অর্ডারের মাধ্যমে ব্যবহারের জন্য নির্বাচিত সমস্ত কলামগুলি অবশ্যই একটি সূচককে আবৃত করতে হবে?

Question

তাই, কেউ সম্প্রতি জিজ্ঞাসা করেছেন কেন সূচকটি ব্যবহার করে অর্ডার দেওয়া হচ্ছে না?

পরিস্থিতিটি মাইএসকিউএলে একটি সাধারণ InnoDB টেবিলের সাথে জড়িত যাতে তিনটি কলাম এবং 10 কে সারি রয়েছে। কলামগুলির মধ্যে একটি, একটি পূর্ণসংখ্যার সাথে সূচকযুক্ত হয়েছিল - এবং ওপি সেই কলামটিতে সাজানো তার পুরো টেবিলটি পুনরুদ্ধার করতে চেয়েছিল:

SELECT * FROM person ORDER BY age

তিনি EXPLAINআউটপুট সংযুক্ত করে দেখিয়েছেন যে এই ক্যোয়ারীটি একটি filesort(সূচকের চেয়ে) সমাধান করা হয়েছে এবং কেন হবে তা জিজ্ঞাসা করলেন।

সত্ত্বেও ইঙ্গিতটি FORCE INDEX FOR ORDER BY (age) সূচক ঘটাচ্ছে ব্যবহার করা , কেউ উত্তর দিল যে (অন্যদের কাছ থেকে মন্তব্য / upvotes সমর্থনকারী সঙ্গে) একটি সূচক শুধুমাত্র বাছাই যখন নির্বাচিত কলামগুলির সূচক থেকে সব পড়া হয় জন্য ব্যবহার করা হয় (যেমন হিসাবে স্বাভাবিকভাবে দ্বারা নির্দেশিত করা হবে Using indexএ Extraকলাম এর EXPLAINআউটপুট)। পরে একটি ব্যাখ্যা দেওয়া হয়েছিল যে সূচকটি অনুসরণ করে এবং তারপরে টেবিল থেকে কলামগুলি আনার ফলে এলোমেলো I / O ফলাফল আসে যা মাইএসকিউএল এ এর ​​চেয়ে বেশি ব্যয়বহুল হিসাবে দেখায় filesort।

এটি ORDER BYঅপ্টিমাইজেশানের ম্যানুয়াল অধ্যায়ের মুখে উড়ে যায় বলে মনে হয় , যা কেবলমাত্র দৃ the় ধারণাটিই প্রকাশ করে না যে ORDER BYসূচক থেকে সন্তুষ্ট করা অতিরিক্ত বাছাই করা পছন্দনীয় (প্রকৃতপক্ষে, filesortকুইকোর্ট এবং সংহতকরণের সংমিশ্রণ এবং তাই অবশ্যই এর নীচে আবদ্ধ হওয়া আবশ্যক ) ; যখন সূচকে যথাযথভাবে চলতে হবে এবং সারণিতে সন্ধান করা উচিত তা হওয়া উচিত this সুতরাং এটি সঠিকভাবে বোঝা যায়), তবে এটি এই কথিত "অপ্টিমাইজেশান" উল্লেখ করার ক্ষেত্রে অবহেলাও করে:Ω(nlog n)O(n)

নিম্নলিখিত সমাধানগুলি ORDER BYঅংশটি সমাধান করতে সূচি ব্যবহার করে :

SELECT * FROM t1
  ORDER BY key_part1,key_part2,... ;

আমার পড়া মতে, এই পরিস্থিতিতে অবিকল এটি (এখনও সূচকটি সুস্পষ্ট ইঙ্গিত ছাড়াই ব্যবহার করা হয়নি)।

আমার প্রশ্নগুলি হ'ল:

• মাইএসকিউএল সূচকটি ব্যবহারের জন্য পছন্দ করার জন্য সমস্ত নির্বাচিত কলামগুলি ইন্ডেক্স করা প্রয়োজন?

  • যদি তা হয় তবে এই নথিটি কোথায় আছে (যদি তা হয়)

  • তা না হলে এখানে কী চলছে?

Answer 1

মাইএসকিউএল সূচকটি ব্যবহারের জন্য পছন্দ করার জন্য সমস্ত নির্বাচিত কলামগুলি ইন্ডেক্স করা প্রয়োজন?

এটি একটি ভারী প্রশ্ন, কারণ এমন কোনও কারণ রয়েছে যা নির্ধারণ করে যে কোনও সূচক ব্যবহার করা উচিত কিনা।

ফ্যাক্টর # 1

প্রদত্ত যে কোনও সূচকের জন্য মূল জনসংখ্যা কত? অন্য কথায়, সূচকে রেকর্ড করা সমস্ত টিপলের কার্ডিনালিটি (স্বতন্ত্র গণনা) কী?

ফ্যাক্টর # 2

আপনি কোন স্টোরেজ ইঞ্জিন ব্যবহার করছেন? সমস্ত প্রয়োজনীয় কলামগুলি কি কোনও সূচক থেকে অ্যাক্সেসযোগ্য?

এরপর কি ???

আসুন একটি সহজ উদাহরণ গ্রহণ করুন: একটি সারণী যা দুটি মান ধরে রাখে (পুরুষ এবং মহিলা)

সূচক ব্যবহারের জন্য একটি পরীক্ষা দিয়ে এই জাতীয় একটি টেবিল তৈরি করুন

USE test
DROP TABLE IF EXISTS mf;
CREATE TABLE mf
(
    id int not null auto_increment,
    gender char(1),
    primary key (id),
    key (gender)
) ENGINE=InnODB;
INSERT INTO mf (gender) VALUES
('M'),('M'),('M'),('M'),('M'),('M'),('M'),('M'),
('M'),('M'),('M'),('M'),('F'),('F'),('M'),('M'),
('M'),('M'),('M'),('M'),('M'),('M'),('M'),('M'),
('M'),('M'),('M'),('M'),('M'),('M'),('M'),('M'),
('F'),('M'),('M'),('M'),('M'),('M'),('M'),('M');
ANALYZE TABLE mf;
EXPLAIN SELECT gender FROM mf WHERE gender='F';
EXPLAIN SELECT gender FROM mf WHERE gender='M';
EXPLAIN SELECT id FROM mf WHERE gender='F';
EXPLAIN SELECT id FROM mf WHERE gender='M';

পরীক্ষা ইনোডিবি

mysql> USE test
Database changed
mysql> DROP TABLE IF EXISTS mf;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE mf
    -> (
    ->     id int not null auto_increment,
    ->     gender char(1),
    ->     primary key (id),
    ->     key (gender)
    -> ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.07 sec)

mysql> INSERT INTO mf (gender) VALUES
    -> ('M'),('M'),('M'),('M'),('M'),('M'),('M'),('M'),
    -> ('M'),('M'),('M'),('M'),('F'),('F'),('M'),('M'),
    -> ('M'),('M'),('M'),('M'),('M'),('M'),('M'),('M'),
    -> ('M'),('M'),('M'),('M'),('M'),('M'),('M'),('M'),
    -> ('F'),('M'),('M'),('M'),('M'),('M'),('M'),('M');
Query OK, 40 rows affected (0.06 sec)
Records: 40  Duplicates: 0  Warnings: 0

mysql> ANALYZE TABLE mf;
+---------+---------+----------+----------+
| Table   | Op      | Msg_type | Msg_text |
+---------+---------+----------+----------+
| test.mf | analyze | status   | OK       |
+---------+---------+----------+----------+
1 row in set (0.00 sec)

mysql> EXPLAIN SELECT gender FROM mf WHERE gender='F';
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                    |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
|  1 | SIMPLE      | mf    | ref  | gender        | gender | 2       | const |    3 | Using where; Using index |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
1 row in set (0.00 sec)

mysql> EXPLAIN SELECT gender FROM mf WHERE gender='M';
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                    |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
|  1 | SIMPLE      | mf    | ref  | gender        | gender | 2       | const |   37 | Using where; Using index |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
1 row in set (0.00 sec)

mysql> EXPLAIN SELECT id FROM mf WHERE gender='F';
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                    |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
|  1 | SIMPLE      | mf    | ref  | gender        | gender | 2       | const |    3 | Using where; Using index |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
1 row in set (0.00 sec)

mysql> EXPLAIN SELECT id FROM mf WHERE gender='M';
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                    |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
|  1 | SIMPLE      | mf    | ref  | gender        | gender | 2       | const |   37 | Using where; Using index |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
1 row in set (0.00 sec)

mysql>

মাইসাম পরীক্ষা

mysql> USE test
Database changed
mysql> DROP TABLE IF EXISTS mf;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE mf
    -> (
    ->     id int not null auto_increment,
    ->     gender char(1),
    ->     primary key (id),
    ->     key (gender)
    -> ) ENGINE=MyISAM;
Query OK, 0 rows affected (0.05 sec)

mysql> INSERT INTO mf (gender) VALUES
    -> ('M'),('M'),('M'),('M'),('M'),('M'),('M'),('M'),
    -> ('M'),('M'),('M'),('M'),('F'),('F'),('M'),('M'),
    -> ('M'),('M'),('M'),('M'),('M'),('M'),('M'),('M'),
    -> ('M'),('M'),('M'),('M'),('M'),('M'),('M'),('M'),
    -> ('F'),('M'),('M'),('M'),('M'),('M'),('M'),('M');
Query OK, 40 rows affected (0.00 sec)
Records: 40  Duplicates: 0  Warnings: 0

mysql> ANALYZE TABLE mf;
+---------+---------+----------+----------+
| Table   | Op      | Msg_type | Msg_text |
+---------+---------+----------+----------+
| test.mf | analyze | status   | OK       |
+---------+---------+----------+----------+
1 row in set (0.00 sec)

mysql> EXPLAIN SELECT gender FROM mf WHERE gender='F';
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                    |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
|  1 | SIMPLE      | mf    | ref  | gender        | gender | 2       | const |    3 | Using where; Using index |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
1 row in set (0.00 sec)

mysql> EXPLAIN SELECT gender FROM mf WHERE gender='M';
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                    |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
|  1 | SIMPLE      | mf    | ref  | gender        | gender | 2       | const |   36 | Using where; Using index |
+----+-------------+-------+------+---------------+--------+---------+-------+------+--------------------------+
1 row in set (0.00 sec)

mysql> EXPLAIN SELECT id FROM mf WHERE gender='F';
+----+-------------+-------+------+---------------+--------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra       |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-------------+
|  1 | SIMPLE      | mf    | ref  | gender        | gender | 2       | const |    3 | Using where |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-------------+
1 row in set (0.00 sec)

mysql> EXPLAIN SELECT id FROM mf WHERE gender='M';
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | mf    | ALL  | gender        | NULL | NULL    | NULL |   40 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)

mysql>

InnoDB এর জন্য বিশ্লেষণ

যখন ডেটা ইনোডিবি হিসাবে লোড করা হয়েছিল, দয়া করে নোট করুন যে চারটি EXPLAINপরিকল্পনাই genderসূচকটি ব্যবহার করেছিল । তৃতীয় এবং চতুর্থ EXPLAINপরিকল্পনাগুলি genderঅনুরোধ করা ডেটা থাকলেও সূচকটি ব্যবহার করেছিল id। কেন? কারণ idরয়েছে PRIMARY KEYএবং সব মাধ্যমিক সূচী আছে রেফারেন্স পয়েন্টার ফিরে PRIMARY KEY(মাধ্যমে gen_clust_index )।

মাইআইএসএএম এর জন্য বিশ্লেষণ

যখন ডেটা মাইআইএসএএম হিসাবে লোড করা হয়েছিল, দয়া করে নোট করুন যে প্রথম তিনটি EXPLAINপরিকল্পনা genderসূচি ব্যবহার করেছিল । চতুর্থ EXPLAINপরিকল্পনায় ক্যোয়ারী অপ্টিমাইজার মোটেও একটি সূচক ব্যবহার না করার সিদ্ধান্ত নিয়েছে। পরিবর্তে এটি একটি পূর্ণ টেবিল স্ক্যান বেছে নিয়েছে। কেন?

ডিবিএমএস নির্বিশেষে, কোয়েরি অপ্টিমাইজারগুলি একটি খুব সাধারণ নিয়ম-এর-থাম্বটিতে কাজ করে: যদি কোনও সূচকটি পরীক্ষার জন্য পরীক্ষার জন্য প্রার্থী হিসাবে স্ক্রিন করা হয় এবং ক্যোরি অপটিমাইজার গণনা করে যে এটি অবশ্যই মোট সংখ্যার 5% এর বেশি দেখতে হবে সারণীতে সারি:

• পুনরুদ্ধারের জন্য প্রয়োজনীয় সমস্ত কলামগুলি নির্বাচিত সূচীতে থাকলে একটি পূর্ণ সূচক স্ক্যান করা হয়
• অন্যথায় একটি সম্পূর্ণ টেবিল স্ক্যান

উপসংহার

আপনার যদি সঠিক কভারিং সূচক না থাকে বা যদি কোনও প্রদত্ত টুপলের মূল জনসংখ্যা সারণির 5% এর বেশি হয় তবে ছয়টি জিনিস অবশ্যই ঘটবে:

1. অনুধাবনে আসুন যে আপনাকে অবশ্যই প্রশ্নগুলি প্রোফাইল করতে হবে
2. এই অনুসন্ধানগুলি থেকে সমস্ত WHERE, GROUP BYএবং অর্ডার বাই-ক্লজগুলি সন্ধান করুন
3. এই ক্রমে সূচকগুলি সূচনা করুন
   • WHERE স্থির মান সহ ধারা কলাম
   • GROUP BY কলাম
   • ORDER BY কলাম
4. পূর্ণ টেবিল স্ক্যানগুলি এড়িয়ে চলুন (কোনও বুদ্ধিমান WHEREধারার অভাবে প্রশ্নগুলি )
5. খারাপ কী জনসংখ্যা এড়িয়ে চলুন (বা কমপক্ষে সেই খারাপ কী জনসংখ্যা ক্যাশে করুন)
6. সেরা মাইএসকিউএল সংগ্রহস্থল ইঞ্জিন (স্থির InnoDB বা MyISAM টেবিল জন্য)

আমি অতীতে এই 5% নিয়মের সম্পর্কে লিখেছি:

• May 07, 2012: মাইএসকিউএল বর্ণিত ফুলটেক্সটের জন্য 'ব্যবহার সূচক' দেখায় না
• Mar 22, 2012: মাইএসকিউএল এই কার্যকর করার পরিকল্পনাটি কেন নির্বাচন করে?
• Mar 09, 2012: সূচক ব্যবহার হচ্ছে না
• Jan 18, 2012: মাইএসকিউএল স্ট্যাটাস ভেরিয়েবল হ্যান্ডলার_আর_আরঙ্ক_নেক্সট অনেক বাড়ছে
• Dec 27, 2011: মাইএসকিউএল - ইনোডিবি-র জন্য টেবিল পরিবর্তন করার দ্রুততম উপায়
• Jul 29, 2011: মাইএসকিউএল ক্যোরি অপটিমাইজেশন: ইনডেক্সিং এবং পৃষ্ঠাগুলি
• Jul 12, 2011: কোনও সূচক / কী থাকা সত্ত্বেও WHERE ক্ষেত্রটি পরিবর্তন করার সময় মাইএসকিউএল খুব ধীর ক্যোয়ারী

আপডেট 2012-11-14 13:05 ইডিটি

আমি আপনার প্রশ্ন এবং মূল এসও পোস্টে ফিরে তাকান । তারপরে, আমি আমার Analysis for InnoDBআগে উল্লিখিত আমার সম্পর্কে ভেবেছিলাম । এটি personটেবিলের সাথে মিলে যায় । কেন?

উভয় টেবিলের জন্য mfএবংperson

• স্টোরেজ ইঞ্জিনটি ইনোডিবি
• প্রাথমিক কী id
• সারণী অ্যাক্সেস মাধ্যমিক সূচক দ্বারা হয়
• যদি টেবিলটি মাইআইএসএএম হয় তবে আমরা সম্পূর্ণ ভিন্ন EXPLAINপরিকল্পনা দেখতে পেতাম

এখন, তাই প্রশ্ন থেকে ক্যোয়ারী তাকান: select * from person order by age\G। যেহেতু কোনও WHEREধারা নেই, আপনি স্পষ্টভাবে একটি পূর্ণ টেবিল স্ক্যানের দাবি করেছেন । টেবিলের ডিফল্ট সাজানোর ক্রমটি (id PRYARY KEY) দ্বারা হবে কারণ এটি অটো_সংশ্লিষ্ট এবং জেন_ ক্লাস্ট_ইন্ডেক্স (ওরফে ক্লাস্টারড ইনডেক্স) অভ্যন্তরীণ রোউইড দ্বারা আদেশ করা হয়েছে । আপনি যখন সূচক দ্বারা আদেশ করেছেন, তখন মনে রাখবেন যে ইনোডিবি মাধ্যমিক সূচকগুলিতে প্রতিটি সূচী প্রবেশের সাথে সারি সংযুক্ত থাকে। এটি প্রতিবার সম্পূর্ণ সারি অ্যাক্সেসের অভ্যন্তরীণ প্রয়োজনীয়তা তৈরি করে।

ORDER BYইনোডিবি সূচকগুলি কীভাবে সংগঠিত হয় সে সম্পর্কে যদি আপনি এই বিষয়গুলি উপেক্ষা করেন তবে একটি ইনোডিবি টেবিল সেট আপ করা বরং একটি কঠিন কাজ হতে পারে।

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

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

আপডেট 2012-11-14 14:21 ইডিটি

মাইএসকিউএল ইন্টার্নালগুলি বোঝার বই অনুসারে

পৃষ্ঠা 202 অনুচ্ছেদ 7 নিম্নলিখিতটি বলেছে:

ডেটাগুলি একটি ক্লাস্টারড ইনডেক্স নামে একটি বিশেষ কাঠামোতে সংরক্ষণ করা হয় , যা মূল-মূল হিসাবে কাজ করা প্রাথমিক কী সহ একটি বি-ট্রি এবং ডেটা অংশে প্রকৃত রেকর্ড (পয়েন্টারের পরিবর্তে) থাকে। সুতরাং, প্রতিটি InnoDB টেবিলের একটি প্রাথমিক কী থাকতে হবে। যদি কোনও সরবরাহ না করা হয় তবে একটি বিশেষ সারি আইডি কলাম প্রাথমিকভাবে ব্যবহারকারী হিসাবে প্রদর্শিত হয় না যা প্রাথমিক কী হিসাবে কাজ করার জন্য যুক্ত করা হয় to একটি মাধ্যমিক কী প্রাথমিক কীটির মান সংরক্ষণ করবে যা রেকর্ডটি সনাক্ত করে। বি-ট্রি কোড ইনোএনবেস / বিটিআর / বিটিআর0 বিটিআর.সি . তে পাওয়া যাবে ।

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

Comments

রোল্যান্ডো, এরকম একটি বিশদ এবং বিস্তারিত উত্তরের জন্য আপনাকে ধন্যবাদ। তবে এটি সূচী বাছাইয়ের ক্ষেত্রে প্রাসঙ্গিক বলে মনে হচ্ছে না FOR ORDER BY(যা এই প্রশ্নের নির্দিষ্ট ক্ষেত্রে)। প্রশ্নটি বলেছিল যে এক্ষেত্রে স্টোরেজ ইঞ্জিনটি ছিল InnoDB(এবং মূল এসও প্রশ্নটি দেখায় যে 10 কে সারিগুলি 8 টি আইটেমের মধ্যে মোটামুটি সমানভাবে বিতরণ করা হয়েছে, কার্ডিনালিটি এখানে কোনও সমস্যা হওয়া উচিত নয়)। দুঃখের বিষয়, আমি মনে করি না যে এটি প্রশ্নের উত্তর দেয়।

— উদ্বিগ্ন

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

— ডেরেক ডউনি

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

— রোল্যান্ডোমাইএসকিউএলডিবিএ

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

— ডেরেক ডাউনি

@eggyal এই এই সপ্তাহে লেখা হয়েছিল। একই বর্ণিত পরিকল্পনাটি লক্ষ্য করুন এবং ডেটাসেটের মেমরিতে ফিট না হলে পুরো স্ক্যানটি বেশি সময় নেয়।

— ডেরেক ডউনি

Answer 2

ডেনিসের এসও-তে অন্য প্রশ্নের উত্তর থেকে অভিযোজিত (অনুমতি সহ) :

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

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

কেন তা বুঝতে, ডিস্কে আই / ও জড়িত চিত্রটি চিত্রিত করুন।

মনে করুন আপনি কোনও সূচি ছাড়াই পুরো টেবিলটি চান। এটি করার জন্য, আপনি টেবিলের শেষে না পৌঁছানো অবধি ক্রমে জড়িত বিভিন্ন ডিস্ক পৃষ্ঠাগুলি পরিদর্শন করে ডেটা_পেজ 1, ডেটা_পেজ 2, ডেটা_পেজ 3 ইত্যাদি পড়েন। আপনি তারপর বাছাই এবং ফিরে।

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

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

আপনি যদি কেবল সূচকযুক্ত টেবিলের শীর্ষ 5 সারি চান, তবে বিপরীতে, সূচকটি ব্যবহার করা সঠিক কৌশল হয়ে যায়। সবচেয়ে খারাপ পরিস্থিতিতে আপনি মেমরিতে 5 টি ডেটা পৃষ্ঠা লোড করে এগিয়ে যান on

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

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