درباره نویسنده

میلاد فیروزی

میلاد فیروزی

   هم اکنون کارشناس تضمین کیفیت تیم توسعه دیجی کالا می باشم.

17 دیدگاه

  1. مسعود طاهری

    مسعود طاهری

    میلاد عزیز متشکرم از مقاله خوبی که در سایت قرار دادید.

    فقط یک نکته کوچک دوستان عزیز توجه داشته باشید که قرار نیست هزینه LOOKUP همه کوئری را حذف کنید. دنبال کوئری های پر استفاده باشید روی حذف هزینه LOOKUP آن متمرکز شوید. ضمنا اگر قرار است تعداد فیلد زیادی به ایندکس INCLUDE شود شاید این کار به علت هزینه نگهداری ایندکس (به علت تغییرات و… ) به صرفه نباشد.
    اما در کل مقاله عالی و خوبی است در جهت آشنایی دوستان با مفهوم LOOKUP و حذف هزینه آن
    متشکرم میلاد جان
    پاسخ
    1. میلاد فیروزی

      میلاد فیروزی

          ممنون استاد

      نکات ارزشمندی فرمودید
      پاسخ
  2. فرشید علی اکبری

    فرشید علی اکبری

    سلام

    مقاله خوبی بود و تشکر از زحمتی که بابت به اشتراک گذاری مطالب میگذارید. فقط اگه اون Nun را به Non ویرایش کنید باعث سردرگمی کاربران مبتدی نمیشه.
    ممنون.
    پاسخ
    1. فرید طاهری

      فرید طاهری

         سلام. با تشکر از دقت شما
      اصلاح گردید.

      پاسخ
      1. میلاد فیروزی

        میلاد فیروزی

            ممنون

        اشتباه از من بود
  3. مهدی ربانی ذبیحی

    مهدی ربانی ذبیحی

        با سلام ممنون بابت مقاله خوبتون

    پاسخ
  4. علی تجویدی

    با سلام
    ممنون از مقاله مفید
    جمله شما که در زیر آورده شده صحیح نیست
    “حال اگر این Non Clustered روی Heap Table تعریف شده باشد SQL مجبور
    است تمامی جدول را برای یافتن فیلد اضافی بگردد که به این عمل هم RID
    Lookup گفته می شود.

    تمامی جدول را نمی گردد و در خیلی موارد RID Lookup هزینه کمتری نسبت به Key Lookup دارد.
    با تشکر

    پاسخ
  5. محمد

    با عرض سلام خدمت همه دوستان
    آقای فیروزی عزیز تشکر از مقاله ای که ارائه کردید.

    2 نکته وجود داشت که لازم میدونم به اون اشاره ای داشته باشم.

    1-همونطور که دوست خوبمون آقای تجویدی به اون اشاره داشتن SQL Optimizer مجبور نیست کل جدول را جستجو کند بلکه فقط اون ستونی رو که توسط Clustered یا NonClulustered پوشش داده نشده را در سطح Data Page جستجو میکند.

    2-آقای تجویدی عزیز صحبت شما در مواقعی که تعداد رکوردهای جداول کم باشد صحت دارد و در تعداد رکورد های میلیونی نتیجه عکس خواهید گرفت.
    برای نمونه اگر شما تست هایی را انجام داده باشید زمان کامپایل جداول heap در تعداد رکورد کم (در حد 100 تا 200 هزار تا)به نسب جداول غیر Heap کمتر است ولی read Ahead از جداولی که دارای key Lookup هستند بیشتر است.
    و این عمل موجب می شود که در تعداد رکوردهایی گفته شده اختلاف 2 تا 3 درصدی بین RID یا Key Lookup بوجود آید.
    با تشکر

    پاسخ
  6. میلاد فیروزی

    میلاد فیروزی

       ممنون از متذکر شدن نکته ارزشمندتون جناب تجویدی و آقای محمد

    قطعا که زمانی به فکر هذف هزینه Lookup می افتیم که ارزشش رو داشته باشه و هزینه ی زیادی برداشته باشه
    اگر دقت کرده باشید من گفتم اگر Non Clustered روی یک جدول Heap تعریف شده باشد ممکن است حالتی باشد که به دلیل تعریف نادرست Index این اتفاق بیوفتد و SQL کل جدول را جست و جو کند
    فرض کنید یک فیلد Non Clustered روی یک جدول Heap تعریف کرده باشیم , 
    این اتفاق گاها به دلیل درک نادرست از مفهوم Index رخ می دهد
    پاسخ
  7. Hamid J. Fard

    Hamid J. Fard

       با سلام
    بعد از روزها دوری باز هم برگشتم.
    البته این نکته رو بگم که SQL Server  یک ستون مخفی برای جداول Heap قرار می دهد به نام RID که این مقدار شامل FileID, PageID, SlotID است.
    عملیات RID Lookup تمامی جدول را اسکن نمی کند بلکه دقیقا برای یافتن آن داده به آدرس آن مراجعه می کند و هزینه ی RID Lookup و Key Lookup دقیقا یکی است.
    نکته دوم اینکه شما می توانستید ستون OrderDate را در یک ایندکس دیگر قرار دهید تا از قابلیت Index Intersection استفاده کنید تا اگر احیانا یک Query دیگر از این ستون خواست استفاده کنه عملیات Seek انجام بشه. در این مثال شما اگر ما بر اساس OrderDate فیلتر کنید احتمال استفاده نکردن از Index Seek به دلیل نداشتن Index Edge Key  بسیار بالا است.
    پاسخ
    1. میلاد فیروزی

      میلاد فیروزی

          جناب فرد ممنون از اطلاعات ازشمندتون

      نکاتی که در مورد FileID, PageID, SlotID گفتید رو نمی دونستم
      تشکر می کنم
      پاسخ
      1. Hami J. Fard

        خواهش می کنم. امیدوارم که استفاده کرده باشید.

  8. مسعود طاهری

    مسعود طاهری

    یکی از بزرگترین معایب جداول Heap مسئاله Forwarding Pointer است. 

    یکی از دلیل استفاده از Forwarding Pointer جلوگیری از بروزرسانی ردیف‌های ایندکس‌های Non Clustered بهنگام انتقال row اصلی به data page  دیگر پس از بروزرسانی می‌باشد. 
    اما این مسئاله (Forwarding Pointer) یک ایراد بزرگ به سیستم تحمیل می کند زمانی که SQL Server از IAM Page برای استخراج Pageهای وابسته به یک Heap Table استفاده می کند ممکن است به ازای برخی از Pageها چندین بار عملیات خواندن تکرار شود و این یعنی تحمیل IO اضافی به سیستم.
    پاسخ
  9. عاطفه حسن پور

    عاطفه حسن پور

        با سلام وتشکر از مقاله بسیار و عالی و جذابی که داشتید واقعا بعد از مدت ها که اومدم شگفت زده شدم بابت این همه مطلب عالی

    پاسخ
  10. حسن ضرابی

    حسن ضرابی

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

    از بابت این مقاله خیلی خوب ممنونم لطف کردید.

    با تشکر از شما

    پاسخ
  11. yahyaee.ali

    yahyaee.ali

    با سلام
    مقاله تحسین برانگیزی بود
    یه سوال:
    به جای استفاده از الگوی Cover Index بهتر نبود الگوی Included Columns پیشنهاد می شد چون با این الگوی جدید تر می‌توان ستون‌های اضافی را در ایندکس‌ها، Include کنیم و نیازی نیست که جزء ستون‌های اصلی ایندکس باشند.
    برداشت من این بود که به طور ضمنی در اولین کامنتی که استاد عزیز جناب مهندس طاهری هم گذاشته اند به این مطللب اشاه شده بود
    با سپاس

    پاسخ

ارسال یک نظر

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

تمامی حقوق مادی و معنوی این وب سایت متعلق به نیک آموز می باشد.
این سایت توسط تیم آموزش برنامه نویسی نیک آموز مدیریت می شود.