Det korte svar er ja, den primære nøgle har en rækkefølge, alle indekser har en rækkefølge, og en primær nøgle er simpelthen et unikt indeks.
Som du med rette har sagt, bør du ikke stole på, at data returneres i den rækkefølge, dataene er lagret i, optimeringsværktøjet kan frit returnere dem i hvilken som helst rækkefølge, det vil, og dette vil være afhængigt af forespørgselsplanen. Jeg vil dog forsøge at forklare, hvorfor din forespørgsel har virket i 12 år.
Dit klyngeindeks er kun dine tabeldata, og din klyngenøgle definerer den rækkefølge, de er gemt i. Dataene gemmes på bladet, og klyngingsnøglen hjælper grundtonen (og mellemnoterne) med at fungere som pointere til hurtigt at komme til højre blad for at hente dataene. Et ikke-klynget indeks er en meget lignende struktur, men det laveste niveau indeholder blot en pegepind til den korrekte position på bladet af det klyngede indeks.
I MySQL er den primære nøgle og det klyngede indeks synonyme, så den primære nøgle er ordnet, men de er grundlæggende to forskellige ting. I andre DBMS kan du definere både en primær nøgle og et klynget indeks, når du gør dette bliver din primære nøgle et unikt ikke-klynget indeks med en peger tilbage til det klyngede indeks.
I dets enkleste termer kan du forestille dig en tabel med en ID-kolonne, der er den primære nøgle, og en anden kolonne (A), din B-Tree-struktur for dit klyngede indeks ville være noget i retning af:
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 |
+-----------+ +-----------+ +-----------+
I virkeligheden vil bladsiderne være meget større, men dette er kun en demo. Hver side har også en pegepind til næste side og den forrige side, så det er nemt at krydse træet. Så når du laver en forespørgsel som:
SELECT ID, A
FROM T
WHERE ID > 5
LIMIT 1;
du scanner et unikt indeks, så det er meget sandsynligt, at dette vil være en sekventiel scanning. Meget sandsynligt er dog ikke garanteret.
MySQL vil scanne rodnoden, hvis der er et potentielt match, vil det gå videre til de mellemliggende knudepunkter, hvis klausulen havde været noget i stil med WHERE ID < 0 så ville MySQL vide, at der ikke var nogen resultater uden at gå længere end til rodnoden.
Når den går videre til den mellemliggende node, kan den identificere, at den skal starte på den anden side (mellem 4 og 7) for at begynde at søge efter et ID > 5 . Så den vil sekventielt scanne bladet begyndende på den anden bladside, idet den allerede har identificeret LIMIT 1 den stopper, når den finder en match (i dette tilfælde 6) og returnerer disse data fra bladet. I et så simpelt eksempel ser denne adfærd ud til at være pålidelig og logisk. Jeg har forsøgt at fremtvinge undtagelser ved at vælge en ID-værdi, som jeg ved er i slutningen af en bladside for at se, om bladet vil blive scannet i omvendt rækkefølge, men har endnu ikke været i stand til at frembringe denne adfærd, det betyder dog ikke det vil ikke ske, eller at fremtidige udgivelser af MySQL ikke vil gøre dette i de scenarier, jeg har testet.
Kort sagt, bare tilføj en ordre efter, eller brug MIN(ID) og vær færdig med den. Jeg ville ikke miste for meget søvn ved at prøve at dykke ned i forespørgselsoptimeringsværktøjets indre funktioner for at se, hvilken slags fragmentering eller dataområder der kræves for at observere forskellig rækkefølge af det klyngede indeks i forespørgselsplanen.