Analisis mendalam tentang pernyataan LIMIT dalam MySQL

Artikel ini akan membawa anda memahami pernyataan LIMIT dalam MySQL dan bercakap tentang soalan - adakah LIMIT MySQL begitu teruk? Semoga ia membantu semua orang!

Baru-baru ini, ramai kawan bertanya kepada kanak-kanak tentang LIMIT dalam kumpulan Soal Jawab Izinkan saya menerangkan secara ringkas masalah ini.

Soalan

Agar cerita berkembang dengan lancar, kita mesti terlebih dahulu mempunyai jadual:

CREATE TABLE t (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    key1 VARCHAR(100),
    common_field VARCHAR(100),
    PRIMARY KEY (id),
    KEY idx_key1 (key1)
) Engine=InnoDB CHARSET=utf8;

Jadual t mengandungi 3 lajur, lajur id ialah kunci utama, dan lajur kunci1 ialah lajur indeks sekunder. Jadual mengandungi 10,000 rekod. [Cadangan berkaitan: tutorial video mysql]

Apabila kami melaksanakan pernyataan berikut, indeks sekunder idx_key1 digunakan:

mysql>  EXPLAIN SELECT * FROM t ORDER BY key1 LIMIT 1;
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-------+
|  1 | SIMPLE      | t     | NULL       | index | NULL          | idx_key1 | 303     | NULL |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

Ini mudah difahami , kerana dalam indeks sekunder idx_key1, lajur key1 dipesan. Pertanyaannya adalah untuk mendapatkan semula rekod pertama yang diisih mengikut lajur key1 Kemudian MySQL hanya perlu mendapatkan rekod indeks sekunder pertama daripada idx_key1, dan kemudian terus kembali ke jadual untuk mendapatkan rekod lengkap.

Tetapi jika kita menggantikan LIMIT 1 dalam pernyataan di atas dengan LIMIT 5000, 1, kita perlu melakukan imbasan jadual penuh dan penyisihan fail Pelan pelaksanaan adalah seperti berikut:

mysql>  EXPLAIN SELECT * FROM t ORDER BY key1 LIMIT 5000, 1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | t     | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 9966 |   100.00 | Using filesort |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)

Sesetengah pelajar saya tidak begitu memahaminya: LIMIT 5000, 1 Anda juga boleh menggunakan indeks sekunder idx_key1 Kita boleh mengimbas rekod indeks menengah ke-5001 dahulu, dan kemudian melakukan operasi pemulangan jadual pada rekod indeks menengah ke-5001 kos pasti lebih baik daripada imbasan jadual penuh failsort.

Saya menyesal untuk memberitahu anda bahawa disebabkan oleh kelemahan pelaksanaan MySQL, situasi ideal di atas tidak akan berlaku.

Lapisan pelayan dan lapisan enjin storan

Seperti yang kita sedia maklum, MySQL sebenarnya terbahagi kepada lapisan pelayan dan lapisan enjin storan:

• Lapisan pelayan bertanggungjawab untuk mengendalikan beberapa perkara biasa, seperti pengurusan sambungan, penghuraian sintaks SQL, analisis rancangan pelaksanaan, dll.

• Lapisan enjin storan bertanggungjawab untuk khusus storan data, seperti Sama ada data disimpan dalam fail atau dalam memori, apakah format storan khusus, dsb. Kami pada asasnya menggunakan enjin storan InnoDB sekarang, dan enjin storan lain jarang digunakan, jadi kami tidak akan meliputi enjin storan lain.

Pelaksanaan pernyataan SQL dalam MySQL memperoleh hasil akhir melalui berbilang interaksi antara lapisan pelayan dan lapisan enjin storan. Contohnya, pertanyaan berikut:

SELECT * FROM t WHERE key1 > &#39;a&#39; AND key1 < &#39;b&#39; AND common_field != &#39;a&#39;;

Lapisan pelayan akan menganalisis bahawa pernyataan di atas boleh dilaksanakan menggunakan dua pilihan berikut:

• Pilihan 1: Gunakan imbasan jadual penuh

• Pilihan 2: Gunakan indeks sekunder idx_key1 Pada masa ini, anda perlu mengimbas semua rekod indeks sekunder dengan nilai lajur key1 antara ('a', 'b'. ), dan setiap rekod indeks Tahap kedua perlu dikembalikan ke jadual.

Lapisan pelayan akan menganalisis yang mana antara dua pilihan di atas adalah kos yang lebih rendah, dan kemudian memilih pilihan kos yang lebih rendah sebagai pelan pelaksanaan. Kemudian antara muka yang disediakan oleh enjin storan dipanggil untuk benar-benar melaksanakan pertanyaan.

Adalah diandaikan bahawa pilihan 2 diterima pakai, iaitu indeks sekunder idx_key1 digunakan untuk melaksanakan pertanyaan di atas. Kemudian perbualan antara lapisan pelayan dan lapisan enjin storan boleh menjadi seperti berikut:

Lapisan pelayan: "Hei, sila semak ('a', ' pada idx_key1 indeks sekunder b') Rekod pertama dalam selang, dan kemudian kembalikan rekod lengkap kepada saya selepas kembali ke jadual."

InnoDB: "Diterima, semak sekarang", dan kemudian InnoDB menggunakan sekunder idx_key1 indeks Pokok B yang sepadan dengan cepat mencari rekod indeks sekunder pertama dalam selang imbasan ('a', 'b'), dan kemudian mengembalikan jadual untuk mendapatkan rekod indeks berkelompok yang lengkap dan mengembalikannya ke lapisan pelayan.

Selepas lapisan pelayan menerima rekod indeks berkelompok yang lengkap, ia terus menilai sama ada keadaan common_field!='a' adalah benar, jika tidak, rekod itu dibuang, sebaliknya rekod itu dihantar kepada pelanggan. Kemudian katakan kepada enjin storan: "Sila berikan saya rekod seterusnya"

Petua:

Menghantar rekod kepada pelanggan di sini sebenarnya menghantarnya ke rangkaian tempatan Penampan, saiz penimbal dikawal oleh net_buffer_length, saiz lalai ialah 16KB. Tunggu sehingga penimbal penuh sebelum benar-benar menghantar paket rangkaian kepada klien.

InnoDB: "Terima, semak sekarang". InnoDB mencari rekod indeks sekunder seterusnya dalam selang ('a', 'b') idx_key1 berdasarkan atribut next_record rekod, kemudian melakukan operasi pemulangan jadual dan mengembalikan rekod indeks berkelompok lengkap ke lapisan pelayan.

小贴士：

不论是聚簇索引记录还是二级索引记录，都包含一个称作next_record的属性，各个记录根据next_record连成了一个链表，并且链表中的记录是按照键值排序的（对于聚簇索引来说，键值指的是主键的值，对于二级索引记录来说，键值指的是二级索引列的值）。

server层收到完整的聚簇索引记录后，继续判断common_field!='a'条件是否成立，如果不成立则舍弃该记录，否则将该记录发送到客户端。然后对存储引擎说：“请把下一条记录给我哈”

... 然后就不停的重复上述过程。

直到：

也就是直到InnoDB发现根据二级索引记录的next_record获取到的下一条二级索引记录不在('a', 'b')区间中，就跟server层说：“好了，('a', 'b')区间没有下一条记录了”

server层收到InnoDB说的没有下一条记录的消息，就结束查询。

现在大家就知道了server层和存储引擎层的基本交互过程了。

那LIMIT是什么鬼？

说出来大家可能有点儿惊讶，MySQL是在server层准备向客户端发送记录的时候才会去处理LIMIT子句中的内容。拿下边这个语句举例子：

SELECT * FROM t ORDER BY key1 LIMIT 5000, 1;

如果使用idx_key1执行上述查询，那么MySQL会这样处理：

• server层向InnoDB要第1条记录，InnoDB从idx_key1中获取到第一条二级索引记录，然后进行回表操作得到完整的聚簇索引记录，然后返回给server层。server层准备将其发送给客户端，此时发现还有个LIMIT 5000, 1的要求，意味着符合条件的记录中的第5001条才可以真正发送给客户端，所以在这里先做个统计，我们假设server层维护了一个称作limit_count的变量用于统计已经跳过了多少条记录，此时就应该将limit_count设置为1。

• server层再向InnoDB要下一条记录，InnoDB再根据二级索引记录的next_record属性找到下一条二级索引记录，再次进行回表得到完整的聚簇索引记录返回给server层。server层在将其发送给客户端的时候发现limit_count才是1，所以就放弃发送到客户端的操作，将limit_count加1，此时limit_count变为了2。

• ... 重复上述操作

• 直到limit_count等于5000的时候，server层才会真正的将InnoDB返回的完整聚簇索引记录发送给客户端。

从上述过程中我们可以看到，由于MySQL中是在实际向客户端发送记录前才会去判断LIMIT子句是否符合要求，所以如果使用二级索引执行上述查询的话，意味着要进行5001次回表操作。server层在进行执行计划分析的时候会觉得执行这么多次回表的成本太大了，还不如直接全表扫描+filesort快呢，所以就选择了后者执行查询。

怎么办？

由于MySQL实现LIMIT子句的局限性，在处理诸如LIMIT 5000, 1这样的语句时就无法通过使用二级索引来加快查询速度了么？其实也不是，只要把上述语句改写成：

SELECT * FROM t, (SELECT id FROM t ORDER BY key1 LIMIT 5000, 1) AS d
    WHERE t.id = d.id;

这样，SELECT id FROM t ORDER BY key1 LIMIT 5000, 1作为一个子查询单独存在，由于该子查询的查询列表只有一个id列，MySQL可以通过仅扫描二级索引idx_key1执行该子查询，然后再根据子查询中获得到的主键值去表t中进行查找。

这样就省去了前5000条记录的回表操作，从而大大提升了查询效率！

吐个槽

设计MySQL的大叔啥时候能改改LIMIT子句的这种超笨的实现呢？还得用户手动想欺骗优化器的方案才能提升查询效率~

更多编程相关知识，请访问：编程视频！！

Atas ialah kandungan terperinci Analisis mendalam tentang pernyataan LIMIT dalam MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!