MyISAM表锁导致线程池排队的本质是表级锁使连接卡在“Waiting for table level lock”状态并持续占用连接。其写操作加整表锁，后续读写全排队；常见诱因包括未用LOW_PRIORITY的LOAD DATA、大批量INSERT及高峰期ALTER TABLE；Threads_connected逼近max_connections而Threads_running很低即为典型表现；SHOW ENGINE INNODB STATUS无效；临时缓解需LOW_PRIORITY、分批写入（≤500行/批）及HIGH_PRIORITY读；根治须迁InnoDB并验证索引命中、显式COMMIT和全文索引差异。
MyISAM 表锁导致线程池排队，本质不是线程池配置问题，而是表级锁让大量连接卡在 Waiting for table level lock 状态，持续占用连接不释放——线程池再怎么调参也救不了被锁死的连接。
为什么 SHOW PROCESSLIST 里全是 Waiting for table level lock
MyISAM 对任何写操作（INSERT、UPDATE、DELETE、ALTER TABLE）都施加整张表的写锁，后续所有对该表的读写请求（包括 SELECT）全部排队等待。这些线程不会进入“执行中”，而是在锁队列里干等，但每个都占着一个连接，不超时、不释放。
- 常见诱因：
LOAD DATA INFILE导入未加LOW_PRIORITY；单条插入上万行的INSERT VALUES (),(),...；高峰期执行ALTER TABLE -
Threads_running可能只有个位数，但Threads_connected已逼近max_connections，这是典型锁堆积而非高负载 -
SHOW ENGINE INNODB STATUS完全无效——MyISAM 没事务、没死锁检测、也不输出锁状态
临时缓解：用 LOW_PRIORITY 和分批写入抢出时间窗口
若无法立刻迁移引擎，只能靠降低单次锁持有时间 + 让读优先来缓解排队深度：
- 所有非关键写操作显式加
LOW_PRIORITY：例如INSERT LOW_PRIORITY INTO log_table ...，强制让位于SELECT - 批量写入必须拆成小批次：每批 ≤ 500 行，避免单次锁表超过 1 秒；
INSERT DELAYED在 MySQL 8.0 已移除，不可用 - 读密集场景下，报表类查询可加
HIGH_PRIORITY（如SELECT HIGH_PRIORITY FROM report_view），但慎用——它会挤占写资源，可能引发写超时 - 配置
concurrent_insert=2仅对纯尾部追加有效，业务表存在DELETE/UPDATE就基本失效；--low-priority-updates在 8.0+ 已标记为 deprecated
根治方案：迁移到 InnoDB 时必须验证的三件事
执行 ALTER TABLE t ENGINE=InnoDB 只是第一步，漏掉任一都会让问题从“表锁”变成更难排查的“隐性行锁”：
- 检查所有
UPDATE/DELETE是否命中索引：用EXPLAIN验证，否则会升级为全表扫描 + 全聚簇索引页锁定，效果等同于表锁 - 确认业务代码是否显式
COMMIT：MyISAM 是自动提交语义，InnoDB 下未COMMIT的事务会持续持有锁，导致连接池耗尽 - 全文索引需重测：MyISAM 的
FULLTEXT分词逻辑与 InnoDB 不同，停用词、权重计算均有差异，搜索结果可能大面积偏移
真正难的不是执行 ALTER TABLE，而是把 MyISAM 时代“不加事务也能跑”的惯性思维切掉——InnoDB 的锁行为严格依赖索引、事务边界和隔离级别，任何一个环节松动，线程池排队就会换一种方式卷土重来。
