টেম্পডিবির ছড়িয়ে যাওয়ার সম্ভাবনা হ্রাস করার জন্য কীভাবে সারি অনুমানের উন্নতি করা যায়

Question

আমি লক্ষ্য করেছি যে যখন টেম্পিডবি ইভেন্টগুলিতে ছড়িয়ে পড়ে (ধীরে ধীরে অনুসন্ধানের কারণ হয়) যা প্রায়শই সারি অনুমানগুলি একটি নির্দিষ্ট যোগদানের জন্য বন্ধ হয়ে যায়। আমি দেখেছি যে স্পিল ইভেন্টগুলি মার্জ এবং হ্যাশ যোগদানের সাথে ঘটে থাকে এবং তারা প্রায়শই রানটাইম 3x থেকে 10x বৃদ্ধি করে। এই প্রশ্নটি কীভাবে সারি ঘটনার সম্ভাবনা হ্রাস করবে এই অনুমানের অধীনে সারি অনুমানের উন্নতি করতে পারে তা উদ্বেগ দেয়।

সারিগুলির আসল সংখ্যা 40k।

এই ক্যোয়ারির জন্য, পরিকল্পনাটি খারাপ সারি অনুমান (11.3 সারি) দেখায়:

select Value
  from Oav.ValueArray
 where ObjectId = (select convert(bigint, Value) NodeId
                     from Oav.ValueArray
                    where PropertyId = 3331  
                      and ObjectId = 3540233
                      and Sequence = 2)
   and PropertyId = 2840
option (recompile);

এই ক্যোয়ারির জন্য, পরিকল্পনাটি ভাল সারির প্রাক্কলন (56 কে সারি) দেখায়:

declare @a bigint = (select convert(bigint, Value) NodeId
                       from Oav.ValueArray
                      where PropertyId = 3331
                        and ObjectId = 3540233
                        and Sequence = 2);

select Value
  from Oav.ValueArray
 where ObjectId = @a               
   and PropertyId = 2840
option (recompile);

প্রথম ক্ষেত্রে সারি অনুমানের উন্নতি করতে পরিসংখ্যান বা ইঙ্গিতগুলি যুক্ত করা যেতে পারে? আমি নির্দিষ্ট ফিল্টার মান (সম্পত্তি = 2840) এর সাথে পরিসংখ্যান যুক্ত করার চেষ্টা করেছি তবে হয় সংমিশ্রণটি সঠিকভাবে পাওয়া যায়নি বা সম্ভবত এটি উপেক্ষা করা হচ্ছে কারণ সংকলনের সময় ObjectId অজানা এবং এটি সম্ভবত সমস্ত অবজেক্টআইডের তুলনায় একটি গড় বেছে নিচ্ছে।

এমন কোনও মোড আছে যেখানে এটি প্রথমে প্রোব ক্যোয়ারী করবে এবং তারপরে সারি অনুমানটি নির্ধারণ করতে এটি ব্যবহার করবে বা এটি অন্ধভাবে উড়তে হবে?

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

কোনও প্যারামিটার রয়েছে যা ছিটকে টেম্পডিবির সম্ভাবনা হ্রাস করতে সামঞ্জস্য করা যেতে পারে (উদাহরণস্বরূপ ক্যোয়ারি প্রতি মিনিট মেমরি)? দৃ plan় পরিকল্পনার অনুমানের কোনও প্রভাব ছিল না।

2013.11.06 সম্পাদনা করুন : মন্তব্য এবং অতিরিক্ত তথ্যের প্রতিক্রিয়া:

এখানে ক্যোয়ারী প্ল্যান চিত্রগুলি রয়েছে। সতর্কতাগুলি কার্ডিনালিটি সম্পর্কে / রূপান্তর () এর সাথে ভবিষ্যদ্বাণী নিতে চাই:

অ্যারন বার্ট্র্যান্ডের মন্তব্য অনুসারে, আমি রূপান্তর ()টিকে একটি পরীক্ষা হিসাবে প্রতিস্থাপনের চেষ্টা করেছি:

create table Oav.SeekObject (
       LookupId bigint not null primary key,
       ObjectId bigint not null
);

insert into Oav.SeekObject (
   LookupId, ObjectId
) VALUES (
   1, 3540233
) 

select Value
  from Oav.ValueArray
 where ObjectId = (select ObjectId 
                     from Oav.SeekObject 
                    where LookupId = 1)
   and PropertyId = 2840
option (recompile);

অদ্ভুত তবে সফল আগ্রহের বিষয় হিসাবে এটি এটিকে শর্ট সার্কিটের অনুসন্ধানের অনুমতি দিয়েছে:

select Value
  from Oav.ValueArray
 where ObjectId = (select ObjectId 
                     from Oav.ValueArray
                    where PropertyId = 2840
                      and ObjectId = 3540233
                      and Sequence = 2)
   and PropertyId = 2840
option (recompile);

এই উভয়টিই যথাযথ কী অনুসন্ধানের তালিকায় তবে কেবল প্রথমটিতে অবজেক্টআইডের একটি "আউটপুট" তালিকাভুক্ত করা হয়। আমি অনুমান করি যে দ্বিতীয়টি আসলে সংক্ষিপ্ত সার্কিট?

সারি অনুমানের সাহায্যে কখনও একক-সারি প্রোব সম্পাদন করা হয় কিনা তা কি কেউ যাচাই করতে পারেন? কেবলমাত্র হিস্টগ্রাম অনুমানের মধ্যে অপ্টিমাইজেশন সীমাবদ্ধ করা ভুল বলে মনে হয় যখন কোনও একক-সারি পিকে লুকোচুরি হিস্টোগ্রামে অনুসন্ধানের যথার্থতাটিকে ব্যাপকভাবে উন্নত করতে পারে (বিশেষত যদি স্পিলের সম্ভাবনা বা ইতিহাস থাকে)। যখন এগুলির মধ্যে 10 টি সত্যিকারের ক্যোয়ারিতে যোগদান করে, আদর্শভাবে সেগুলি সমান্তরালে ঘটবে।

একটি পার্শ্ব নোট, যেহেতু sql_variant ক্ষেত্রের মধ্যেই তার বেস ধরণের (এসকিউএল_ভিআরআইএনT_PROPERTY = বেস টাইপ) সংরক্ষণ করে, তাই আমি "রূপান্তরযোগ্য" (যেমন দশমিকের সাথে স্ট্রিং নয় বরং অন্তর্নিহিত) হিসাবে রূপান্তর () প্রায় ব্যয়বহুল হওয়ার প্রত্যাশা করব অন্তর্নিহিত বা সম্ভবত int যাও বিগিন্ট)। যেহেতু এটি সংকলন সময়ে জানা যায় না তবে এটি ব্যবহারকারী দ্বারা জানা হতে পারে, সম্ভবত স্কেল_ভিভারেন্টগুলির জন্য "AssumeType (টাইপ, ...)" ফাংশন তাদের আরও স্বচ্ছভাবে চিকিত্সার অনুমতি দেয় would

Comments

প্রথম অনুমানটি হ'ল বিগিন্টে রূপান্তর করা আপনার অনুমানগুলি বন্ধ করে দিচ্ছে (ক্যোয়ারী পরিকল্পনায় এসকিউএল সার্ভার ২০১২-এ এটি সম্পর্কে একটি সতর্কতা থাকবে) তবে অন্যদিকে, আপনার সাব-কোয়েরিটি 0 বা 1 টি সারি ছাড়া আর কিছুই ফেরত দিতে পারে না একটি সফল প্রশ্নের জন্য। আপনার কাছে থাকা ক্যোয়ারী পরিকল্পনাগুলি দেখতে আকর্ষণীয় হবে। সম্ভবত এক্সএমএল সংস্করণটির লিঙ্ক হিসাবে।

— মিকেল এরিকসন

সাবকিউরিয় ইনলাইন করে আপনি কী অর্জন করবেন? আমি আলাদাভাবে এটি টানতে পরামর্শ দেব সামগ্রিকভাবে পরিষ্কার, এবং যেহেতু এটি আরও ভাল অনুমানের দিকে পরিচালিত করে, তবে কেন কেবল সেই পদ্ধতিটি ব্যবহার করবেন না?

— অ্যারন বারট্র্যান্ড

এসকিউএল সার্ভারের কোন সংস্করণ? আপনি কি টেবিলগুলির জন্য টেবিল এবং সূচক ডিডিএল এবং পরিসংখ্যান ব্লবগুলি (একক এবং একাধিক কলাম) সরবরাহ করতে পারেন যাতে আমরা সমস্যার বিশদটি দেখতে পারি? declare @a bigint = আপনি যেমনটি করেছেন তেমনিভাবে কোয়েরিটি বিভক্ত করা আমার কাছে একটি প্রাকৃতিক সমাধান বলে মনে হচ্ছে, কেন এটি অগ্রহণযোগ্য?

— পল হোয়াইট 9

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

— ypercubeᵀᴹ

@ পল হোয়াইট, যতই বিচ্ছিন্ন হয়ে পড়েছে ... এই মামলার সমাধান হিসাবে এটি ঠিক। তবে আরও সাধারণ / জটিল জন্য আমি বেশিরভাগই সমান্তরালতা এবং পাঠযোগ্যতা ছেড়ে দিতে চাই না। বলুন যে এগুলির মধ্যে আমার কাছে 10 টি সাব-কোয়েরি (কিছু জটিল হিসাবে জটিল) রয়েছে তবে বাকি কোয়েরিটি শুরু হওয়ার আগে কেবল 5 টি "পাকা" হওয়া দরকার - এটি 5 টি কী তা নির্ধারণ করা এড়াতে চাই।

— ক্রোকুসেক

Answer 1

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

এবং আপনার দুটি ক্যোয়ারিতে বিভক্ত করা ভাল কারণ এটি সূচকগুলি কী কার্যকর হবে তা দেখায়। প্রথম অংশ:

(select convert(bigint, Value) NodeId
 from Oav.ValueArray
 where PropertyId = 3331  
   and ObjectId = 3540233
   and Sequence = 2)

(PropertyId, ObjectId, Sequence)অন্তর্ভুক্ত উপর একটি সূচক প্রয়োজন Value। আমি এটি UNIQUEনিরাপদ করতে চাই । একাধিক সারি ফেরত দেওয়া হলে রানটাইম চলাকালীন ক্যোয়ারিতে ত্রুটি ছুঁড়ে ফেলা হবে, সুতরাং অনন্য সূচক সহ এমনটি ঘটবে না তা আগেই নিশ্চিত করে নেওয়া ভাল:

CREATE UNIQUE INDEX
    PropertyId_ObjectId_Sequence_UQ
  ON Oav.ValueArray
    (PropertyId, ObjectId, Sequence) INCLUDE (Value) ;

প্রশ্নের দ্বিতীয় অংশ:

select Value
  from Oav.ValueArray
 where ObjectId = @a               
   and PropertyId = 2840

(PropertyId, ObjectId)অন্তর্ভুক্ত সহ একটি সূচক প্রয়োজন Value:

CREATE INDEX
    PropertyId_ObjectId_IX
  ON Oav.ValueArray
    (PropertyId, ObjectId) INCLUDE (Value) ;

যদি দক্ষতা উন্নত না হয় বা এই সূচকগুলি ব্যবহার না করা হয় বা সারি অনুমানের মধ্যে এখনও পার্থক্য দেখা যায়, তবে এই কোয়েরিতে আরও নজর দেওয়া দরকার।

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

Comments

টেবিলগুলিতে কভার সূচকগুলি ছিল - আমার প্রশ্নে এটি বলা উচিত ছিল। উদাহরণটি হ'ল একটি বৃহত্তর কোয়েরি খাওয়ানোর জন্য একটি সাব সাব জয়ডেন্ট কেন এটি কারণেই টেম্পডিবি স্পিলগুলি সম্পর্কে সমস্ত কোলাহল রয়েছে।

— ক্রোকুসেক

Answer 2

পরিসংখ্যান উন্নত করার বিষয়ে সুস্পষ্ট প্রশ্নের আংশিক উত্তর হিসাবে ...

মনে রাখবেন যে পৃথক পৃথক মামলার জন্য এমনকি সারির অনুমানগুলি এখনও 10 এক্স (4 কে বনাম প্রত্যাশিত 40 কে) বন্ধ রয়েছে।

পরিসংখ্যান হিস্টোগ্রাম সম্ভবত সেই সম্পত্তিটির জন্য খুব পাতলা ছড়িয়ে গিয়েছিল কারণ এটি একটি দীর্ঘ (উল্লম্ব), 3.5 ম সারির টেবিল এবং সেই বিশেষ সম্পত্তি অত্যন্ত বিরল।

বিচ্ছিন্ন সম্পত্তির জন্য অতিরিক্ত পরিসংখ্যান (আইএক্স পরিসংখ্যানের সাথে কিছুটা রিডানড্যান্ট) তৈরি করুন:

create statistics [STAT_ValueArray_ObjPropValue_WhereProp2840] ON [Oav].[ValueArray](ObjectId, PropertyId, Value)
where PropertyId = 2840

আসলগুলো:

রূপান্তর () সরানো (যথাযথ) সহ:

রূপান্তরিত () সরানো (শর্ট-সিরিট) সহ:

এখনও 2X ডলার ছাড়াই সম্ভবত বন্ধ রয়েছে কারণ> 99.9% অবজেক্টের এগুলিতে সম্পত্তি 2840 মোটেই সংজ্ঞায়িত হয়নি। আসলে এই পরীক্ষার ক্ষেত্রে সম্পত্তি 3.5M সারি সারণির 200k স্বতন্ত্র অবজেক্টগুলির মধ্যে 1 এ উপস্থিত রয়েছে। এটি আশ্চর্যজনক এটি সত্যিই কাছে পেয়েছিল। ফিল্টারটি কম অবজেক্টআইডস হিসাবে সামঞ্জস্য করা,

create statistics [STAT_ValueArray_ObjPropValue_WhereProp2840] ON [Oav].[ValueArray](ObjectId, PropertyId, Value)
where PropertyId = 2840 and ObjectId >= 3540000 and ObjectId < 3541000

create statistics [STAT_ValueArray_ObjPropValue_WhereProp2840] ON [Oav].[ValueArray](ObjectId, PropertyId, Value)
where PropertyId = 2840 and ObjectId = 3540233;

হুম, কোনও পরিবর্তন নেই ... পরিসংখ্যানের শেষের জন্য "সম্পূর্ণ স্ক্যান সহ" যোগ করা হয়েছে (আগের দুটি কেন কাজ করেনি এমন হতে পারে) এবং হ্যাঁ:

create statistics [STAT_ValueArray_ObjPropValue_WhereProp2840] ON [Oav].[ValueArray](ObjectId, PropertyId, Value)
where PropertyId = 2840 with full scan;

হ্যাঁ. সুতরাং বিস্তৃতভাবে IX সহ একটি উচ্চ উল্লম্ব টেবিলটিতে অতিরিক্ত ফিল্টারযুক্ত পরিসংখ্যান যুক্ত করা একটি দুর্দান্ত উন্নতি বলে মনে হচ্ছে (বিশেষত বিরল তবে অত্যন্ত বৈকল্পিক কী সংমিশ্রনের জন্য)।

Comments

মাল্টি কলাম পরিসংখ্যান সহ কিছু সমস্যাযুক্ত সমস্যার একটি লিঙ্ক ।

— ক্রোকুসেক