myisam表锁性能瓶颈只能通过迁移到innodb解决，参数调优仅临时有效且副作用明显；concurrent_insert=2实际命中率低，low_priority_updates拖慢吞吐并已弃用；迁移需规避索引缺失、事务未提交、全文索引差异三大坑，并监控行锁平均时间和缓冲池命中率。
MyISAM 表锁导致的性能瓶颈，不能靠调参“修好”，只能换引擎——InnoDB 是唯一可持续解法。所有参数调整（concurrent_insert、low_priority_updates 等）都只是临时扛压，且副作用明显，一旦写压力上升就会失效。
为什么 concurrent_insert=2 在业务中基本无效
这个参数常被误认为能“并发插入”，但它只在极窄条件下生效：
- 必须是纯尾部追加（即没有
DELETE或UPDATE产生的空洞），否则会退化为普通表锁 - 即使满足条件，也要依赖定期
OPTIMIZE TABLE清空碎片，而该操作本身会锁全表，线上不敢轻易执行 - 业务表普遍存在更新和删除，
concurrent_insert=2实际命中率极低，SHOW PROCESSLIST里仍大量出现Locked状态 - 它不解决
UPDATE和DELETE的锁表问题，而这两种操作恰恰是业务高频变更的核心
low_priority_updates 不是降级，是拖慢整体吞吐
启用该参数后，所有写操作默认让位于读请求，看似缓解了读阻塞，实则带来新问题：
- 写请求排队时间拉长，事务等待超时（
Lock wait timeout exceeded）概率上升 - 批量更新任务耗时翻倍，可能触发应用层重试或超时熔断
- 无法按语句粒度控制优先级——你不能只对日志类
INSERT降权，而保留订单UPDATE高优 - MySQL 8.0+ 中该参数已标记为 deprecated，未来版本可能移除
迁移至 InnoDB 时最容易踩的三个坑
不是执行 ALTER TABLE t ENGINE=InnoDB 就算完成，以下三点漏掉任一，上线后反而更卡：
-
UPDATE或DELETE没走索引 → 触发全表扫描，InnoDB 会锁住所有聚簇索引页，等效于表锁；务必用EXPLAIN验证每条 DML 是否命中索引 - 业务代码依赖 MyISAM 的“自动提交语义”，切换后未显式
COMMIT→ 数据查不到、事务堆积、连接池耗尽 - 原 MyISAM 表含
FULLTEXT索引 → InnoDB 的全文索引分词逻辑、停用词列表不同，搜索结果可能大面积偏差，需重新测试
上线后必须盯住的两个指标
迁移不是终点，而是监控起点：
-
innodb_row_lock_time_avg：持续高于 50ms，说明行锁争抢严重，要检查是否因缺失索引或锁范围过大导致 -
Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads的比值：若后者占比 > 1%，说明缓冲池命中率不足，innodb_buffer_pool_size可能设小了
真正难的不是改表，是把 MyISAM 时代“不加索引也敢写”的习惯，换成 InnoDB 下“没索引就不敢动”的敬畏心。
