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 下“没索引就不敢动”的敬畏心。