আমার কিছুটা জটিল এসকিউএল সার্ভার ২০০৮ ক্যোয়ারী রয়েছে (প্রায় 200 টি লাইন মোটামুটি ঘন এসকিউএল) যা আমার প্রয়োজন হিসাবে সম্পাদন করছে না। সময়ের সাথে সাথে পারফরম্যান্স প্রায় .5 সেকেন্ড থেকে প্রায় 2 সেকেন্ডে নেমে যায়।
মৃত্যুদণ্ড কার্যকর করার পরিকল্পনাটি দেখে, এটা বেশ সুস্পষ্ট ছিল যে যোগদানের পুনর্নির্মাণের মাধ্যমে পারফরম্যান্সের উন্নতি হতে পারে। আমি করেছি, এবং এটি করেছে ... প্রায় .3 সেকেন্ডের মধ্যে। এখন ক্যোয়ারিতে "অপশন ফোরস অর্ডার" ইঙ্গিত রয়েছে এবং জীবন ভাল।
আজ আমার সাথে আসে, ডাটাবেস পরিষ্কার। আমি প্রায় 20% সারি সংরক্ষণাগারভুক্ত করেছি, সারিগুলি মোছা বাদ দিয়ে প্রাসঙ্গিক ডাটাবেসে কোনও পদক্ষেপ নিই না ... কার্যকর করার পরিকল্পনাটি সম্পূর্ণ হোজেড হয় । এটি নির্দিষ্ট সাবট্রির কতগুলি সারি ফিরে আসবে এবং সম্পূর্ণরূপে এটি ভুলভাবে বোঝায়:
<Hash>সঙ্গে
<NestedLoops Optimized='false' WithUnorderedPrefetch='true'>এখন ক্যোয়ারির সময়টি প্রায় .3 এস থেকে প্রায় 18 এর দশক পর্যন্ত বেড়ে যায়। (!) আমি সারিগুলি মুছে ফেলেছি বলেই। আমি যদি ক্যোয়ারির ইঙ্গিতটি সরিয়ে দিই তবে আমি প্রায় 2s কোয়েরি সময়টিতে ফিরে আসি। আরও ভাল, কিন্তু খারাপ।
আমি একাধিক অবস্থান এবং সার্ভারে ডাটাবেস পুনরুদ্ধার করার পরে সমস্যাটি পুনরায় তৈরি করেছি। কেবলমাত্র প্রতিটি টেবিল থেকে প্রায় 20% সারি মুছে ফেলা এই সমস্যাটির কারণ হয়।
- জোর করে যোগদানের আদেশের পক্ষে কি কোয়েরি অনুমানগুলি সম্পূর্ণরূপে অসম্পূর্ণ (এবং এভাবে কোয়েরি সময়কে অনির্দেশ্য) করা যায় না?
- আমার কি কেবল আশা করা উচিত যে আমাকে হয় উপ-অনুকূল ক্যোয়ারী সম্পাদনা গ্রহণ করতে হবে, বা এটি বাজপাখির মতো দেখতে হবে এবং প্রায়শই ম্যানুয়ালি কোয়েরি ইঙ্গিতগুলি সম্পাদনা করতে হবে? বা প্রতিটি ইঙ্গিতও পাশাপাশি যোগ হতে পারে? .3 থেকে 2s নেওয়া বড় হিট।
- সারণি মোছার পরেও কেন অপ্টিমাইজারটি ফুঁসে উঠল তা স্পষ্ট? উদাহরণস্বরূপ, "হ্যাঁ, এটি একটি নমুনা স্ক্যান নিয়েছিল, এবং আমি ডেটা ইতিহাসে এর আগে বেশিরভাগ সারি সংরক্ষণাগারভুক্ত করেছিলাম কারণ নমুনায় বিরল ফলাফল পাওয়া যায়, সুতরাং এটি বাছাই করা হ্যাশ অপারেশনটির প্রয়োজনীয়তাটিকে অবমূল্যায়ন করে"?
আপনি যদি কার্য সম্পাদনের পরিকল্পনা দেখতে চান তবে দয়া করে এমন কোনও অবস্থানের প্রস্তাব করুন যাতে আমি সেগুলি পোস্ট করতে পারি। অন্যথায়, আমি সবচেয়ে অত্যাশ্চর্য বিট নমুনা করেছি। এখানে মৌলিক ভুল অনুমান, প্যারেন্সে সংখ্যাগুলি (আনুমানিক: প্রকৃত) সারি হয়।
/ Clustered Index Scan (908:7229)
Nested Loops (Inner Join) --<
\ NonClustered Index Seek (1:7229)
মনে রাখবেন যে অভ্যন্তরীণ লুপটি 908 টি সারি স্ক্যান করবে বলে আশা করা হচ্ছে, তবে এর পরিবর্তে 52,258,441 স্ক্যান করে। যদি এটি সঠিক হত তবে এই শাখাটি 12 সিসি না দিয়ে প্রায় 2 মিমি দৌড়ে দিত। সারিগুলি মোছার আগে, এই অভ্যন্তরীণ যোগদানের প্রাক্কলনটি কেবল 2 এর মোট ফ্যাক্টর দ্বারা বন্ধ ছিল এবং দুটি ক্লাস্টার ইনডেক্সে হ্যাশ ম্যাচ হিসাবে সম্পাদিত হয়েছিল।