join با جداول با حجم بالا

[setak]

سلام
من دو جدول را که هر دو حجم زیادی دارند را با هم join کرده ام و آن فیلدهایی را هم که رویشان join انجام می شود برایشان index گذاشته ام اما باز هم سرعت این query خیلی خیلی پایین است . لطفا من را راهنمائی نمائید
با تشکر

[DonetKarvb]

سلام
من دو جدول را که هر دو حجم زیادی دارند را با هم join کرده ام و آن فیلدهایی را هم که رویشان join انجام می شود برایشان index گذاشته ام اما باز هم سرعت این query خیلی خیلی پایین است . لطفا من را راهنمائی نمائید
با تشکر
به نظر من بهتره که شما ساختار دو تا جدول و یا جدول هایی رو که در این Join شرکت میکنند همراه با کوئریت بدی تا بشه Index مناسبی برای اون پیشنهاد کرد.

[odiseh]

سلام
من دو جدول را که هر دو حجم زیادی دارند را با هم join کرده ام و آن فیلدهایی را هم که رویشان join انجام می شود برایشان index گذاشته ام اما باز هم سرعت این query خیلی خیلی پایین است . لطفا من را راهنمائی نمائید
با تشکر



سلام
من برای حل این مشکل پیشنهاد می کنم که شما هر کدام از جداول بزرگ خود را به صورت Dervided Table در کوئری join خود شرکت دهید. نه اینکه همه جدول را بگیرید

[AminSobati]

لطفا خود دستور Select و همچنین دستورات Create Index رو اینجا پست کنید

[SabaSabouhi]

با سلام
باید بدانید که هر عمل Join یک ضرب دکارتى از دو جدول ایجاد مى‌کند، وقتى که تعداد سطرهاى جدول‌هاى شما زیاد باشد حاصل این ضرب یک جدول مجازى با تعداد حاصل ضرب رکوردهاى موجود خواهد شد. شرایطى که شما پس از کلمه‌ى ON اضافه مى‌کنید محدود کننده‌ى تعداد سطرهاى پاسخ است. بنابراین توصیه مى‌کنم که در Joinها جدول‌هاى بزرگ تا جایى که امکان دارد دیرتر درگیر شوند و دیگر این که تمام شرط‌هاى محدود کننده در اولین جایى که ممکن است ظاهر شوند.
مثلاً اگر جدول مشتریان را با جدول خریدها Join مى‌کنید و شرط تاریخ دارید حتماً این شرط را پس از Join اعمال کنید و آن را به فرمان Where در پایان Query خود واگذار نکنید.

صبا صبوحى

[عفت بزرگه]

این فرمایشتان رو روی چه حسابی مفرمائید؟

[DonetKarvb]

با سلام
باید بدانید که هر عمل Join یک ضرب دکارتى از دو جدول ایجاد مى‌کند، وقتى که تعداد سطرهاى جدول‌هاى شما زیاد باشد حاصل این ضرب یک جدول مجازى با تعداد حاصل ضرب رکوردهاى موجود خواهد شد. شرایطى که شما پس از کلمه‌ى ON اضافه مى‌کنید محدود کننده‌ى تعداد سطرهاى پاسخ است. بنابراین توصیه مى‌کنم که در Joinها جدول‌هاى بزرگ تا جایى که امکان دارد دیرتر درگیر شوند و دیگر این که تمام شرط‌هاى محدود کننده در اولین جایى که ممکن است ظاهر شوند.
مثلاً اگر جدول مشتریان را با جدول خریدها Join مى‌کنید و شرط تاریخ دارید حتماً این شرط را پس از Join اعمال کنید و آن را به فرمان Where در پایان Query خود واگذار نکنید.

صبا صبوحى
با سلام
در SQL Server یک بخشی وجود دارد به نام Execution Plan که یک هوش مصنوعی می باشد. بسار قدرتمند است. این کارهایی رو که میفرمایید خود SQL Server توسط این بخش انجام میدهد.
استفاده از اندیکس ها به کوئری ما سرعت میبخشد. ولی نه هز اندکسی. باید دید که این دوستمون چه کوئری دارند و همچنین چه ایندکسی

[AminSobati]

با سلام
در SQL Server یک بخشی وجود دارد به نام Execution Plan که یک هوش مصنوعی می باشد. بسار قدرتمند است. این کارهایی رو که میفرمایید خود SQL Server توسط این بخش انجام میدهد.
استفاده از اندیکس ها به کوئری ما سرعت میبخشد. ولی نه هز اندکسی. باید دید که این دوستمون چه کوئری دارند و همچنین چه ایندکسی
برای واضحتر کردن موضوع:
در حقیقت Query Processor و Query Optimizer هوش مصنوعی هستند، Execution Plan شیوه ای هستش که SQL Server برای اجرای Query پس از تحلیل بدست میاره.
همونطور که اشاره کردید، هر ایندکسی به Query ما کمک نمیکنه و تشخیص ایندکس مناسب میتونه کار فنی بحساب بیاد.
با وجود اینکه Query Processor بسیار خوب بعضی شرط ها رو تشخیص میده و در جای درستش ادغام میکنه، اما بعضا بکار بردن نکاتی که در پستهای قبلی اشاره شد میتونه Hint بیشتری به SQL Server بده.