MySQL查询结果顺序不一致的根本原因是未使用ORDER BY，导致返回顺序由聚簇索引物理存储顺序（主键升序）决定，而非插入顺序；InnoDB按主键B+树组织数据，插入乱序时物理重排必然发生，而MYISAM等堆表才保留插入顺序。
INSERT 语句本身不显式排序，但 InnoDB 会按主键顺序物理重排数据 —— 这不是“插入时自动调用 ORDER BY”，而是聚簇索引的底层存储机制决定的。
为什么 INSERT 后查出来顺序和插入顺序不一致？
因为 InnoDB 表的数据页本身就是按主键值升序组织的 B+ 树叶子节点。你执行 INSERT INTO t (id, name) VALUES (5, 'e'), (1, 'a'), (3, 'c')，数据最终在磁盘上是按 id=1、id=3、id=5 的物理顺序存放的，哪怕插入语句是乱序写的。
这跟 MYISAM 完全不同：MYISAM 是堆表，数据按插入顺序追加，不重排。
- 如果你的主键是
AUTO_INCREMENT，那插入顺序 ≈ 物理顺序，看起来“没排序” - 如果主键是 UUID 或业务自定义无序值（比如手机号、邮箱），每次插入都可能触发页分裂和数据挪动，物理位置完全不可预测
-
SELECT *不带ORDER BY时，MySQL 返回的是聚簇索引叶子节点的自然遍历顺序 —— 就是主键升序，不是插入顺序
二级索引的排序行为怎么理解？
每个二级索引（比如 INDEX idx_name (name)）也是一棵独立的 B+ 树，它的叶子节点存的是 name 值 + 对应主键值（不是整行数据）。所以：
- 插入时，InnoDB 会同时往聚簇索引树和所有相关二级索引树里写入条目
- 每个二级索引树也按自己的键值（这里是
name）升序维护结构，同样会发生页分裂、节点分裂、层级上升 - 同一个
name值可能对应多个主键，B+ 树内部靠主键值做二次排序来保证唯一性（避免索引页内重复键冲突）
这意味着：即使你只查 SELECT * FROM t WHERE name = 'alice'，返回结果的顺序仍由主键决定，不是插入顺序，也不是二级索引页内存储顺序。
ORDER BY 能不能走索引排序？关键看是否满足最左前缀
只有当 ORDER BY 字段能被某个索引的最左前缀完全覆盖，且没有被 WHERE 条件破坏顺序性时，才可能跳过 filesort。
- 有索引
INDEX idx_status_created (status, created_at)，SELECT * FROM t WHERE status = 1 ORDER BY created_at→ 可走索引排序 - 同个索引，
ORDER BY status, created_at→ 可走；但ORDER BY created_at, status→ 不可走（违反最左前缀） - 如果
WHERE用了范围条件（如status > 0），即使索引存在，ORDER BY created_at通常也会退化为 filesort
注意：EXPLAIN 中看到 Using filesort 就说明 MySQL 没法复用索引顺序，得额外排序。
页分裂对插入性能和排序连续性的实际影响
频繁向非自增主键表插入数据时，页分裂不是“偶尔发生”，而是常态。每分裂一次，都会带来：
- 磁盘随机写放大：旧页要读出、新页要写入、父节点要更新
- 索引碎片：逻辑上相邻的主键值，物理上可能落在不同数据页，甚至不同区（extent）
- 后续
SELECT ... ORDER BY primary_key虽然逻辑有序，但 I/O 是离散的，性能不如自增主键下的顺序读
这也是为什么线上业务表强烈建议用 AUTO_INCREMENT 主键 —— 不是为了“省事”，而是为了把 B+ 树的分裂控制在右边界，让大部分插入变成顺序追加，物理局部性更好。
