MyISAM非聚簇索引的物理结构决定其索引与数据分离（.MYI存地址、.MYD存数据），回表为直接物理寻址，故纯读快但无事务、无崩溃恢复、仅支持表锁；更新非索引列快，范围查询慢；ORDER BY非主键必Using filesort；MySQL 8.0默认禁用，全文索引等旧“刚需”已被InnoDB覆盖。
MyISAM非聚簇索引的物理结构决定了它的行为边界
MyISAM所有索引（包括主键）都是非聚簇索引，本质是索引与数据彻底分离：索引存在.MYI文件，数据存在.MYD文件。叶子节点不存记录本身，只存行号或文件偏移量（比如0x100），查到后直接跳转到.MYD对应位置读取——这和InnoDB“先查主键再回表”有根本区别。
这种设计让MyISAM在纯读场景下回表极快，但代价是完全放弃事务、崩溃恢复能力弱，且无法支持行级锁。
为什么MyISAM非聚簇索引更新更快但范围查询更慢
更新时只需改.MYD中某行和.MYI中对应地址，不用挪动整条记录或分裂B+树节点；而InnoDB聚簇索引更新主键可能触发整行移动甚至页分裂。
- 优势场景：
INSERT密集、UPDATE只改非索引列、SELECT带精确WHERE条件（如WHERE id = 123） - 劣势场景：
WHERE age BETWEEN 20 AND 30这类范围查询，MyISAM要随机跳转多个.MYD地址，磁盘寻道开销大；InnoDB聚簇索引下数据物理有序，能顺序读取 - 注意：
ORDER BY若非按主键排序，MyISAM几乎必然触发Using filesort
MyISAM非聚簇索引容易被忽略的兼容性陷阱
MySQL 8.0默认禁用MyISAM，新实例需显式启用skip_disabled_storage_engines才允许建表；5.7之后mysql系统库已强制InnoDB，意味着权限表、日志表等底层依赖不再兼容MyISAM。
-
SHOW CREATE TABLE输出里ENGINE=MyISAM可能被静默转成InnoDB，尤其在复制从库或导入dump时 -
REPAIR TABLE对损坏的.MYI文件有效，但.MYD损坏往往不可逆——没有WAL日志，崩溃即丢数据 - 联合索引
(a,b)的WHERE b = ?无法命中，因为MyISAM索引B+树只按最左前缀排序，且叶子节点存的是地址而非主键，无法做索引下推
真正影响选型的不是索引类型，而是锁粒度和恢复机制
MyISAM表级锁在并发写入时会阻塞所有读操作，哪怕只是SELECT COUNT(*)；而InnoDB行锁+MVCC能支撑高并发读写。这不是索引结构问题，是存储引擎整体设计取舍。
如果你的应用仍依赖MyISAM，大概率是因为历史原因用了全文索引（FULLTEXT）或GIS功能——但MySQL 5.6+的InnoDB已支持FULLTEXT，8.0+支持空间索引，这些“刚需”早已消失。
