بالا بردن سرعت Query در پردازش 1 میلیون رکورد

[niksoft]

با عرض سلام خدمت دوستان عزیز

در برنامه ای که مشغول کار بر روی آن هستم به گفته ی خود موسسه قرار است روزانه بالای 1000 رکورد وارد دیتابیس شود

تنها ترس بنده از این است که در قسمت گزارش گیری به دلیل این که Stored Procedure ی که برای درست کردن گزارش نوشته ام و ریپورتم را با فیلدهای این Stored Procedure پر میکنم به دلیل این که از 3جدول مختلف Select میکند در تعداد رکوردهای بالا دچار مشکل نشود و مدت زمان گزارش گیری از حد معمول بالاتر شود

و یا سرعت برنامه کند نشود

خواهشا اگر راه بهتری یا شیوه ی منطقی تری برای حل این مشکل دارید بنده را راهنمایی کنید
آیا قرار دادن Index روی جداول زیر درست است ؟ اگر درست است روی کدام فیلدها بهتر است؟

در این جا Stored Procedure را میگذارم
متشکرم:تشویق:



Create Procedure Forward_Report
AsBegin
SELECT Forward.Id,
Forward.Kelase,
Forward.Number,
Forward.Wanted,
Oragh.Title AS Oragh,
Vahed.Title AS Vahed,
Forward.ReciveDate,
Forward.DeliverDate
FROM Forward
INNERJOIN
Vahed ON Forward.Vahed_Id = Vahed.Id
INNERJOIN
Oragh ON Forward.Oragh_Id = Oragh.Id
End

[AminSobati]

دوست عزیزم،
برای پیشنهاد بهترین ایندکسها، لازمه اطلاعات با حجم واقعی و همچنین Execution Plan در دست باشه، اما مطمئنم اینها میتونه کمک بسیاری به Performance گزارش شما انجام بده:


create index ix1 on forward (Vahed_Id, Kelase, Number, Wanted, ReciveDate, DeliverDate, Id)
create index ix2 on forward (Oragh_Id , Kelase, Number, Wanted, ReciveDate, DeliverDate, Id)
create index ix1 on Vahed (Id , Title)
create index ix1 on Oragh (Id , Title)

[Microsoft.net]

جناب امین خان در ایندکس اول و دوم هدف شما فراهم کردن Covered Query هست دیگه درسته ؟ آیا اگه یکی از فیلدهای ما در این جدول از نوع Image باشه بازم همین نوع ایندکس رو پیشنهاد میکنید ؟

[niksoft]

این کار رو انجام دادم

Query در صد هزار رکورد 1 ثانیه زودتر جواب داد :متفکر:

ولی حجم دیتابیس از 60MB به 200MB رسید :متعجب:

آیا بالا رفتن حجم تا این اندازه طبیعیه ؟ مشکلی به وجود نمیاد ؟

[linux]

این کار رو انجام دادم

Query در صد هزار رکورد 1 ثانیه زودتر جواب داد :متفکر:

ولی حجم دیتابیس از 60MB به 200MB رسید :متعجب:

آیا بالا رفتن حجم تا این اندازه طبیعیه ؟ مشکلی به وجود نمیاد ؟

چکار به حجم فایل داری شما؟ این یک مورد نگرانی نداره.
در ضمن این یک کوئری ساده و معمولی هست که بدون هیچ شرطی یک جدول را بر می گرداند، این به چه دردت می خوره ؟
فرض کن یک هزار میلیارد تا رکورد را هم در کمتر از 1 ثانیه بر گرداند میخواهی چی کار کنی؟ جشن بگیری عروسی برپا کنی شادمانی کنی و از خوشحالی خودت بکوبی به سقف ؟

[رضا عربلو]

بهتر ایندکس را برای فیلدهایی که به انها جوین می شوید یا بروی انها سرچ می کنید اضافه کنید.
اضافه کردن ایندکس با چندین فیلد باعث افزایش بیش از اندازه حجم فایل دیتابیس می گردد. به نر من بهتر است به جای اون چهار تا ایندکس دو ایندکس پایین را اضافه کنید.


create index ix1 on forward (Vahed_Id)
create index ix2 on forward (Oragh_Id)

در ضمن می توانید نتیجه این نوع ایندکس را در execution plane ببینید و مقایسه ای با چهار ایندکس قبلی بکنید.

[AminSobati]

بهتر ایندکس را برای فیلدهایی که به انها جوین می شوید یا بروی انها سرچ می کنید اضافه کنید.
اضافه کردن ایندکس با چندین فیلد باعث افزایش بیش از اندازه حجم فایل دیتابیس می گردد. به نر من بهتر است به جای اون چهار تا ایندکس دو ایندکس پایین را اضافه کنید.

در ضمن می توانید نتیجه این نوع ایندکس را در execution plane ببینید و مقایسه ای با چهار ایندکس قبلی بکنید.

رضا جان زمانی که یک Query حیاتی باشه (تعداد دفعات زیادی ازش استفاده میشه)، فیلدهای بیشتر هم برای ایندکسش در نظر میگیریم. چون کندی سرعت Query به مراتب بیشتر از کندی در ویرایش اطلاعات به چشم میاد.
ایندکسهایی که شما پیشنهاد کردین دقیقا خاصیت دو ایندکس اول من رو داره، با این تفاوت که Query رو Cover نمیکنه و احتمالا Optimizer ازش چشم پوشی میکنه.

[AminSobati]

جناب امین خان در ایندکس اول و دوم هدف شما فراهم کردن Covered Query هست دیگه درسته ؟ آیا اگه یکی از فیلدهای ما در این جدول از نوع Image باشه بازم همین نوع ایندکس رو پیشنهاد میکنید ؟
- بله درسته
- اگر فیلد Image کم حجم باشه مشکلی نداره اما گاها تجربه کردم که واکشی کردن فیلد Image حجیم در Query اصلی مشکل ساز میشه. مثلا در یک مورد، Optimizer از همون ابتدا فیلد Image رو به همراه سایر اطلاعات برمیداشت و در Plan بزرگی که طی میکرد، Image رو هم با خودش میاورد. بعد از کلی فیلتر شدن، مثلا 20 رکورد باقی میموند. با وجود اینکه Plan خیلی بهینه بود اما سرعت کند بود. تا اینکه متوجه پهنای رکورد در آمار و ارقام Exec Plan شدم. فیلد Image رو از Query اصلی حذف کردم، سرعت Query به حدی رسید که تقریبا در یک پنجم زمان قبلی به پایان میرسید! نتیجه این که تصمیم گرفتم Query اصلی رو بدون Image انجام بدم و وقتی تمام رکوردهای اضافی فیلتر شدن، حاصل رو دوباره با جدول اصلی Join کنم تا Imageها رو واکشی کنم. این باعث شد Image فقط برای 20 رکورد باقیمانده بازیابی بشه که سرعت Query ایده آل شد.

[AminSobati]

این کار رو انجام دادم

Query در صد هزار رکورد 1 ثانیه زودتر جواب داد :متفکر:

ولی حجم دیتابیس از 60MB به 200MB رسید :متعجب:

آیا بالا رفتن حجم تا این اندازه طبیعیه ؟ مشکلی به وجود نمیاد ؟

افزایش حجم میتونه هم روی Data و هم روی Log اتفاق افتاده باشه.
در مورد سرعت Query، با توجه به اینکه هیچ شرطی در Where وجود نداره، قائدتا تمام رکوردها باید بازیابی بشن که ناچارا زمانش زیاد خواهد بود. اگر نهایتا باید Where اعمال کنید، Query رو کامل کنین و مجددا ارسال کنین تا ایندکس مناسب تر پیشنهاد کنم