MySQL数据页存储位置因引擎而异：InnoDB将数据和主键索引存于同一ibd文件，16KB页直接承载B+树叶节点；MyISAM则分离为.MYD（数据）、.MYI（索引）、.frm（结构），索引仅存指向.MYD的物理偏移指针。
MySQL数据页到底存哪儿？InnoDB和MyISAM根本不是一回事
InnoDB把数据和主键索引“捆”在同一个文件里（ibd），页就是16KB的连续块，数据行直接塞进B+树叶子节点；MyISAM则拆成三件套：.MYD（纯数据）、.MYI（纯索引）、.frm（表结构），索引页里只存指向.MYD中物理偏移量的指针。
这意味着：查InnoDB的主键是“一步到位”，查MyISAM是“先找地址、再跳过去”。如果数据页因更新而分裂或移动，MyISAM索引不用改——指针值重写就行；InnoDB的辅助索引却必须跟着更新主键值（因为回表依赖主键），所以主键别用UUID这类大字段。
为什么SELECT COUNT(*)在MyISAM快得离谱，InnoDB却要扫全表？
MyISAM在内存里维护了一个实时计数器，COUNT(*)直接返回；InnoDB没这个缓存，它得遍历聚簇索引的所有叶子页，挨个数记录——哪怕加了WHERE id > 0也绕不开，除非你用覆盖索引（比如COUNT(id)且id有二级索引）。
- 别为了count快就硬切MyISAM：崩溃后
.MYD损坏，计数器就彻底失真 - 真要高频count，考虑用单独统计表+应用层维护，或者升级到MySQL 8.0+用物化视图
- InnoDB下想略提速？确保
WHERE条件能命中二级索引，避免回表
崩溃后数据还在不在？页级恢复机制差异太大
InnoDB靠redo log实现崩溃恢复：所有修改先写日志，再刷页；掉电后重启时，MySQL重放未落盘的redo，把页拉回一致状态。MyISAM没日志，靠myisamchk修表，但可能丢最后几秒写入，甚至索引和数据页对不上。
- MyISAM表突然变“坏”，常见报错是
Table is marked as crashed或Incorrect key file - InnoDB出问题通常是
innodb_force_recovery级别不为0，或启动卡在Initializing buffer pool - 别信“MyISAM更轻量”——它的修复过程锁整个实例，InnoDB可在线热备+点恢复
什么时候还该用MyISAM？别被默认值带偏了
2026年还在用MyISAM，基本只剩两个真实场景：只读归档表（比如日志快照，用myisampack压缩后几乎不更新）、GIS空间查询（InnoDB至今不支持Polygon等原生类型）。
其他所谓“读多写少”“启动快”的理由，早被InnoDB的Buffer Pool自适应哈希、只读事务优化、并行读取等补平。真正容易踩的坑是：开发环境用MyISAM跑得欢，上线切InnoDB后发现LOCK TABLES逻辑崩了、外键报错、甚至FULLTEXT搜索结果不对——因为MySQL 5.6+的InnoDB全文索引分词规则和MyISAM不同。
页管理不是调参能解决的事，它是引擎基因。选错，后期迁移成本远高于初期多花十分钟看懂innodb_page_size和key_buffer_size的区别。
