সিটিই, সাব-কোয়েরি, অস্থায়ী টেবিল বা টেবিল ভেরিয়েবলের মধ্যে পারফরম্যান্সের পার্থক্য রয়েছে কি?

Question

এই দুর্দান্ত এসও প্রশ্নে , মধ্যে পার্থক্য CTEএবং sub-queriesআলোচনা করা হয়েছিল।

আমি বিশেষভাবে জিজ্ঞাসা করতে চাই:

কোন পরিস্থিতিতে নিম্নলিখিত প্রতিটি আরও কার্যকর / দ্রুত হয়?

• কোটে
• উপ-ক্যোয়ারী
• অস্থায়ী টেবিল
• টেবিল পরিবর্তনশীল

Ditionতিহ্যগতভাবে, আমি temp tablesবিকাশে প্রচুর ব্যবহার করেছি stored procedures- যেহেতু এগুলি আন্তঃবিবাহিত সাব-কোয়েরির চেয়ে অনেক বেশি পঠনযোগ্য বলে মনে হয়।

Non-recursive CTEs ডেটাগুলির সেটগুলি খুব ভালভাবে encapsulate করে, এবং খুব পঠনযোগ্য, তবে কোনও নির্দিষ্ট পরিস্থিতি রয়েছে যেখানে কেউ বলতে পারে যে তারা সবসময় আরও ভাল সম্পাদন করবে? বা সর্বাধিক দক্ষ সমাধানের জন্য বিভিন্ন বিকল্পের সাথে সর্বদা ঝাঁকুনির মতো অবস্থা?

---

সম্পাদনা

আমাকে সম্প্রতি বলা হয়েছে যে দক্ষতার দিক থেকে অস্থায়ী টেবিলগুলি প্রথম পছন্দ হিসাবে ভাল কারণ তারা সম্পর্কিত হিস্টোগ্রাম অর্থাৎ পরিসংখ্যান রয়েছে।

Comments

সাধারণ উত্তর: এটি নির্ভর করে। এবং এটি বেশ কয়েকটি কারণের উপর নির্ভর করে, কোনও সাধারণ বিবৃতি সম্ভবত মিথ্যা - কিছু পরিস্থিতিতে। মূলত: আপনাকে পরীক্ষা এবং পরিমাপ করা দরকার - দেখুন যা আপনার পক্ষে সবচেয়ে ভাল কাজ করে!

— marc_s

@মার্ক_স - ঠিক আছে; সাবজেক্টিভ হওয়ার কারণে এই প্রশ্নটি বন্ধ করা উচিত? আপনাকে SO- এর অনেকগুলি এসকিউএল প্রশ্নকে বিষয়ভিত্তিক হিসাবে বিবেচনা করা যেতে পারে।

— কেন

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

— marc_s

@মার্ক_স চেষ্টা করা এবং রাখা ভাল হবে - ওপিকে আরও সুনির্দিষ্ট এবং সংকীর্ণ করার চেষ্টা করার জন্য সম্ভাব্য সম্পাদনার বিষয়ে কোনও পরামর্শ?

— কেন

দয়া করে নোট করুন যে এই প্রশ্নটি এসকিউএল সার্ভারের সাথে নির্দিষ্ট। পোস্টগ্রিসের মতো অন্যান্য ডিবিগুলির জন্য, একটি সিটিই প্রায়শই সমতুল্য সাবকোয়ারির তুলনায় অনেক ধীর হয় (দেখুন http://blog.2ndquadrant.com/postgresql-ctes-are-optimization-fences/ )

— জয়

Answer 1

এসকিউএল একটি ঘোষণামূলক ভাষা, পদ্ধতিগত ভাষা নয়। এটি, আপনি যে ফলাফল চান তা বর্ণনা করতে আপনি একটি এসকিউএল স্টেটমেন্টটি তৈরি করেন। কীভাবে কাজ করবেন তা আপনি এসকিউএল ইঞ্জিনকে বলছেন না।

একটি সাধারণ নিয়ম হিসাবে, এসকিউএল ইঞ্জিন এবং এসকিউএল অপ্টিমাইজারকে সর্বোত্তম ক্যোয়ারী প্ল্যানটি সন্ধান করা ভাল ধারণা। অনেকগুলি ব্যক্তি-বছরের প্রচেষ্ট রয়েছে যা একটি এসকিউএল ইঞ্জিন বিকাশে যায়, তাই ইঞ্জিনিয়াররা তাদের কীভাবে কী করতে হয় তা কী তা করতে দিন।

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

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

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

আপনার প্রশ্নের উত্তর হ'ল আপনার প্রত্যাশা করা পারফরম্যান্স পেতে আপনার বিশেষভাবে খেলা উচিত, বিশেষত নিয়মিতভাবে চালানো জটিল প্রশ্নের জন্য। একটি আদর্শ বিশ্বে ক্যোয়ারী অপ্টিমাইজার সঠিক প্রয়োগের পথ খুঁজে পাবে path যদিও এটি প্রায়শই হয়, আপনি আরও ভাল পারফরম্যান্স পাওয়ার উপায় খুঁজে পেতে সক্ষম হতে পারেন।

Comments

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

— মার্টিন স্মিথ

সেই কাগজটি 2007 সালে উপস্থাপিত হয়েছিল তা দেওয়া, তারা এসকিউএল সার্ভার 2012 এ এটি অন্তর্ভুক্ত করেছে কিনা সে সম্পর্কে কোনও ধারণা?

— গর্ডন লিনফ

দুর্দান্ত উত্তর! কেবল জোর দেওয়ার জন্য: এসকিউএল একটি ঘোষণামূলক ভাষা এবং আমরা কীভাবে ডেটা টানা হয় তা নিয়ন্ত্রণ করি না। সুতরাং, কর্মক্ষমতা / গতি ক্যোয়ারী থেকে ক্যোয়ারিতে পরিবর্তিত হয়।

— সিমচা খাবিনস্কি

@ আরজিএস । । স্থায়ী টেবিলের সূচি অনুসারে অস্থায়ী সারণীতে সূচীগুলি অবশ্যই সেই প্রশ্নের উন্নতি করে যেগুলি সেই সূচকগুলির সুবিধা নিতে পারে। তবে, যদি আপনি একটি অস্থায়ী টেবিল হিসাবে সাবকিউরিটি তৈরি করেন তবে আপনি মূল টেবিলগুলিতে সূচকের সুবিধা হারাতে পারেন।

— গর্ডন লিনফ 22

@ আরজিএস । .কখন একটি ডাটাবেস ইঞ্জিন একটি জটিল ক্যোয়ারি সম্পাদন করার সময় একটি সাবকিউরি / সিটিইতে পদার্থ সরবরাহ করে, তখন এটি বস্তুকরণে সূচক যুক্ত করে না। অস্থায়ী টেবিলগুলি ব্যবহার করে আপনি নিজে এটি করতে পারেন।

— গর্ডন লিনফ

Answer 2

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

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

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

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

Comments

+1 পরিণত হওয়াই যথেষ্ট বিষয়গত প্রশ্ন হতে পারে; আমি আশা করি যে এটি এতটা অস্পষ্ট হওয়ার কারণে বন্ধ হয়ে যাবে না কারণ উত্তরগুলি এখন পর্যন্ত তথ্যবহুল। আমি উপলব্ধি :-) প্রশ্নগুলি পরিবর্তিত হলে আপনি এটি পছন্দ করেন না তবে প্রশ্নটিতে সংকীর্ণ হওয়ার জন্য আপনার কাছে কি কোনও পরামর্শ আছে?

— কেন

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

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

আপনার প্রশ্নের ঠিক নীচে লিঙ্ক রয়েছে link / edit / close / flag- প্রশ্নটি বন্ধ করার জন্য যদি কোনও ভোট থাকে, আপনি দেখতে পাবেন যে আপনার প্রশ্নটি বন্ধ করার পক্ষে ভোটদানকারী ব্যবহারকারীদের সংখ্যাটি close (n)কোথায় nউপস্থাপন করে। আপনি যদি লিঙ্কটিতে ক্লিক করেন তবে আপনি ব্যবহারকারীদের নির্বাচিত কারণগুলি দেখতে পাবেন।

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

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

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

উপরের স্থির লিঙ্ক: sqlskills.com/blogs/bob/…

— এডিজেঙ্কস

Answer 3

# টেম্প materalized এবং সিটিই হয় না।

সিটিই কেবল সিনট্যাক্স তাই তত্ত্বের ক্ষেত্রে এটি কেবল একটি উপশক্তি। এটি কার্যকর করা হয়। # টিম্প বস্তুগত হয়। সুতরাং একটি যোগদানের জন্য একটি ব্যয়বহুল সিটিই যা বহুবার কার্যকর করা হয় # টেম্পে ভাল হতে পারে। অন্যদিকে যদি এটি একটি সহজ মূল্যায়ন হয় যা কার্যকর হয় না তবে কয়েকবার হয় তবে # টেম্পের ওভারহেডের মূল্য নেই।

এসও-তে এমন কিছু লোক যা টেবিলের পরিবর্তনশীল পছন্দ করে না তবে আমি তাদের পছন্দ করি কারণ # টেেম্পের চেয়ে তৈরি করা দ্রুততর এবং দ্রুত হয়। এমন সময়গুলি আসে যখন সারণী ভেরিয়েবলের তুলনায় ক্যোরি অপটিমাইজারটি # টেম্পের সাথে আরও ভাল করে।

একটি # টেম্প বা টেবিল ভেরিয়েবলে একটি পিকে তৈরি করার ক্ষমতা কোয়েরি অপ্টিমাইজারকে সিটিইর চেয়ে বেশি তথ্য দেয় (কারণ আপনি কোনও সিটিইতে পিকে ঘোষণা করতে পারবেন না)।

Comments

"টিভিপি" সংক্ষিপ্ত রূপটি কী ... # টেম্পের অনুরূপ কিছু?

— কেন

টিভিপি একটি সাধারণ শব্দ হয়ে উঠছে, কারণ এটি চিত্তাকর্ষক বলে মনে হচ্ছে (কারও কারও কাছে)। সংক্ষেপে, একটি টিভিপি প্যারামিটার হিসাবে পাস একটি টেবিল। যে কেউ টেবিলের ভেরিয়েবল ব্যবহার করেছেন সে ঠিক সে বাড়িতেই থাকবে।

— ওয়ান্ডার ওয়ার্কার

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

— হিলিয়াক

Answer 4

আমার মনে হয় মাত্র 2 টি জিনিস একটি # টেম্প টেবিল ব্যবহার করা সবসময়ই পছন্দনীয় করে তোলে তারপরে কোনও সিটিই হ'ল:

1. আপনি কোনও সিটিইতে একটি প্রাথমিক কী রাখতে পারবেন না তাই সিটিই দ্বারা অ্যাক্সেস করা ডেটা সিটিইর টেবিলের প্রতিটি সূচকে অনুসরণ করতে হবে তবে কেবল টেম্প টেবিলের পিকে বা সূচি অ্যাক্সেস করতে হবে।

2. আপনি কোনও সিটিইতে সীমাবদ্ধতা, সূচী এবং প্রাথমিক কীগুলি যুক্ত করতে পারবেন না কারণ এগুলি বাগের ক্রাইপিং এবং খারাপ ডেটার ঝুঁকিতে বেশি।

---

গতকাল

এখানে একটি উদাহরণ যেখানে # টেবিলের সীমাবদ্ধতাগুলি খারাপ ডেটা রোধ করতে পারে যা সিটিই-র ক্ষেত্রে নয়

DECLARE @BadData TABLE ( 
                       ThisID int
                     , ThatID int );
INSERT INTO @BadData
       ( ThisID
       , ThatID
       ) 
VALUES
       ( 1, 1 ),
       ( 1, 2 ),
       ( 2, 2 ),
       ( 1, 1 );

IF OBJECT_ID('tempdb..#This') IS NOT NULL
    DROP TABLE #This;
CREATE TABLE #This ( 
             ThisID int NOT NULL
           , ThatID int NOT NULL
                        UNIQUE(ThisID, ThatID) );
INSERT INTO #This
SELECT * FROM @BadData;
WITH This_CTE
     AS (SELECT *
           FROM @BadData)
     SELECT *
       FROM This_CTE;

Comments

ALWAYSকিছুটা দূরে কিন্তু উত্তরের জন্য ধন্যবাদ। পাঠযোগ্যতার দিক থেকে সিটিই ব্যবহার করা ভাল জিনিস হতে পারে।

— কেন

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

— onedaywhen