مقایسه زمان اجرای دو Query

[supporter]

با سلام،
کسی می‌دونه چرا در بعضی حالات (که البته من نمی دونم دقیقا چه وقت هایی این حالت پیش ‌می‌آد؟) Query دوم به شدت سریعتر از Query اوله؟





SELECT CustomerCode
FROM tabel_source



و Query دوم:





DECLARE @Customer TABLE ( CustomerCode INT )
INSERT INTO @Customer( Customer_code )
SELECT CustomerCode
FROM tabel_source


SELECT CustomerCode From @Customer



لازم میدونم بگم این حالت برای خودم پیش اومده (البته در اون حالت table_sorce مربوط کمی پیچیده بود ولی در هر دو Query ها table_source ها کاملا مشابه بود)

[AminSobati]

دوست عزیزم،
منظورتون اینه که Query برای عمل Insert سریعتر از حالتی که قراره نمایش بده عمل میکنه؟ اگر بله، باید بگم وقتی تعداد رکورد زیاد باشه، منتقل شدن اطلاعات در شبکه خودش میتونه زمان قابل توجهی صرف کنه. اما در عمل Insert، اطلاعات در شبکه جا به جا نمیشن.

[supporter]

جناب ثباتی،
هر دو Query در نهایت رکوردهای مورد نظر رو نمایش میدن با این تفاوت که در Query دوم به جای Select مستقیم ابتدا خروجی Query اول در یک Variable Table ریخته می‌شه و بعد، از این Variable Table سلکت زده میشه.
یعنی زمان Insert در Variable Table بعلاوه زمان Select از اون از زمان اجرای Query اول به شدت کمتره!!!
باز هم می‌گم این حالت برای من وقتی پیش اومده که table_source مربوط به Query کمی پیچیده بوده و البته تعداد رکوردهای جداول مربوط هم کم نبوده.

[AminSobati]

آیا Query شما عینا همینه یا مثل اونیکی پست بازهم شاخ و برگ داشته!

[supporter]

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

[aidinwashere]

من این چنتا جمله رو پیدا کردم, شاید به مشکل مربوط باشه:

Because of the well-defined scope, a table variable will generally use fewer resources than a temporary table.

Using a temporary table inside of a stored procedure may result in additional re-compilations of the stored procedure. Table variables can often avoid this recompilation hit.

اینو بخونین:
the size of the resultset will determine which solution to choose. If the table stores a resultset so large you require indexes to improve query performance, you’ll need to stick to a temporary table. In some borderline cases try some performance benchmark testing to see which approach offers the best performance. If the resultset is small, the table variable is always the optimum choice.

شاید چون حجم خروجی شما زیاده, استفاده از table variable مفید واقع شده. آیا حجم داده های برگشتی زیاده؟

ببخشید جناب ثباتی وسط سوالای شما پریدم!

ویرایش: راستی منبع http://www.odetocode.com/Articles/365.aspx

[AminSobati]

حقیقتا تنها کاری که من اگر جای شما بودم انجام میدادم تا شاید به منبع اشکال پی ببرم، اینه که Exec Plan رو برای هر دو مورد بررسی کنم ببینم کدوم قسمت داره منابع سخت افزاری رو بیشتر تحت فشار قرار میده. اگر بتونین Plan رو ازش Print Screen بگیرین خیلی خوبه

[supporter]

در مورد تعداد رکورد های خروجی باید بگم که تعداد این رکوردها در حدود 2000 تا بود .
در ضمن من Exec Plan هردو حالت رو بررسی کردم ولی از اونجایی که Exec Plan ها کمی پیچیده شده بودن (البته برای من) نفهمیدم چرا این اتفاق می‌افته.
اما یه چیزی که در مورد Exec plan های این دو تا Query می تونم بگم اینه که Exec Plan ها تقریبا شبیه هم بودن با این تفاوت که Query اول (کند تر) چند تا parallelism داشت.
البته من امروز Backup همون Database رو روی یه سیستم دیگه Restore کردم و دو تا Query رو دوباره اجرا کردم. این دفعه Exec plan دو تا Query شبیه هم بودن و زمان اجراشون هم تقریبا یکی بود.
البته Queryهای قبلی رو روی SQL Server Service pack3 اجرا کرده بودم و امروز روی Service Pack 4 (نمی‌دونم ربط داره یا نه؟)
البته از Exec plan هر دو حالت حتما Print Screen می‌گیرم تا ببینید.

[AminSobati]

از این Hint استفاده کنین:


select * from mytable option(maxdop 1)

این حالت رو روی همون سروری که parallelism میداد آزمایش کنین