আমি যোগদানের ইঙ্গিত যুক্ত করলে এসকিউএল সার্ভার সারি অনুমান কেন পরিবর্তন হয়?


15

আমার একটি ক্যোয়ারী রয়েছে যা কয়েকটি টেবিলগুলিতে যোগদান করে এবং বেশ খারাপভাবে সম্পাদন করে - সারি অনুমানগুলি (এক 1000 বার) বন্ধ এবং নেস্টেড লুপস জয়েন বেছে নেওয়া হয়, যার ফলে একাধিক টেবিল স্ক্যান হয়। কোয়েরির আকৃতিটি মোটামুটি সোজা, এরকম কিছু দেখতে:

SELECT t1.id
FROM t1
INNER JOIN t2 ON t1.id = t2.t1_id
LEFT OUTER JOIN t3 ON t2.id = t3.t2_id
LEFT OUTER JOIN t4 ON t3.t4_id = t4.id 
WHERE t4.id = some_GUID

ক্যোয়ারির সাথে চারপাশে খেলতে, আমি লক্ষ্য করেছি যে যখন আমি একটির সাথে যোগ দেওয়ার জন্য মার্জ যোগটি ব্যবহার করার ইঙ্গিত দিচ্ছি তখন এটি বহুগুণ দ্রুত চলে। এটি আমি বুঝতে পারি - যুক্ত হওয়া ডেটার জন্য মার্জ জয়েন একটি ভাল বিকল্প, তবে এসকিউএল সার্ভার সঠিকভাবে নেস্টেড লুপগুলি বেছে নেওয়ার অনুমান করে না।

যা আমি পুরোপুরি বুঝতে পারি না তা কেন এই যোগদানের ইঙ্গিতটি সমস্ত পরিকল্পনা অপারেটরগুলির সমস্ত অনুমানকে পরিবর্তন করে? বিভিন্ন নিবন্ধ এবং বই পড়া থেকে, আমি ধরে নিয়েছি যে পরিকল্পনাটি তৈরির আগে কার্ডিনালিটির অনুমান করা হয়, সুতরাং কোনও ইঙ্গিত ব্যবহার করে অনুমানগুলি পরিবর্তিত হত না, বরং স্পষ্টভাবে এসকিউএল সার্ভারকে একটি নির্দিষ্ট শারীরিক যোগদানের প্রয়োগটি ব্যবহার করতে বলি।

যাইহোক, আমি যা দেখছি তা হল যে মার্জ ইঙ্গিতটি সমস্ত অনুমানকে বেশ নিখুঁত করে তোলে। কেন এটি ঘটে এবং কোয়েরি অপ্টিমাইজারটি কোনও ইঙ্গিত ছাড়াই আরও ভাল অনুমান করা যায় - এমন পরিসংখ্যান স্পষ্টতই এর জন্য অনুমতি দেয় তা বিবেচনা করে?

ইউপিডি: অজ্ঞাতনামা কার্যকরকরণের পরিকল্পনাগুলি এখানে পাওয়া যাবে: https ://www.DPboxboxss/hchfuru35qqj89s/ विसর_join.sqlplan?dl=0 https://www.rodbox.com/s/38sjtv0t7vjjfdp/no_hints_join.sqlplan?dl = 0

আমি টিএফ 3604, 9292 এবং 9204 ব্যবহার করে উভয় প্রশ্নের দ্বারা ব্যবহৃত পরিসংখ্যানগুলি পরীক্ষা করেছি এবং সেগুলি অভিন্ন। তবে যে সূচিগুলি স্ক্যান করা / সন্ধান করা হয়েছে তা প্রশ্নের মধ্যে পৃথক।

তদ্ব্যতীত, আমি কোয়েরিটি চালানোর চেষ্টা করেছি OPTION (FORCE ORDER)- এটি প্রতিটি সংযুক্তির জন্য হ্যাশ ম্যাচটি বেছে নেওয়ার সাথে সংযুক্ত হয়ে যোগদানের চেয়ে আরও দ্রুত চলে।


3
আপনি কি খেয়াল করেছেন যে আপনার একটি বাহ্যিক যোগদান রয়েছে তবে আপনি যেখানে সেই ধারাটিতে টেবিলটি ব্যবহার করছেন?
জেমস জেড

@ জামেজেড - হ্যাঁ, আমি এটি সম্পর্কে সচেতন, যদিও আমি মনে করি না যে এতে কোনও সমস্যা আছে।
আলেকজান্ডার শেলিন

9
@ অ্যালেক্সশ ওয়েল, এটির সাথে একটি যৌক্তিক / শব্দার্থিক সমস্যা আছে কারণ এটি আপনার বাইরের জোড়কে অভ্যন্তরীণ যোগদানের পরিবর্তিত করে।
হারুন বারট্রান্ড

উত্তর:


21

বিভিন্ন নিবন্ধ এবং বই পড়া থেকে, আমি ধরে নিয়েছি যে পরিকল্পনাটি তৈরির আগে কার্ডিনালটির অনুমান করা হয়।

বেপারটা এমন না. একটি প্রাথমিক cardinality অনুমান প্রাপ্ত করা হয়, প্রাথমিক যোগদানের অর্ডার অপটিমাইজার দ্বারা নির্বাচিত প্রভাবিত যা (simplifications এবং অন্যান্য কাজ পরে)।

যাইহোক, পরবর্তী অনুসন্ধানগুলি (ব্যয়ভিত্তিক অপ্টিমাইজেশনের সময়) নতুন কার্ডিনালিটির অনুমানগুলি গণনা করতে পারে এবং প্রায়শই তা করতে পারে। এই পরবর্তী সিইগুলি কম-বেশি 'নির্ভুল' হতে পারে। যদি কোনও প্রাক-অনুমানের ফলাফল হয় তবে অপটিমাইজারটি এমন একটি পরিকল্পনা চয়ন করতে পারে যা সস্তা দেখায়, তবে বাস্তবে এটি দীর্ঘ সময়ের জন্য চলে।

সাধারণভাবে, এর কোনও গ্যারান্টি নেই যে শব্দার্থগতভাবে অভিন্ন সাবট্রিজগুলির জন্য কার্ডিনালিটি অনুমানগুলি একই ফলাফল আনবে। এটি সর্বোপরি একটি পরিসংখ্যান প্রক্রিয়া এবং কিছু অপারেশনে অন্যের তুলনায় গভীর সিই সমর্থন রয়েছে।

আপনার ক্ষেত্রে, অন্য ফ্যাক্টর হিসাবে উপস্থিত হবে - অপ্টিমাইজার একটি শীর্ষের সাথে পরিচয় করিয়ে দেয় (বা ঘুরে বেড়ায়) যা নীচের সাবট্রিতে একটি সারি লক্ষ্য নির্ধারণ করে:

পরিকল্পনা খণ্ড

আপনি যদি ট্রেস ফ্ল্যাগটি 4138 (২০০৮ আর ২ বা তারপরে) সক্ষম করতে সক্ষম হন তবে আপনি অনুমানগুলি প্রত্যাশার সাথে আরও সারণিতে খুঁজে পেতে পারেন, বা সম্ভবত অপটিমাইজারটি নেস্টেড লুপগুলি বেছে নেবে না।

যাইহোক, আমি যা দেখছি তা হল যে মার্জ ইঙ্গিতটি সমস্ত অনুমানকে বেশ নিখুঁত করে তোলে।

এখানে ভাগ্যের একটি উপাদান জড়িত রয়েছে। লোকেরা শারীরিকভাবে সম্পাদন করার জন্য তারা যে ক্রমটি লিখেছেন বা কমপক্ষে যোগ দেয় সেগুলি লেখার ঝোঁক রয়েছে। একটি যোগদানের ইঙ্গিতটি ব্যবহারের সাথে অন্তর্ভুক্ত হয় FORCE ORDER, যার ফলে পাঠ্য রূপের সাথে মিলিত হওয়ার জন্য জয়েন্ট অর্ডারটি ঠিক করা এবং অনেক অপটিমাইজার অনুসন্ধানের নিয়মগুলি বন্ধ করে দেওয়া হয় যা কার্ডিনালিটির পুনর্নির্মাণের দিকে নিয়ে যেতে পারে।

তদ্ব্যতীত, আমি কোয়েরিটি চালানোর চেষ্টা করেছি OPTION (FORCE ORDER)- এটি প্রতিটি সংযুক্তির জন্য হ্যাশ ম্যাচটি বেছে নেওয়ার সাথে সংযুক্ত হয়ে যোগদানের চেয়ে আরও দ্রুত চলে।

এটি একটি যোগদানের ইঙ্গিত দেওয়ার সমান, তবে শারীরিক যোগদান অপারেটরের পছন্দকে সীমাবদ্ধ করে না। আবার, যদি আপনি যুক্তিযুক্ত উপায়ে ক্যোয়ারী জোড় অর্ডার লিখতে চান তবে সম্ভবত আপনি একটি যুক্তিসঙ্গত পরিকল্পনা পাবেন। অবশ্যই, আপনি এইভাবে অপ্টিমাইজারের বেশিরভাগ দক্ষতা হারাবেন, যা আরও সাধারণ পরিস্থিতিতে অনুকূল ফলাফল নাও পেতে পারে।

আপনি সম্ভবত FORCE ORDERখুব ঘন ঘন ব্যবহার করতে চাইবেন না কারণ এটি একটি অত্যন্ত শক্তিশালী ইঙ্গিত (দিকনির্দেশক) যা এর সাথে যোগ দেওয়ার ক্রমকে চাপ দেওয়ার চেয়ে সহজতর প্রভাব রয়েছে; উদাহরণস্বরূপ, এটি অপ্টিমাইজারকে একত্রিত করে এবং আংশিক সমষ্টি প্রবর্তন করে। আমি খুব ব্যতিক্রমী পরিস্থিতিতে এবং সত্যই বিশেষজ্ঞ টিউনারগুলি ব্যতীত এই ইঙ্গিতটি ব্যবহার করার বিরুদ্ধে খুব পরামর্শ দিই ।

বিশদ বিশ্লেষণে আমার কাছে এখনের চেয়ে আরও বেশি সময় প্রয়োজন, এবং কেবলমাত্র ডাটাবেসের একটি পরিসংখ্যানের অনুলিপি অ্যাক্সেস করতে হবে।


-10

বামকে যেখানে উপেক্ষা করে
কেন এটি অপ্টিমাইজারের উপর কঠোর করে তোলে?
3 বা ততোধিক সংখ্যায় অপ্টিমাইজার যোগ দেয় এবং আত্মরক্ষামূলক হয়ে যায় এবং লুপের সাথে যোগ দেয় যেরূপে স্মৃতি রক্ষা হয়
একটি যোগদানের শর্তটিও এটি একটি লুপ জয়েন্টে যেতে প্রবণতা পোষণ করে - আমার কাছে কি প্রমাণ আছে যে এটি প্রতিবার হবে - না - এখনও বাস্তবতা
একাধিক যোগদানের সাথে শর্তগুলি টান দেয় যেখানে থেকে যখন যোগ দিতে পারে তখনই

SELECT t1.id
  FROM t1
  JOIN t2 
        ON t1.id = t2.t1_id
  JOIN t3 
        ON t2.id = t3.t2_id
  JOIN t4 
        ON t3.t4_id = t4.id 
       AND t4.id = some_GUID 

বা আরও ভাল - আমি বাজি ধরছি এটি আপনার ইঙ্গিতগুলি বা বলের সাথে মিলিত হবে বা মারবে

SELECT t1.id
  FROM t1
  JOIN t2 
        ON t1.id = t2.t1_id
  JOIN t3 
        ON t2.id = t3.t2_id
       AND t3.t4_id = some_GUID

ইঙ্গিতগুলির সাথে সমস্যা হ'ল তারা কোনও নির্দিষ্ট অবস্থায় থাকা ডেটার জন্য। একটি পরিষ্কার প্রশ্ন জিজ্ঞাসা করুন এবং অনুকূলকর্মী এর কাজ করতে দিন। কিছু সময় এটি সঠিক কাজটি করার জন্য আরও পরিসংখ্যানের প্রয়োজন তবে এটি লক হয়ে যাবে।

কেন বিভিন্ন অনুমান। একটি ভিন্ন পরিকল্পনা। অনুকূলিতাকে লড়াইয়ের সুযোগ দেয় এমন প্রশ্নের সাথে শুরু করুন।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.