InnoDB聚簇索引查主键只需一次B+树查找，因其叶子节点直接存储整行数据；MyISAM索引与数据分离，需先查索引再按地址读数据文件，至少两次磁盘访问。
InnoDB 聚簇索引查主键（WHERE id = ?）通常比 MyISAM 快，不是因为“B+树更先进”，而是数据物理存放方式决定了 IO 次数——InnoDB 一次定位即得整行，MyISAM 至少两次磁盘寻址。
聚簇索引查主键为什么只用一次 B+ 树查找？
InnoDB 的主键索引就是数据本身：PRIMARY KEY 对应的 B+ 树叶子节点里直接存着整行记录。执行 SELECT * FROM t WHERE id = 123 时，B+ 树搜索到叶子页，数据就躺在那儿，不用跳转。
MyISAM 则不然：哪怕你建了 PRIMARY KEY(id)，它的索引文件（.MYI）和数据文件（.MYD）完全分离。索引叶子节点只存一个地址（比如 offset=12403），查完还得 fseek 到 .MYD 文件那个位置再读一次——这不算“回表”，是两次独立磁盘访问。
关键差异点：
- InnoDB 的“回表”是二次 B+ 树查找（先查二级索引得主键，再拿主键去聚簇索引里查）；
- MyISAM 的“回表”是直接按地址读文件，局部性更好，但前提是
.MYD没碎片、系统 page cache 命中率高； - 真实负载下，InnoDB 的
buffer_pool缓存的是页（page），而 MyISAM 只缓存索引（key_buffer_size），数据靠系统 page cache，稳定性差。
没有显式主键时，InnoDB 和 MyISAM 行为完全不同
InnoDB 会悄悄加一个隐藏的 6 字节 _rowid（类型为 BIGINT）作为聚簇索引键，确保数据能按顺序组织。这个字段不可见、不能引用（ORDER BY _rowid 会报错），但真实参与排序、插入和回表。
MyISAM 完全不强制主键：没定义 PRIMARY KEY 就真没有，SHOW CREATE TABLE 里也不会出现。很多 ORM 或旧客户端默认假设有主键，生成的 SQL 含 ORDER BY id 或 JOIN ON id，结果要么报错，要么逻辑错乱。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
迁移老 MyISAM 表前务必做两件事：
- 先执行
ALTER TABLE t ENGINE=InnoDB； - 紧接着显式添加
PRIMARY KEY（比如ADD PRIMARY KEY (id)），否则等于把隐患打包带走； - 别依赖
mysqldump导出再导入来“修复”，MyISAM 表导出后.MYD文件顺序丢失，SELECT * LIMIT 10结果每次可能都不一样。
范围查询（BETWEEN / ORDER BY）性能差距被严重低估
聚簇索引天然保证数据物理有序。例如 SELECT * FROM orders WHERE created_at BETWEEN '2025-01-01' AND '2025-01-31'，如果 created_at 是二级索引，InnoDB 还是要回表；但如果用 (id, created_at) 建联合主键，或让 created_at 成为聚簇索引的一部分，就能批量读连续页，大幅减少 IO。
MyISAM 的数据文件本身无序，即使走 INDEX(created_at)，查到的物理地址也是离散的，顺序读失效，ORDER BY 或 LIMIT 很可能触发 filesort。
更隐蔽的问题：
- MyISAM 的
INDEX(a,b)即使满足ORDER BY a,b，也不保证返回结果稳定——引擎不承诺排序物理连续； - InnoDB 的覆盖索引（
Using index）在范围扫描时更容易生效，尤其当查询字段全在索引里； - 用
EXPLAIN看到type: range且Extra有Using index condition，说明走了索引下推但仍要回表；这时如果SELECT字段都在索引里，就该建覆盖索引，而不是忍着回表。
最常被忽略的一点：InnoDB 的聚簇索引对写入敏感。用 UUID 或随机字符串作主键，会导致频繁页分裂、数据碎片、缓冲池命中率下降；MyISAM 虽然也怕随机写，但它不维护 B+ 树结构一致性，反而“钝感”更强——但这不是优势，是放弃事务与崩溃恢复换来的妥协。
