myisam被边缘化的根本原因是缺乏事务和行级锁，无法满足web 2.0对原子性、高并发及数据一致性的刚需；其表级锁、无回滚机制、崩溃易错乱等缺陷在用户注册、下单等多表联动场景中成为瓶颈。
MySQL 5.1 之后 MyISAM 被快速边缘化，根本原因不是它变慢了，而是 Web 2.0 应用场景里“单条 SQL 必须成功或全部失败”成了刚需——MyISAM 做不到这一点。
MyISAM 的表级锁在高并发写入时直接卡死
Web 2.0 场景下，用户注册、发帖、点赞、下单这些操作都伴随多张表的联动更新。MyISAM 对整张表加锁，一个 UPDATE users SET last_login=NOW() WHERE id=123 正在执行，整张 users 表就不可读不可写。
常见错误现象：SHOW PROCESSLIST 中大量线程卡在 Waiting for table level lock；SHOW STATUS LIKE 'Table_locks_waited' 数值持续上涨，且 Table_locks_waited / (Table_locks_immediate + Table_locks_waited) 超过 10% 就该警惕。
使用场景：只要业务中存在“同一张表被多个用户同时修改”的可能（比如评论数、浏览量、库存），MyISAM 就会成为瓶颈。
实操建议：
- 用
SELECT COUNT(*) FROM information_schema.INNODB_TRX对比当前活跃事务数，若远高于SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE COMMAND='Sleep'，说明 InnoDB 的行锁机制正在有效分流压力 - 检查慢查询日志里是否频繁出现未走索引的
WHERE条件（如WHERE status=1但status列无索引）——这种语句在 InnoDB 下也会退化为表锁，效果和 MyISAM 一样
没有事务意味着无法回滚，崩溃即数据错乱
Web 2.0 应用普遍依赖原子性：下单要扣库存 + 写订单 + 减余额，三步缺一不可。MyISAM 没有 undo log，也没有事务边界概念，UPDATE 一旦开始写磁盘，中途宕机就只剩半截数据。
典型错误现象：应用层看到“下单成功”，但数据库里只有订单记录、库存没扣、余额没减；或者反过来，库存扣了但订单没生成——这种不一致 MyISAM 根本无法自动修复。
实操建议：
-
mysqldump导出 MyISAM 表时加--lock-tables是必须的，否则备份过程中写入会导致逻辑不一致；而 InnoDB 可用--single-transaction实现无锁一致性快照 - 迁移老项目时，不能只改
ALTER TABLE t ENGINE=InnoDB，还要检查代码里有没有依赖“MyISAM 写一半可观察中间态”的调试逻辑（比如故意中断脚本看某字段是否已更新） - 确认应用连接串里是否显式设置了
autocommit=0，如果用了 InnoDB 却关掉自动提交又忘了COMMIT，会导致长事务堆积、锁等待飙升
COUNT(*) 性能差异在监控和分页场景里暴露得最明显
MyISAM 把总行数存在磁盘上，SELECT COUNT(*) FROM logs 几乎是常量时间；InnoDB 得扫聚簇索引，4 万行可能耗时 10ms 以上。这在 Web 2.0 的实时监控面板、后台分页总数统计里非常敏感。
但注意：这不是 InnoDB 的缺陷，而是设计取舍——它用可重复读、MVCC 和事务一致性换来了行级并发能力。
实操建议：
- 对大表的
COUNT(*)，不要直接查，改用近似值：SELECT table_rows FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t'（该值来自统计信息，误差可控） - 分页场景避免
SELECT * FROM t ORDER BY id LIMIT 10000,20，MyISAM 和 InnoDB 都会慢；应改用游标式分页：SELECT * FROM t WHERE id > 12345 ORDER BY id LIMIT 20 - 如果真需要精确总数且查询极频繁（如小配置表），可单独维护一个计数器字段，用
INSERT ... ON DUPLICATE KEY UPDATE或应用层加锁更新
真正难处理的不是技术切换本身，而是那些隐含在旧代码里的“无事务假设”：比如靠 REPLACE INTO 模拟幂等、用 MyISAM 的快速修复掩盖逻辑漏洞、甚至把表锁等待当成天然限流手段。这些惯性思维比语法迁移更难纠正。
