এসকিউএল সার্ভার যখন এই কোয়েরিটি সাবকিউরি ব্যবহার করে তবে এটি যোগদানের সময় ব্যবহার করে না কেন চলতে গিয়ে সমান্তরালতা ব্যবহার করে? যোগদানের সংস্করণটি সিরিয়ালে চলে এবং এটি প্রায় 30 গুণ বেশি সময় নেয়।
সংস্করণে যোগদান করুন: sec 30 সেকেন্ড
সাবকিউরি সংস্করণ: <1 সেকেন্ড
সম্পাদনা: ক্যোয়ারী পরিকল্পনার এক্সএমএল সংস্করণ:
উত্তর:
মন্তব্যগুলিতে ইতিমধ্যে ইঙ্গিত হিসাবে এটি দেখে মনে হচ্ছে আপনার নিজের পরিসংখ্যান আপডেট করার প্রয়োজন আছে।
জোড়ার মধ্য থেকে বেরিয়ে আসা আনুমানিক সারিগুলির সংখ্যা locationএবং testrunsদুটি পরিকল্পনার মধ্যে চূড়ান্ত।
পরিকল্পনার অনুমানগুলিতে যোগদান করুন: 1
সাব ক্যোয়ারী পরিকল্পনার অনুমান: 8,748
যোগদানের মধ্য থেকে আসা সারিগুলির আসল সংখ্যা 14,276।
অবশ্যই এটি নিখুঁতভাবে কোনও স্বজ্ঞাত ধারণা দেয় না যে যোগদানের সংস্করণটি অনুমান করে যে 3 টি সারি এসে locationএকটি একক যোগদান করা সারি তৈরি করবে যখন সাব কোয়েরি অনুমান করে যে সেই সারিগুলির মধ্যে একটিও একই যোগ থেকে 8,748 উত্পাদন করবে তবে তবুও আমি সক্ষম হয়েছি এটি পুনরুত্পাদন করতে।
পরিসংখ্যান তৈরি করার সময় হিস্টোগ্রামগুলির মধ্যে কোনও ক্রস ওভার না থাকলে এটি ঘটতে পারে বলে মনে হয়। যোগদান সংস্করণ একটি একক সারি ধরে। এবং উপ-ক্যোয়ারীর একক সাম্যতার সন্ধান একই অংকিত সারিগুলিকে অজানা ভেরিয়েবলের বিপরীতে সমতা হিসাবে ধরে নেয়।
টেস্টরুনগুলির কার্ডিনালিটিটি 26244। ধরে নিলাম যে তিনটি পৃথক অবস্থানের আইডিতে জনবসতিযুক্ত রয়েছে তারপরে নিম্নলিখিত কোয়েরি অনুমান করে যে 8,748সারিগুলি ফিরে আসবে ( 26244/3)
declare @i int
SELECT *
FROM testruns AS tr
WHERE tr.location_id = @iপ্রদত্ত টেবিলে locationsকেবল 3 টি সারি রয়েছে এমন পরিসংখ্যান তৈরি করা সহজ (যদি আমরা কোনও বিদেশী কী না ধরে থাকি) যেখানে পরিসংখ্যান তৈরি হয় এবং তারপরে ডেটাটি এমনভাবে পরিবর্তিত করা হয় যেগুলি ফিরে আসার সারিগুলির প্রকৃত সংখ্যাকে নাটকীয়ভাবে প্রভাবিত করে তবে এটি অপর্যাপ্ত হয় পরিসংখ্যানের স্বতঃ আপডেট ট্রিপ করুন এবং থ্রেশহোল্ডটি পুনরায় কম্পাইল করুন।
যেহেতু এসকিউএল সার্ভার এতে যোগ হয় এমন সারিগুলির সংখ্যাটি এত ভুল হিসাবে যোগদানের পরিকল্পনার অন্যান্য সমস্ত সারি অনুমানকে ব্যাপকভাবে অবমূল্যায়ন করা হয়। পাশাপাশি আপনি অর্থ একটি সিরিয়াল পরিকল্পনা পেয়েছেন ক্যোয়ারী এছাড়াও একটি অপর্যাপ্ত মেমরি অনুদান এবং ধরণের এবং হ্যাশ যোগ দিতে যোগ দেয় tempdb।
আপনার পরিকল্পনায় প্রদর্শিত প্রকৃত বনাম আনুমানিক সারিগুলি পুনরুত্পাদন করার একটি সম্ভাব্য দৃশ্য নীচে রয়েছে।
CREATE TABLE location
(
id INT CONSTRAINT locationpk PRIMARY KEY,
location VARCHAR(MAX) /*From the separate filter think you are using max?*/
)
/*Temporary ids these will be updated later*/
INSERT INTO location
VALUES (101, 'Coventry'),
(102, 'Nottingham'),
(103, 'Derby')
CREATE TABLE testruns
(
location_id INT
)
CREATE CLUSTERED INDEX IX ON testruns(location_id)
/*Add in 26244 rows of data split over three ids*/
INSERT INTO testruns
SELECT TOP (5984) 1
FROM master..spt_values v1, master..spt_values v2
UNION ALL
SELECT TOP (5984) 2
FROM master..spt_values v1, master..spt_values v2
UNION ALL
SELECT TOP (14276) 3
FROM master..spt_values v1, master..spt_values v2
/*Create statistics. The location_id histograms don't intersect at all*/
UPDATE STATISTICS location(locationpk) WITH FULLSCAN;
UPDATE STATISTICS testruns(IX) WITH FULLSCAN;
/* UPDATE location.id. Three row update is below recompile threshold*/
UPDATE location
SET id = id - 100তারপরে নিম্নলিখিত প্রশ্নগুলি চালানো একই আনুমানিক বনাম প্রকৃত তাত্পর্য দেয়
SELECT *
FROM testruns AS tr
WHERE tr.location_id = (SELECT id
FROM location
WHERE location = 'Derby')
SELECT *
FROM testruns AS tr
JOIN location loc
ON tr.location_id = loc.id
WHERE loc.location = ( 'Derby' )