A resposta curta é sim, a chave primária tem uma ordem, todos os índices têm uma ordem e uma chave primária é simplesmente um índice único.
Como você disse com razão, você não deve confiar que os dados são retornados na ordem em que são armazenados, o otimizador é livre para devolvê-los na ordem que desejar, e isso dependerá do plano de consulta. No entanto, tentarei explicar por que sua consulta funcionou por 12 anos.
Seu índice clusterizado é apenas seus dados de tabela, e sua chave de cluster define a ordem em que são armazenados. Os dados são armazenados na folha, e a chave de cluster ajuda a raiz (e notas intermediárias) a agir como ponteiros para chegar rapidamente folha direita para recuperar os dados. Um índice não clusterizado é uma estrutura muito semelhante, mas o nível mais baixo simplesmente contém um ponteiro para a posição correta na folha do índice clusterizado.
No MySQL, a chave primária e o índice clusterizado são sinônimos, então a chave primária é ordenada, mas são fundamentalmente duas coisas diferentes. Em outros DBMS, você pode definir uma chave primária e um índice clusterizado, quando você faz isso, sua chave primária se torna um índice não clusterizado exclusivo com um ponteiro de volta para o índice clusterizado.
Em termos mais simples, você pode imaginar uma tabela com uma coluna ID que é a chave primária e outra coluna (A), sua estrutura B-Tree para seu índice clusterizado seria algo como:
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 |
+-----------+ +-----------+ +-----------+
Na realidade, as páginas das folhas serão muito maiores, mas isso é apenas uma demonstração. Cada página também tem um ponteiro para a próxima página e a página anterior para facilitar a navegação na árvore. Então, quando você faz uma consulta como:
SELECT ID, A
FROM T
WHERE ID > 5
LIMIT 1;
você está verificando um índice exclusivo, portanto, é muito provável que seja uma verificação sequencial. Muito provavelmente não é garantido embora.
O MySQL varrerá o nó Raiz, se houver uma correspondência em potencial, ele passará para os nós intermediários, se a cláusula tiver sido algo como
WHERE ID < 0 então o MySQL saberia que não havia resultados sem ir além do nó raiz. Depois de passar para o nó intermediário, ele pode identificar que precisa começar na segunda página (entre 4 e 7) para começar a procurar um
ID > 5 . Portanto, ele digitalizará sequencialmente a folha começando na segunda página da folha, já tendo identificado o LIMIT 1 ele parará quando encontrar uma correspondência (neste caso 6) e retornará esses dados da folha. Em um exemplo tão simples, esse comportamento parece ser confiável e lógico. Tentei forçar exceções escolhendo um valor de ID que sei que está no final de uma página de folha para ver se a folha será digitalizada na ordem inversa, mas ainda não consegui produzir esse comportamento, isso não significa isso não acontecerá, ou que versões futuras do MySQL não farão isso nos cenários que testei. Resumindo, basta adicionar um pedido por, ou usar MIN(ID) e pronto. Eu não perderia muito sono tentando mergulhar no funcionamento interno do otimizador de consulta para ver que tipo de fragmentação ou intervalos de dados seriam necessários para observar a ordenação diferente do índice clusterizado no plano de consulta.
