myisam 表锁无法被连接池缓解，必须转为 innodb 或重构操作方式；因其表级写锁会阻塞所有对该表的读写请求，导致连接长时间占用池中 slot 而假性爆满，根源在于锁机制而非连接池配置。
MyISAM 表锁无法被连接池缓解，必须转为 InnoDB 或重构操作方式。 连接池满溢只是表象，根源是 MyISAM 在执行 INSERT、UPDATE、DELETE 或 ALTER TABLE 时对整张表加写锁，阻塞其他连接，导致连接长时间 hang 住、无法释放，最终池子耗尽。
为什么 MyISAM 表锁会让连接池“假性爆满”
MyISAM 的表级锁机制意味着：只要一个线程在写某张表，所有其他对该表的读写请求（包括 SELECT）都得排队等待——哪怕只是查一行。这些等待中的连接不会立刻断开，而是持续占用连接池 slot，直到锁释放或超时。尤其在有慢写操作（如未加索引的 UPDATE）或批量 INSERT 时，等待队列会迅速堆积。
-
SHOW PROCESSLIST中大量连接状态为Waiting for table level lock - 对应线程的
Info字段显示正在执行的 SQL 涉及 MyISAM 表 -
Threads_connected接近max_connections，但实际活跃查询并不多 - 应用层报错常是 “Connection timeout” 或 “Cannot get JDBC connection”，而非直接的锁错误
最快见效的修复路径：改表引擎 + 调整 wait_timeout
不改引擎，任何连接池调优都是临时止痛。MyISAM 本质不支持行级并发，强行压连接数只会让问题更隐蔽。
- 用
ALTER TABLE table_name ENGINE=InnoDB;迁移关键表（注意备份、磁盘空间和锁表时间；5.6+ 可加ALGORITHM=INPLACE减少影响） - 检查并缩短数据库空闲连接超时：
wait_timeout建议设为 60–180 秒（默认常为 28800），避免僵死连接长期占位 - 确认应用代码中每个
Connection都在finally块或 try-with-resources 中显式close()，防止泄漏叠加锁阻塞 - 禁用 MyISAM 相关功能（如
federated引擎），减少意外触发表锁的路径
如果暂时无法改引擎：绕过锁的实操策略
仅适用于只读为主、写操作极少且可接受延迟的场景。不能根治，但能缓解雪崩。
- 将写操作集中到低峰期，并拆成小批次（例如每次
INSERT ... VALUES (...), (...)不超过 500 行） - 用
INSERT DELAYED（仅 MyISAM 支持）缓存写入，但注意它已从 MySQL 5.7+ 移除，且不保证顺序和即时可见性 - 对高频读场景，用
SELECT SQL_NO_CACHE ...配合应用层缓存，减少直接打到 MyISAM 表的请求量 - 监控
Table_locks_waited和Table_locks_immediate状态变量，比值 > 0.01 就说明锁争抢已严重
真正棘手的点不在配置参数，而在于 MyISAM 的锁行为不可预测：一个没加索引的 WHERE 条件，可能让本该秒级完成的 UPDATE 持锁几十秒，把整个池子拖垮。排查时别只盯连接数，先抓 SHOW PROCESSLIST 里卡在 Waiting for table level lock 的那几条 SQL，它们才是源头。
