解决MySQL MyISAM表锁导致的业务性能瓶颈

MyISAM表锁导致的性能瓶颈无法通过参数调整彻底解决，唯一可持续的方案是更换为InnoDB引擎。诸如`concurrent_insert`、`low_priority_updates`等参数调整仅是临时缓解压力的权宜之计，且副作用显著。当写入压力增大时，这些参数会立即失效，性能瓶颈依旧存在。

为什么 concurrent_insert=2 在业务中基本没啥用

很多人误以为加上这个参数就能实现“并发插入”，但实际上，它的生效条件非常狭窄：

• 必须是纯尾部追加操作，也就是说，表里不能有 DELETE 或 UPDATE 留下的空洞，否则它会直接退化成普通的表锁。
• 即使满足了这个条件，还得依赖定期运行 OPTIMIZE TABLE 来清空碎片。但 OPTIMIZE TABLE 本身会锁全表，线上业务很少敢执行。
• 现实业务表里，更新和删除操作比比皆是，concurrent_insert=2 的实际命中率低得可怜。查看 SHOW PROCESSLIST 时，依然会看到大量 Locked 状态。
• 最关键的是，它根本不解决 UPDATE 和 DELETE 带来的锁表问题，而这些操作恰恰是业务中最频繁、最核心的变更。

low_priority_updates 不是降级，是拖慢整体吞吐

开启这个参数后，所有写操作都会默认给读让路。表面上缓解了读阻塞，实际上引入了一堆新麻烦：

• 写请求排队时间会拉得很长，事务等待超时（Lock wait timeout exceeded）的概率显著上升。
• 批量更新任务的耗时可能直接翻倍，甚至触发应用层的重试或超时熔断。
• 它无法按语句粒度控制优先级——不能只让日志类的 INSERT 降权，而把订单 UPDATE 保留高优，这是一刀切的方案。
• MySQL 8.0 及以上版本中，low_priority_updates 已被标记为 deprecated，未来版本很可能会直接移除。

迁移到 InnoDB 时最容易踩的三个坑

不要以为执行一句 ALTER TABLE t ENGINE=InnoDB 就算完成了。下面三点，若遗漏任何一点，上线后不仅无法解决问题，反而可能更卡：

• UPDATE 或 DELETE 没走索引：这会导致全表扫描，InnoDB 在这种情况下会锁住所有聚簇索引页，效果与表锁类似。所以务必用 EXPLAIN 把每一条 DML 语句都验证一遍，确保命中索引。
• 业务代码依赖 MyISAM 的“自动提交语义”：切换后如果没有显式调用 COMMIT，你会发现数据查不到、事务堆积、甚至连接池被耗尽。
• 原 MyISAM 表里有 FULLTEXT 索引：InnoDB 的全文索引在分词逻辑和停用词列表上与 MyISAM 不同，搜索结果可能出现大面积偏差，必须先重新测试。

上线后必须盯着这两个指标

迁移不是终点，而是监控的起点：

• innodb_row_lock_time_avg：如果这个值持续高于 50ms，说明行锁争抢很严重，需要检查是否缺失索引或锁范围设置过大。
• Innodb_buffer_pool_read_requests 与 Innodb_buffer_pool_reads 的比值：如果 Innodb_buffer_pool_reads 占比超过 1%，说明缓冲池命中率不足，innodb_buffer_pool_size 可能需要调大。

说句实在的，真正难的不是改表，是把 MyISAM 时代“不加索引也敢写”的习惯，换成 InnoDB 下“没索引就不敢动”的敬畏心。