আমি যখন dbcc show_statistics ('Reports_Documents', PK_Reports_Documents)রিপোর্ট আইডি 18698 এর জন্য নিম্নলিখিত ফলাফল পাই:
এই প্রশ্নের জন্য:
SELECT *
FROM Reports_Documents
WHERE ReportID = 18698 option (recompile)আমি একটি ক্যোয়ারী প্ল্যান পেয়েছি যা একটি ক্লাস্টারড সূচককে PK_Reports_Documentsপ্রত্যাশার অনুসারে সন্ধান করে।
তবে সারণির আনুমানিক সংখ্যার জন্য যেটি আমাকে বিভ্রান্ত করে তা হ'ল:
এই অনুযায়ী :
যখন নমুনা ক্যোয়ারী WHERE ক্লজ মানটি হিস্টোগ্রাম RANGE_HI_KEY মানের সমান হয়, এসকিউএল সার্ভার হিস্টোগ্রামে EQ_ROWS কলামটি সারণীর সংখ্যা নির্ধারণ করতে ব্যবহার করবে
আমি এটি এমনভাবেই প্রত্যাশা করব, তবে বাস্তবে এটি বাস্তবে দেখা যায় না। আমি অন্যান্য কিছু RANGE_HI_KEYমানও চেষ্টা করেছিলাম যা হিস্টগ্রামে উপস্থিত ছিল এবং এটির show_statisticsঅভিজ্ঞতাও ছিল। আমার ক্ষেত্রে এই ইস্যুটির ফলে কিছু ক্যোয়ারিকে খুব অযৌক্তিক প্রয়োগের পরিকল্পনা ব্যবহার করার কারণ বলে মনে হচ্ছে যার ফলস্বরূপ কয়েক মিনিটের এক্সিকিউশন সময় হবে যখন আমি এটিকে 1 সেকেন্ডে কোয়েরি ইঙ্গিত সহ চালাতে পারি।
সব মিলিয়ে: কেউ আমাকে ব্যাখ্যা করতে পারেন EQ_ROWSযে হিস্টোগ্রাম থেকে কেন সারণির আনুমানিক সংখ্যার জন্য ব্যবহার করা হচ্ছে না এবং ভুল অনুমানটি কোথা থেকে এসেছে?
আরও কিছুটা (সম্ভবত সহায়ক) তথ্য:
- স্বয়ংক্রিয় তৈরি পরিসংখ্যান চালু এবং সমস্ত পরিসংখ্যান আপ টু ডেট।
- সন্ধান করা টেবিলটিতে প্রায় 80 মিলিয়ন সারি রয়েছে।
PK_Reports_Documentsসংমিশ্রণ পি কে গঠিত হয়ReportID INTএবংDocumentID CHAR(8)
ক্যোয়ারিতে মোট 5 টি পৃথক পরিসংখ্যান অবজেক্ট লোড করা হচ্ছে বলে মনে হচ্ছে, এগুলির সবকটিতে ReportIDটেবিলের থেকে + কিছু অন্যান্য কলাম রয়েছে। সেগুলি নতুনভাবে আপডেট করা হয়েছে। RANGE_HI_KEYনীচের টেবিলের মধ্যে হিস্টোগ্রামের সর্বোচ্চ উপরের আবদ্ধ কলাম মান।
+-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+
| name | stats_id | auto_created | user_created | Leading column Type | RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS | DISTINCT_RANGE_ROWS | AVG_RANGE_ROWS |
+-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+
| PK_Reports_Documents | 1 | 0 | 0 | Stationary | 18722 | 0 | 2228,526 | 0 | 1 |
| _dta_index_Reports_Documents_42_1629248859__K1_K63_K14_K13_K22_K23_72_6 | 62 | 0 | 0 | Stationary | 18698 | 0 | 2228,526 | 0 | 1 |
| _dta_stat_1629248859_1_1_59 | 76 | 0 | 1 | Stationary | 18686 | 50,56393 | 1 | 0 | 13397,04 |
| _dta_stat_1629248859_1_22_14_18_12_6 | 95 | 0 | 1 | Stationary | 18698 | 0 | 2228,526 | 0 | 1 |
| _dta_stat_1629248859_1_7_14_4_23_62 | 96 | 0 | 1 | Stationary | 18698 | 56,63327 | 21641,5 | 0 | 14526,44 |
+-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+sp_updatestats পরিসংখ্যান আপডেট করতে প্রতি রাতে চলার সময় নির্ধারিত হয়।
_dta_পরিসংখ্যান তৈরি করি নি , ডিবিতে আমার প্রথম চেহারা পাওয়ার পর থেকে তারা সেখানে ছিল। আমি জানতাম না সুপারিশগুলি ব্যবহার করলে এরকম বিরূপ প্রভাব