MyISAM适合非核心数据快速存储，根本原因是其省略事务、行锁和崩溃恢复等机制，仅追加数据到.MYD并更新.MYI索引偏移，结构轻量无额外开销。
MyISAM 适合非核心数据快速存储，根本原因不是它“快”，而是它彻底省掉了事务、行锁、崩溃恢复这些重型机制——结构轻到几乎不干预写入过程。
MyISAM 写入为什么几乎没有额外开销
MyISAM 的 INSERT 不走 WAL（预写日志），不校验外键，不加行锁，不维护 MVCC 版本链，也不触发聚簇索引重组。它只做两件事：append 到 .MYD 文件末尾（或复用已删除记录的空洞），再更新 .MYI 中对应索引项的物理偏移量。
常见错误现象：在高并发写入时发现性能骤降——这不是 MyISAM “变慢”了，而是表级锁把所有写请求串行化了，INSERT 被阻塞在等待锁上。
- 单线程批量插入（如日志归档）：直接追加，无锁竞争，吞吐接近磁盘顺序写极限
- 多线程写入：哪怕只有一条
UPDATE或DELETE，整张表就卡住，其他写和读都等锁 - 没有事务回滚能力：
INSERT执行一半崩溃，.MYD和.MYI可能错位，表直接被标记为crashed
为什么 .MYD + .MYI 分离结构利于快速落地
MyISAM 把数据和索引存在两个独立文件里：.MYD 是纯堆表（heap table），按插入顺序堆放；.MYI 是 B+ 树索引，叶子节点只存 .MYD 中的字节偏移量。这种解耦带来三个实际好处：
- 建表后立刻能写：不需要初始化聚簇索引树，
CREATE TABLE ... ENGINE=MyISAM几乎瞬时完成 - 压缩友好：
myisampack可直接对只读.MYD压缩，不影响.MYI查询路径 - 迁移简单：拷贝
.frm+.MYD+.MYI三文件即可“热备份”，无需mysqldump或FLUSH TABLES WITH READ LOCK
但注意：.MYD 中的“空洞”（删除后留下的碎片）不会自动整理，长期增删后 SELECT 性能会缓慢下降，需定期 OPTIMIZE TABLE ——这会锁表，且重建整个 .MYD 和 .MYI。
COUNT(*) 秒出背后的风险点
MyISAM 的 COUNT(*) 快，是因为它在内存里缓存了一个精确的行数计数器，每次 INSERT/DELETE 都原子增减。但这依赖两个脆弱前提：
- 所有变更必须经由 MySQL Server 层执行；用
myisamchk --recover修复后，计数器不会自动同步，得手动ANALYZE TABLE - 表级锁保护该计数器，高写场景下，
COUNT(*)查询本身也会排队等锁，反而成瓶颈 -
COUNT(*) WHERE status = 1这类带条件的统计，依然要全表扫描.MYD，不享受计数器优化
真正需要“非核心数据快速存储”的场景（比如埋点日志、传感器原始采样、归档报表快照），MyISAM 的轻量结构确实省心；但只要涉及任何写入并发、数据一致性要求或后续可能要 JOIN/UPDATE，它的简化就立刻变成隐患——不是不能用，而是得清楚它省掉的每一个功能，都是你将来要自己兜底的缺口。
