innodb主键查询更快，因其聚簇索引叶子节点直接存储整行数据，一次b+树查找即可完成；myisam所有索引均为非聚簇，主键查询需先查索引得物理偏移量、再读数据文件，属两次独立磁盘寻址。
查主键时，InnoDB一次B+树查找就拿到整行数据
MyISAM所有索引（包括主键）都是非聚簇索引，叶子节点只存.MYD文件里的物理偏移量。哪怕你写SELECT * FROM t WHERE id = 123，也得先读.MYI拿到地址，再fseek去.MYD里读——这是两次独立磁盘寻址。
InnoDB主键索引就是聚簇索引，叶子节点直接存整行数据。同样语句，一次B+树定位就结束，不用跳转。实测在SSD上，单点查询延迟能低30%~50%。
- 这个优势只对主键查询成立；用
name等二级索引查，InnoDB仍要回表（先查辅助索引得id，再查聚簇索引） - MyISAM的“两次寻址”在高并发下容易引发磁盘头抖动，尤其当多个连接查不同主键时，IO请求高度离散
- InnoDB的
innodb_buffer_pool_size能同时缓存索引页和数据页；MyISAM的key_buffer_size只缓索引，.MYD还得靠系统page cache，命中率不稳定
范围扫描时，InnoDB天然物理连续，MyISAM得额外排序
聚簇索引强制数据按主键物理排序。执行SELECT * FROM orders WHERE id BETWEEN 1000 AND 2000，InnoDB大概率能顺序读几个相邻数据页，IO次数少、局部性好。
MyISAM的数据文件本身无序，即使id是主键，索引查到的物理地址也是离散的。引擎无法保证结果顺序，ORDER BY id或LIMIT常触发filesort，且.MYD碎片多了之后，顺序读彻底失效。
- 如果业务依赖时间范围查询（如
created_at），InnoDB更推荐建联合主键（如PRIMARY KEY (created_at, id)），让物理存储与查询模式对齐 - MyISAM导出再导入后，
.MYD顺序丢失，SELECT * LIMIT 10结果可能每次都不一样，应用层不能依赖隐式顺序 - InnoDB的预读机制（
innodb_read_ahead_threshold）会自动加载相邻页；MyISAM无此能力，每个范围条目都得单独发IO请求
随机I/O密集场景下，InnoDB Buffer Pool比MyISAM更抗压
真实负载 rarely 是纯单点查询。混合了点查、范围扫描、JOIN的场景下，InnoDB的统一缓冲池设计优势明显：热数据页（含索引+数据）全驻内存，冷数据由后台线程异步刷盘。
MyISAM把索引和数据分离，key_buffer_size只能保索引，.MYD读取全靠OS page cache。QPS稍高（比如800+），从库iowait就容易飙到40%以上；InnoDB同一负载下iowait通常压在5%以内。
- MyISAM的
delay_key_write能缓解索引写压力，但不解决数据文件随机读问题 - InnoDB的自适应哈希索引（
innodb_adaptive_hash_index）能把高频点查转为内存O(1)查找，绕开B+树遍历 - SSD环境下，InnoDB的WAL（redo log顺序写）+ 聚簇索引局部性，比MyISAM直写
.MYD/.MYI更少触发SSD垃圾回收
别被“MyISAM COUNT(*)快”带偏了方向
MyISAM确实维护了一个行数计数器，SELECT COUNT(*) FROM t几乎秒返回；InnoDB要扫聚簇索引或采样估算，慢得多。但这只是特例，不是通用查询优势。
真正卡住线上服务的，从来不是这条SQL，而是SELECT * FROM user WHERE status = 1 AND updated_at > '2026-10-01'这类带条件的列表页查询——它既不走主键，又没法覆盖索引，MyISAM照样得全表扫.MYD，而InnoDB至少还能用二级索引+回表缩小范围。
- MyISAM表级锁会让这类查询在写入高峰期排队等待，响应时间毛刺极大
- InnoDB的MVCC允许读不加锁，高并发读写共存时稳定性强得多
- 很多团队误以为“MyISAM快”是因为测试用了简单主键点查+空负载，没模拟真实IO竞争和锁冲突
实际选型时，主键是否单调、是否有事务需求、并发读写比例如何，这些比单纯看“谁查得快”重要得多。聚簇索引的物理有序性是把双刃剑——用得好（如自增ID+时间递增写入），性能跃升；用得糟（如UUID主键+高频插入），页分裂和碎片反而拖垮查询。
