myisam表锁会导致连接池爆满，因其表级锁使慢查询阻塞后续所有读写请求，连接持续占用不释放；可通过show processlist识别waiting for table level lock状态，结合concurrent_insert=2、--low-priority-updates等配置缓解，但治本需迁移到innodb并验证全文索引、auto_increment及lock tables兼容性。
MyISAM表锁为什么会让连接池爆满
MyISAM是表级锁，一次写操作（INSERT、UPDATE、DELETE）会锁住整张表，后续所有对该表的读写请求都得排队等待。如果有个慢查询（比如没走索引的 SELECT）卡了 30 秒，后面几十个并发请求全堵在 Waiting for table level lock 状态——它们不是在执行 SQL，而是在等锁；但每个都在占用一个连接，不释放、不超时、不退出。连接池里的连接被持续“借出却无法归还”，很快打满。
用 SHOW PROCESSLIST 快速识别 MyISAM 锁阻塞
登录 MySQL 后立刻执行：
SHOW PROCESSLIST;
重点关注三类线索：
- 状态为
Waiting for table level lock的连接，且Time值远大于业务正常响应时间（如 >5 秒） -
Info列显示对同一张 MyISAM 表的SELECT或写操作（如SELECT * FROM log_table） - 大量连接的
User和Host高度集中，说明是某服务批量触发
别只看 Threads_running——它可能只有个位数，但 Threads_connected 已逼近 max_connections，这就是典型的“锁堆积”而非高负载。
不改引擎的前提下缓解 MyISAM 表锁压力
如果暂时无法迁移到 InnoDB（比如历史表结构复杂、全文索引依赖 MyISAM），可组合使用以下配置降低锁影响：
- 设
concurrent_insert=2：允许在任何情况下（含表中有空洞）从表尾并发插入，缓解INSERT之间的互斥 - 启动时加
--low-priority-updates：让所有UPDATE/DELETE优先级低于SELECT，避免读被写长期阻塞 - 调小
max_write_lock_count（如设为 16）：强制每执行 16 次写操作后，主动让出锁给等待中的读请求 - 对非关键写操作显式加
LOW_PRIORITY，例如：INSERT LOW_PRIORITY INTO myisam_log ...
注意：concurrent_insert=2 对 UPDATE 和 DELETE 无效，且不能解决长事务或全表扫描导致的锁争用。
真正治本：迁移前必须做的两件事
MyISAM 锁问题本质是架构约束，临时参数只能延缓爆发，不能消除风险。上线迁移前务必确认：
- 检查是否有
FULLTEXT索引：InnoDB 从 5.6 起已支持，但需重建；若仍依赖 MyISAM 全文特性，需评估替代方案（如 Elasticsearch） - 验证
AUTO_INCREMENT行为：InnoDB 的自增锁机制与 MyISAM 不同，高并发插入下可能有间隙或性能差异 - 确认无
LOCK TABLES手动加锁逻辑：这类语句在 InnoDB 下语义不同，容易引发死锁或意外阻塞
最常被忽略的是：MyISAM 表在异常崩溃后需 REPAIR TABLE，该操作全程锁表——这在生产环境是不可接受的停机风险，而 InnoDB 的崩溃恢复是自动且无锁的。
