MyISAM的COUNT(*)快是因为直接读取.MYI文件头中持久化的行数元数据，时间复杂度O(1)；InnoDB需扫描索引树逐行判断可见性，时间复杂度O(n)，且受MVCC影响无法缓存固定值。
MySQL 5.7 中默认存储引擎已是 InnoDB，它和 MyISAM 的性能差异不是“谁更快”的简单对比，而是由锁粒度、缓存机制、索引结构等底层设计决定的——同一类操作在不同场景下表现可能完全相反。
读密集场景下MyISAM的COUNT(*)为什么快得多
MyISAM 在表的 .MYI 文件头里直接维护了行数统计，COUNT(*) 不带 WHERE 条件时直接返回该值；而 InnoDB 没有这种元数据缓存，必须扫描聚集索引或二级索引（取决于执行计划），哪怕只是统计总行数也会触发 I/O。
- 如果业务中频繁执行无条件
COUNT(*)（比如后台管理页显示总记录数），且数据极少变更，MyISAM确实更轻量 -
InnoDB下想避免全表扫描，可改用近似值：SELECT TABLE_ROWS FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't';（但该值来自统计采样，不精确） - 加了
WHERE条件后，两者都得走索引或全表扫描，MyISAM的优势消失
高并发写入时InnoDB行级锁的实际表现
InnoDB 的行级锁只在能明确使用索引定位记录时生效；一旦 SQL 无法利用索引（如 LIKE '%abc'）、或扫描范围过大（如没主键、没合适索引的 UPDATE），它会退化为表级锁——此时并发写入反而比 MyISAM 更卡。
- 确认是否真用了行锁：执行
SHOW ENGINE INNODB STATUS\G查看TRANSACTIONS部分的锁等待信息 - 避免隐式全表扫描：确保
WHERE条件字段上有有效索引，尤其注意TEXT/BLOB列前缀索引是否覆盖查询长度 -
MyISAM虽然写入必锁全表，但它的锁开销极低；在低并发、批量导入场景下，有时反而比InnoDB的 MVCC + undo log 更快
索引查询延迟差异源于聚簇与非聚簇结构
InnoDB 是聚簇索引，主键值即物理地址，主键查询一次磁盘即可取到整行；MyISAM 是非聚簇索引，索引和数据分离，即使查主键也要先查索引再回数据文件——但它的索引更小、更易缓存，对大量随机主键查询（如 UUID）反而减少 cache miss。
- 主键是自增整型时，
InnoDB的顺序插入 + 聚簇特性让写入和主键查询都占优 - 主键是长字符串或 UUID 时，
InnoDB的聚簇索引会导致数据页频繁分裂、B+ 树深度增加，而MyISAM的独立索引文件受此影响较小 -
MyISAM的.MYI文件可被操作系统 page cache 高效缓存，而InnoDB的缓冲池（innodb_buffer_pool_size）需手动调优，配置过小会导致频繁刷脏页
全文检索在5.7中已不是MyISAM专属
MySQL 5.6 起 InnoDB 就支持 FULLTEXT 索引，5.7 已足够稳定；但要注意：InnoDB 的全文检索不支持中文分词（需配合 ngram 或 mechanical 插件），而 MyISAM 原生对英文分词更友好。
- 若用
InnoDB做全文搜索，必须显式指定解析器：CREATE FULLTEXT INDEX ft_idx ON t(c) WITH PARSER ngram; -
MyISAM的全文索引更新是同步的，InnoDB因 MVCC 和事务隔离，可能查不到刚插入未提交的文档 - 真正高并发、高可用的全文需求，建议直接用
Elasticsearch或Sphinx，别强压给 MySQL 存储引擎
最常被忽略的一点：5.7 默认开启 innodb_file_per_table，每个 InnoDB 表单独成文件，但删除大量数据后不会自动回收磁盘空间——OPTIMIZE TABLE 会重建表并释放空间，但这期间会锁表；而 MyISAM 的 REPAIR TABLE 虽也能整理碎片，但同样不可在线。性能对比不能脱离运维成本看。
