根本原因是MyISAM仅支持表级锁，任何写操作均锁全表；缓解参数如concurrent_insert、low_priority_updates仅能错峰或让路，无法改变锁粒度；根治方案是迁移到InnoDB并合理配置innodb_buffer_pool_size等参数。
MyISAM 表在高频更新时出现严重锁表，不是参数调得不够狠的问题，而是引擎本身不支持行锁——concurrent_insert、low_priority_updates 等参数只能缓解表象，无法改变「一写锁全表」的根本限制。
MyISAM 的锁行为根本没法靠参数绕过去
MyISAM 只有表级锁，INSERT、UPDATE、DELETE 任意一个写操作都会对整张表加写锁。哪怕你只改一行，其他所有读写请求都得排队等它完成。这不是配置没开对，是存储引擎的设计决定的。
常见现象包括：SHOW PROCESSLIST 里大量状态为 Locked 的线程；SHOW STATUS LIKE 'Table_locks_waited' 值持续上涨；QPS 上不去但 CPU 不高。
-
concurrent_insert = 2只允许尾部追加插入，且要求表没被DELETE过空洞才稳定生效，实际业务中很难满足 -
low_priority_updates是让写让路，不是减少锁时间，反而可能拉长整体等待链 -
max_write_lock_count强制切换读优先，会打断写事务连续性，导致批量更新变慢甚至超时 -
INSERT DELAYED在 MySQL 5.6+ 已被移除，新版本直接报错
真正在用的参数调整，其实只适合过渡期临时扛压
如果你暂时无法迁移引擎，又必须撑过短期流量高峰，可以谨慎启用以下组合，但要清楚它们的副作用：
- 设
concurrent_insert = 2：仅对纯追加场景有效（如日志表），且需定期OPTIMIZE TABLE清空碎片，否则并发插入会退化为普通写锁 - 启动 mysqld 时加
--low-priority-updates：让所有写操作默认降级，但会显著拖慢写吞吐，且无法控制单条语句粒度 - 避免在配置里设
delay_key_write = ON：虽然能加速索引写入，但实例崩溃会导致索引损坏，恢复后需REPAIR TABLE
这些操作不会提升并发上限，只是把锁争抢“摊薄”或“错峰”，一旦写压力翻倍，立刻打回原形。
真正有效的出路是换引擎，不是调参数
解决 MyISAM 高频更新锁表问题，唯一可持续的方案是迁移到 InnoDB。但直接 ALTER TABLE tbl_name ENGINE=InnoDB 容易出问题，关键检查点有：
- 确认主键存在：InnoDB 必须有显式主键，否则会用隐藏
ROW_ID，导致二级索引膨胀、查询变慢 - 检查磁盘空间：转换过程先建新表再拷数据，临时空间至少等于原表大小
- 核对外键和全文索引：MyISAM 支持
FULLTEXT但不支持外键；InnoDB 在 MySQL 5.6 之前不支持全文索引，版本低于 5.7 要先删掉再重建 - 大表别直接
ALTER：用pt-online-schema-change或gh-ost，否则锁表时间不可控
换完引擎后，innodb_buffer_pool_size 和 innodb_log_file_size 才是值得重点调的参数——它们影响的是行锁效率，而不是在表锁泥潭里徒劳挣扎。
最常被忽略的一点：很多人以为把 concurrent_insert 调成 2 就算“优化完了”，结果上线后发现写延迟没降，反而读响应更抖——因为 MyISAM 的读锁虽不阻塞其他读，但写锁一来，所有读全卡住，而参数根本没动这根筋。
