Jawaban singkatnya adalah ya, kunci utama memiliki urutan, semua indeks memiliki urutan, dan kunci utama hanyalah indeks unik.
Seperti yang Anda katakan dengan benar, Anda tidak boleh bergantung pada data yang dikembalikan dalam urutan penyimpanan data, pengoptimal bebas untuk mengembalikannya dalam urutan apa pun yang diinginkan, dan ini akan tergantung pada rencana kueri. Namun saya akan mencoba menjelaskan mengapa kueri Anda berhasil selama 12 tahun.
Indeks berkerumun Anda hanyalah data tabel Anda, dan kunci pengelompokan Anda menentukan urutan penyimpanannya. Data disimpan di daun, dan kunci pengelompokan membantu root (dan catatan perantara) bertindak sebagai penunjuk untuk dengan cepat sampai ke daun kanan untuk mengambil data. Indeks nonclustered adalah struktur yang sangat mirip, tetapi level terendah hanya berisi penunjuk ke posisi yang benar pada daun indeks clustered.
Di MySQL kunci utama dan indeks berkerumun adalah sinonim, jadi kunci utama dipesan, namun pada dasarnya adalah dua hal yang berbeda. Di DBMS lain, Anda dapat menentukan baik kunci utama maupun indeks berkerumun, ketika Anda melakukan ini, kunci utama Anda menjadi indeks non-cluster yang unik dengan penunjuk kembali ke indeks berkerumun.
Dalam istilah yang paling sederhana, Anda dapat membayangkan sebuah tabel dengan kolom ID yang merupakan kunci utama, dan kolom lain (A), struktur B-Tree Anda untuk indeks berkerumun Anda akan menjadi seperti:
Root Node
+---+
| 1 |
+---+
Intermediate Nodes
+---+ +---+ +---+
| 1 | | 4 | | 7 |
+---+ +---+ +---+
Leaf
+-----------+ +-----------+ +-----------+
ID -> | 1 | 2 | 3 | | 4 | 5 | 6 | | 7 | 8 | 9 |
A -> | A | B | C | | D | E | F | | G | H | I |
+-----------+ +-----------+ +-----------+
Pada kenyataannya halaman daun akan jauh lebih besar, tetapi ini hanya demo. Setiap halaman juga memiliki penunjuk ke halaman berikutnya dan halaman sebelumnya untuk kemudahan melintasi pohon. Jadi ketika Anda melakukan kueri seperti:
SELECT ID, A
FROM T
WHERE ID > 5
LIMIT 1;
Anda memindai indeks unik sehingga kemungkinan besar ini akan menjadi pemindaian berurutan. Sangat mungkin tidak dijamin.
MySQL akan memindai node Root, jika ada potensi kecocokan maka akan pindah ke node perantara, jika klausanya seperti WHERE ID < 0 maka MySQL akan mengetahui bahwa tidak ada hasil tanpa melangkah lebih jauh dari node root.
Setelah berpindah ke node perantara, ia dapat mengidentifikasi bahwa ia perlu memulai pada halaman kedua (antara 4 dan 7) untuk mulai mencari ID > 5 . Jadi secara berurutan akan memindai daun mulai dari halaman daun kedua, setelah mengidentifikasi LIMIT 1 itu akan berhenti setelah menemukan kecocokan (dalam hal ini 6) dan mengembalikan data ini dari daun. Dalam contoh yang begitu sederhana, perilaku ini tampaknya dapat diandalkan dan logis. Saya telah mencoba memaksakan pengecualian dengan memilih nilai ID yang saya tahu ada di akhir halaman daun untuk melihat apakah daun akan dipindai dalam urutan terbalik, tetapi belum dapat menghasilkan perilaku ini, namun ini tidak berarti itu tidak akan terjadi, atau rilis MySQL di masa mendatang tidak akan melakukan ini dalam skenario yang telah saya uji.
Singkatnya, cukup tambahkan pesanan, atau gunakan MIN(ID) dan selesai. Saya tidak akan kehilangan terlalu banyak waktu tidur mencoba mempelajari cara kerja pengoptimal kueri untuk melihat jenis fragmentasi, atau rentang data yang diperlukan untuk mengamati urutan berbeda dari indeks berkerumun dalam rencana kueri.
