MyISAM并发写入时锁全表，InnoDB行锁仅锁定索引命中的行；但InnoDB未走索引会退化为表锁，间隙锁在RR级别防幻读却易引发锁等待。
行级锁 vs 表级锁：并发写入时的锁竞争差异
MyISAM 的 UPDATE 或 INSERT 会直接对整张表加写锁，所有后续读写请求（包括 SELECT）都必须排队等待。InnoDB 默认使用行级锁，只锁定被修改的那几行，其余行仍可被其他事务并发访问。
常见错误现象：后台统计页加载卡顿、订单创建超时、库存扣减失败——这些往往不是 SQL 慢，而是 MyISAM 表被某条慢更新长期持锁，把整个表堵死。
- MyISAM 的锁粒度是表级，
SHOW PROCESSLIST中常看到大量Locked状态 - InnoDB 的行锁由索引决定：没走索引的
WHERE条件会升级为表锁，务必检查EXPLAIN输出的key字段是否非NULL - 间隙锁（Gap Lock）是 InnoDB 特有机制，能防止幻读，但也可能引发意外锁等待，尤其在范围条件
WHERE id BETWEEN 10 AND 20下
事务支持与崩溃恢复：数据不丢才是高并发的前提
MyISAM 不支持事务，ROLLBACK 无效，COMMIT 无意义；一旦写入中途失败（如断电、kill 进程），数据文件和索引文件极易错位，必须手动执行 REPAIR TABLE，且无法保证修复后一致性。
InnoDB 依靠 redo log 和 undo log 实现原子性与持久性：即使服务器突然宕机，重启后也能自动前滚（recover）未刷盘的提交事务，回滚（rollback）未完成事务。
- MyISAM 的
.MYD和.MYI文件分离设计，在崩溃后容易出现“索引指向不存在的偏移”，导致查询返回空或乱码 - InnoDB 的
innodb_force_recovery参数可在严重损坏时尝试启动，而 MyISAM 几乎没有等效机制 - 高并发场景下写入频繁，宕机概率上升，MyISAM 的“无事务”在此不是省事，而是埋雷
聚簇索引与缓存机制：IO 效率决定吞吐上限
InnoDB 主键即数据，二级索引叶子节点存的是主键值而非物理地址；MyISAM 所有索引叶子节点都存 .MYD 文件中的字节偏移量。这意味着同样一次 SELECT * FROM t WHERE idx_col = ?，InnoDB 可能只需两次 B+ 树查找（先查二级索引得主键，再查聚簇索引得整行），而 MyISAM 是一次索引查找 + 一次随机磁盘寻址读数据。
更关键的是缓存：InnoDB 的 Buffer Pool 同时缓存数据页和索引页；MyISAM 的 Key Buffer 只缓存索引，数据页始终要从磁盘读取。
- 高并发下，MyISAM 的
Key Buffer命中率再高，也绕不开每次查询都要访问.MYD文件的 IO 开销 - InnoDB 的
Buffer Pool若配置合理（比如设为物理内存的 70%），热点数据可长期驻留内存，大幅降低磁盘压力 - MyISAM 表在大量
DELETE后会产生碎片，OPTIMIZE TABLE会锁表，进一步加剧高并发下的阻塞
外键与数据一致性：业务逻辑越复杂，MyISAM 越难兜底
电商下单要扣库存、生成订单、更新用户积分，这三步必须原子执行。MyISAM 无法用单个事务包裹，只能靠应用层重试+补偿，出错边界极难控制；InnoDB 支持外键约束，可强制关联表间引用完整性，避免出现“订单存在但商品已下架”的脏状态。
这不是功能炫技，而是工程现实：当业务模块拆分、服务调用链变长，数据一致性保障必须下沉到存储层，否则上层代码会越来越脆弱。
- MyISAM 表加外键会直接报错：
ERROR 1005 (HY000): Can't create table ... (errno: 150) - InnoDB 外键依赖父表索引，若父表被删字段未建索引，
ALTER TABLE会静默失败或锁表很久 - 微服务架构下，跨库事务本就难做，如果连单库内基础约束都无法依赖，系统可靠性会指数级下降
真正容易被忽略的点在于：高并发从来不只是“同时很多人在操作”，而是“操作之间存在数据依赖和状态耦合”。 MyISAM 在这种耦合面前是裸奔的——它把所有协调责任推给应用，而现代业务的耦合深度早已超出人力可控范围。选 InnoDB 不是因为它快，而是因为它敢替你扛住那些你不敢写进业务代码里的异常分支。
