innodb聚簇索引将数据与主键索引物理存储在一起，myisam非聚簇索引仅存储数据地址；前者需主键、回表、易页分裂、count()慢但范围查询局部性好，后者无主键限制、无回表、count()快但随机i/o多。
InnoDB 的聚簇索引和 MyISAM 的非聚簇索引，根本区别在于「数据是否和主键索引存一起」——前者是，后者不是。这个差异直接决定了查询路径、回表行为、锁粒度甚至建表约束。
聚簇索引要求表必须有主键，MyISAM可以没有
InnoDB 强制要求每个表有聚集索引：如果没定义 PRIMARY KEY，它会优先选第一个 NOT NULL UNIQUE 列；都找不到就悄悄加一个隐藏的 row_id 字段当主键。而 MyISAM 允许表完全没主键、没索引，SELECT * FROM t 就是纯顺序扫描 .MYD 文件。
这意味着：
- 在 InnoDB 中删掉主键再重建，可能触发全表重建（因为物理排序要重排）；MyISAM 删除主键只是删掉一棵 B+ 树，数据文件不动
-
ALTER TABLE t DROP PRIMARY KEY在 InnoDB 中若无其他唯一非空列，会报错；MyISAM 直接成功 - 用
UUID或CHAR(36)做主键时，InnoDB 的所有二级索引叶子节点都要存这个大字段，索引体积暴涨；MyISAM 二级索引只存地址（固定 6 字节），不受影响
查一条记录，InnoDB 可能走两次 B+ 树，MyISAM 只走一次
假设执行 SELECT * FROM user WHERE name = 'alice'，且 name 是普通索引：
- InnoDB：先查
name辅助索引树 → 叶子节点拿到id值 → 再查主键索引树（聚簇索引）定位完整行。这就是「回表」 - MyISAM：查
name索引树 → 叶子节点直接拿到数据行在 .MYD 文件里的磁盘偏移量 → 一次 IO 读出整行
所以，InnoDB 中覆盖索引（SELECT id, name）能避免回表，性能提升明显；MyISAM 没这概念，它的索引天生不带数据，每次都要跳转。
主键更新或插入时，InnoDB 更容易页分裂，MyISAM 影响小
InnoDB 聚簇索引让数据按主键物理排序。如果主键是随机值（比如 UUID），新记录大概率插在中间，导致 B+ 树节点频繁分裂、数据页移动、碎片升高。而 MyISAM 的数据文件是追加写入的，索引树只维护地址指针，主键怎么变都不影响数据文件布局。
常见表现：
-
INSERT INTO t VALUES (UUID(), ...)在 InnoDB 中长期运行后，DATA_FREE值变大、innodb_page_size利用率下降 - MyISAM 表
OPTIMIZE TABLE主要是整理 .MYD 空洞；InnoDB 的OPTIMIZE TABLE实际是重建整张表（ALTER TABLE ... FORCE） - 自增
INT主键 + 按时间递增写入，对 InnoDB 最友好；MyISAM 对主键类型几乎无敏感度
count(*) 和范围扫描行为差异极大
SELECT COUNT(*) FROM t 这种无条件统计，在两者底层实现完全不同：
- MyISAM 在内存里缓存了表行数，直接返回，毫秒级
- InnoDB 必须扫描聚簇索引的叶子节点（哪怕只数个数），速度取决于表大小；加
WHERE后反而可能更快（走索引下推或范围裁剪）
范围查询如 SELECT * FROM t WHERE id BETWEEN 100 AND 200：
- InnoDB：聚簇索引叶子节点本身就是有序数据，连续读几个页即可，I/O 局部性好
- MyISAM：即使
id是主键，索引树只给地址，这些地址在 .MYD 文件中大概率不连续，产生大量随机 I/O
这也是为什么，同样是主键范围查询，InnoDB 在 SSD 上优势更明显，而 MyISAM 在机械盘上随机读延迟问题更突出。
真正容易被忽略的点是：InnoDB 的「聚簇」特性既是优势也是枷锁——它让主键选择、写入模式、索引设计环环相扣；而 MyISAM 的松耦合看似简单，却在并发、一致性、崩溃恢复上埋了硬伤。选引擎不是看单条 SQL 快不快，而是看你的数据生命周期里，哪一环崩了你承受不起。
