InnoDB聚簇索引在主键查询和范围扫描上通常快于MyISAM非聚簇索引，但需满足数据量适中、主键有序、buffer pool命中率高等前提；MyISAM仅在纯读、静态小表、无并发写入时表现低延迟，实为牺牲事务与一致性换来的临时表象。
InnoDB 聚簇索引在主键查询和范围扫描上普遍比 MyISAM 非聚簇索引快，但这个“快”有明确前提：数据量适中、主键有序、buffer pool 命中率高；MyISAM 在纯读、静态小表、无并发写入时可能表现出更低延迟，但这不是架构优势，而是牺牲事务与一致性换来的临时表象。
主键等值查询：InnoDB 一次 B+ 树查找 vs MyISAM 一次索引 + 一次 fseek
查 SELECT * FROM t WHERE id = 123：
- InnoDB 主键索引即聚簇索引，叶子节点直接存整行数据，一次 B+ 树遍历就拿到全部字段
- MyISAM 主键索引叶子节点只存
.MYD文件中的物理偏移量（如offset=4096），必须先查索引、再按地址读数据文件——看似也是两次操作，但第二次是系统级lseek + read，不经过 MySQL 缓存层 - 关键差异不在次数，而在缓存：InnoDB 的
buffer_pool可缓存数据页和索引页；MyISAM 的key_buffer_size只缓索引，.MYD文件靠 OS page cache，冷查询抖动更明显
二级索引查询（如 name 索引）：InnoDB 回表成本更高，尤其主键离散时
查 SELECT * FROM t WHERE name = 'Alice'（name 是普通索引）：
- InnoDB 先查
name二级索引得主键值（比如id=105），再拿该值去聚簇索引里二次 B+ 树查找——两次都是逻辑树搜索，若主键是UUID或乱序整数，第二次查找大概率触发随机磁盘 IO - MyISAM 查
name索引得物理地址（如offset=8192），直接跳转读取，局部性更好，尤其当.MYD文件未碎片化时 - 但注意：
EXPLAIN中看到type: ref+Extra: Using index condition就说明 InnoDB 已做索引下推，只是仍要回表；此时若把SELECT *改成SELECT name, id且建了覆盖索引，InnoDB 就能避免回表，MyISAM 却做不到这点
范围查询（如 ORDER BY / BETWEEN）：聚簇索引天然连续，非聚簇索引需额外排序
执行 SELECT * FROM orders WHERE created_at BETWEEN '2025-01-01' AND '2025-01-31' ORDER BY id：
- 如果
created_at是 InnoDB 的二级索引，查出的主键值是离散的，回表后数据物理位置跳跃，ORDER BY id很可能触发filesort - 但如果表用
(id, created_at)作联合主键（或聚簇索引），InnoDB 就能利用物理顺序批量读页，range扫描天然有序，Using index出现概率高 - MyISAM 即使对
created_at建了索引，查到的offset仍是离散的，.MYD文件本身无序，ORDER BY基本逃不开filesort，且导出再导入后顺序彻底丢失
写入与并发：聚簇索引对主键选择敏感，MyISAM 表锁是硬伤
INSERT / UPDATE 高频场景下：
- InnoDB 聚簇索引要求主键尽量趋势递增（如
INT AUTO_INCREMENT）；若用UUID作主键，新行插入位置随机，频繁引发页分裂和数据移动，写性能断崖下跌 - MyISAM 对写入友好，但任何
UPDATE或DELETE都锁整张表，高并发下吞吐量迅速见底；而 InnoDB 行锁让多用户同时改不同行成为可能 - MyISAM 没崩溃恢复机制，
mysqld异常退出后.MYD文件易损坏，修复过程可能丢数据；InnoDB 依赖 redo log 和 doublewrite buffer，保证 crash-safe
真正容易被忽略的点是：InnoDB 的“慢”往往源于隐式主键（如没定义 PRIMARY KEY 时的隐藏 _rowid）或二级索引里冗余存储了过长主键（比如用 VARCHAR(255) 当主键，所有二级索引叶子节点都存一份），而 MyISAM 的“快”只在单线程、只读、小数据量、无事务需求的真空环境里成立——这种场景现在连日志归档表都不太用了。
