PDA

View Full Version : Search بسیار سریع در SQL(فوری)



sm
چهارشنبه 24 تیر 1383, 01:11 صبح
با سلام
می خواستم توی یه بانک اطلاعاتی که حدود 120 تا جدول دراه و چندتاییش 110تا فیلد اطلاعاتی دارند و هرکدوم هم حداقل 6.000رکورد دارند تا 300.000 رکورد!!!! چگونه می تونم یه Search سریع انجام بدم....
چونکه Search معمولی وقت گیره و اگه 2تا از این جدولها رو با هم Join کنیم که دیگه!!!!!!!!!!!!!!!!
یه چیزی مثل دستور Seek ظاهرا در SQL وجود داره
می خواستم اگه کسی با این دستور یا دستورای دیگه کار کرده منو راهنمایی کنه...
ممنون

vadood
چهارشنبه 24 تیر 1383, 07:06 صبح
سرعت جستجو در SQL Server تابع طراحی منطقی بانک اطلاعاتی، ایجاد ایندکس های مناسب، نوشتن درست کوئری و سخت افزار مورد استفاده است. به هر حال هیچ کلید Turbo ای روی سکوئل سرور وجود نداره!

avebrahimi
چهارشنبه 24 تیر 1383, 14:25 عصر
بهترین راه این است که یا

1) جدا از سکوئل سرور، خودتان یک سرچ بنویسید که خاص دیتا شما باشد

یا

2) از جانشینی مثل CodeBase استفاده کنید اما فکر نکنم بتوانید آن را در بازار ایران پیدا کنید

sm
چهارشنبه 24 تیر 1383, 18:40 عصر
ممنون
اما تا اونجایی که من شنیدم مثل اینکه برای سرچ سریع برخی توابع وجود دارند
البته این حرفیه که یکی از اساتیدمون مگفت...راست و دروغش گردن اون...
!!!
بازم ممنونم

Microsoft.net
جمعه 26 تیر 1383, 13:33 عصر
بهترین کاری که می تونی انجام بدی اینه که از داخل enterprise manager بر روی table که می خوای سرچ انجام بدی یه ایندکس خوشه ای درست کنی و درایوی رو که بانکهات روی اون قرار دارن رو NTFS کنی بهتره

ایندکس خوشه ای از ساختار B tree برای جستجو استفاده می کنه

AminSobati
یک شنبه 18 مرداد 1383, 00:47 صبح
دوست عزیز،
تعداد رکوردی که شما قید کردین برای SQL Server رقم معتنا بهی نیست(خوشبختانه!).
اگر میتونید 2 هارد دیسک برای سرور اختصاص بدین، یکی رو برای دیتا و دیگری رو برای ایندکس ها در نظر بگیرین تا جستجو به صورت پارالل یا موازی انجام بشه. همونطور که دوستمون گفتن داشتن ایندکس Clustered و NonClustered سهم عمده ای در بهبود سرعت جستجو دارن. سعی کنید ایندکس Clustered را روی فیلد یونیک و کم حجم بسازید، بعد از اون، سایر ایندکسهای NonClustered همون جدول بخوبی از ایندکس اولیه شما سود میبرن. در صورت لزوم از Indexed Views استفاده کنید که Queryهای شما نیاز به انجام Join یا سایر کارهای غیر ضروری نداشته باشن و Data برای ارائه از قبل آماده شده باشد.
ضمنا اگر از Search در داخل فیلدهای حجیم استفاده میکنید، این کار را حتما با امکانات FullText Search انجام بدین.
امین ثباتی MCSD

sm
یک شنبه 18 مرداد 1383, 19:55 عصر
ممنون امین آقا
اگه براتون امکان داره یه چندتا مثال بزنین آخه من اصلا با این روشهایی که شما و Vadood عزیز گفتن آشنایی ندارم
ممنون

AminSobati
یک شنبه 18 مرداد 1383, 23:51 عصر
سلام،
اگر برای جدولتون Primary Key درست کردین، در حقیقت یک ایندکس Clustered ایجاد کردین که قسمت اول کار انجام شده. از آنجایی که هر جدول فقط یک Primary Key (PK) میتونه داشته باشه، تمام ایندکسهایی که از حالا به بعد میسازید باید NonClustered باشه که طی چند سطر بعد توضیحش رو عرض خواهم کرد.
مهمترین قسمت کار، تجزیه و تحلیل این هستش که برای کدام فیلدها ایندکس بسازیم. چون اولا ایندکسها فضا مصرف میکنند و ثانیا به مجرد هر عمل ویرایش اطلاعات، باید Update بشن. در نتیجه سعی میکنیم این فیلدها رو با احتیاط انتخاب کنیم تا ایندکسهای اضافی روی Performance بانک اطلاعاتی ما تاثیر منفی نداشته باشن.
بهتریم ملاک برای تشخیص اینکه کدام فیلدها ایندکس داشته باشن، دقیقا به Queryهای ما برمیگرده. یعنی ساخت ایندکسها جزء آخرین مرحله طراحی Database هستش. باید تمام Queryهایی که نیاز داریم برای انواع گزارش گیری ها مشخص بشن، بعد از اون فیلدهای کاندید شده رو بدست میاریم.
به عنوان یک معیار خوب، فیلدهایی که بعد از Where قرار میگیرن، کاندید ایدنکس خوردن میشن. مثلا اگر یکی از Queryهای ما به این شکل باشه:
SELECT * FROM customers WHERE country=Germany
میتوانیم نتیجه بگیریم که عمل جستجو روی فیلد country اتفاق خواهد افتاد، پس یک ایندکس روی این فیلد نیاز داریم:
WITH FILLFACTOR=80 CREATE NONCLUSTERED INDEX MyIndex1 ON customers(country)
پارامتر FILLFACTOR مشخص میکند که Pageهای ایندکس ما تا چند درصد پر شوند. برای جدولهایی که زیاد modify میشوند، مقدار 75 تا 80 مناسب هستش.
طبق قائده ای که ذکر شد میتوانیم فیلدهایی که نیاز به ایندکس دارند رو تشخیص بدیم. اگر فیلدهایی که در دستور SELECT ظاهر میشوند کم باشه و اون Query بارها و بارها استفاده میشه، ارزش این رو خواهد داشت که یک ایندکس ترکیبی (ترکیب شده از چند فیلد) بسازیم. به عنوان مثال این Query:
SELECT country, city, customerid FROM customers where country=germany
اگر به تعداد دفعات زیادی اجرا خواهد شد، برایش به جای ایندکس ذکر شده، این ایندکس رو خواهیم ساخت:
CREATE NONCLUSTERED INDEX MyIndex1 ON
customers(country,city,customerid) WITH FILLFACTOR=80
این نوع ایندکس رو اصطلاحا Covering Index مینامند چون تمام فیلدهای مورد نیاز Query، در ایندکس لحاظ شده. یعنی SQL Server برای اجرای Query نیازی به رجوع کردن به جدول نخواهد داشت و تمام اطلاعات مورد نیاز از طریق ایندکس تامین میشود. ولی اگر Query ما به این شکل باشه:
SELECT country, city, customerid, phone FROM customers WHERE country=germany
ایندکس ساخته شده، Covering نخواهد بود چرا که SQL Server برای بدست آوردن phone، میبایستی از قسمت ایندکس، به خود جدول اصلی رجوع کنه که در اصطلاح، Bookmark Lookup اتفاق می افتد و طبیعتا کمی افت سرعت خواهد داشت.
البته فراموش نکنید که هر چه تعداد فیلد ذکر شده در دستور ساخت ایندکس بیشتر باشد، حجم ایندکس ما بیشتر خواهد بود و همچنین دفعات بیشتری این ایندکس به update شدن نیاز پیدا خواهد کرد. به همین دلیل عرض کردم که اگر Queryما خیلی استفاده میشود، برایش Covering Index میسازیم. چون ارزش اون رو خواهد داشت. امیدوارم این اطلاعات که در حقیقت الفبای ساخت ایندکس هم شاید نباشه بتونه کمک کوچکی بکنه. اگر قسمتی نیاز به توضیح بیشتر داشت بفرمایید.
امین ثباتی

sm
دوشنبه 18 آبان 1383, 16:40 عصر
امین خان ممنون
کمک زیادی کردین
راستش یه مدت کسی بهم جواب نداده بود...برای همین نیومده بودم...ممنون
یه نکته و اونهم اینکه من تو برنامه ام تماما از StoredProcedure استفاده کردم...حالا برای جستجو کردن و ایندکس نوشتن چطوری باید عمل کنم
توی جداولم که حدود 120 جدول هست یه شماره 16 رقمی دارم که تقریبا در 95درصد از جداولم استفاده شده یا بعنوان کلید اصلی یل خارجی
ممنون میشم یه راهنمایی همچین پرملات بکنین!!!!!!!!!!!
ممنون :oops:

AminSobati
دوشنبه 18 آبان 1383, 19:32 عصر
دوست عزیزم،
نحوه Search تفاوتی نمیکنه. شما مثل حالت عادی Query مینویسید(یا از SP استفاده میکنید) ولی این ایندکسهای شما هست که باعث میشه تا Query Processor بتونه الگوریتم و روش کارآمد تری رو برای جستجو انتخاب کنه.
اینکه چه ایندکسهایی برای Queryهای ما مناسب هستن، مبحث بسیار گسترده (و البته بسیار جذاب!) داره به اسم Index Tuning که در موردش کتاب نوشته میشه. اما یکی از دستورالعمل های اون که شما هم میتونین در کارتون استفاده کنین اینه که فیلدی که بعد از WHERE در Query قرار میگیره، کاندید برای ایندکس خوردن میشه.
در Post های قبلی هم این مثال رو زده بودم:

مثلا اگر یکی از Queryهای ما به این شکل باشه:
SELECT * FROM customers WHERE country=Germany
میتوانیم نتیجه بگیریم که عمل جستجو روی فیلد country اتفاق خواهد افتاد، پس یک ایندکس روی این فیلد نیاز داریم
ضمنا تشخیص ایندکسهای لازم و همچنین ساختنشون رو میتونین به Index Tuning Wizard محول کنین.
موفق باشید

sm
پنج شنبه 21 آبان 1383, 00:07 صبح
ممنون
امتحان می کنم

AminSobati
پنج شنبه 21 آبان 1383, 00:42 صبح
موفق باشین :)

sm
پنج شنبه 09 تیر 1384, 12:17 عصر
ممنون از راهنمایتون.
خیلی بهم کمک کردین