意向锁本身不可见且不可手动释放，其堆积源于长事务、空闲连接未释放或非DB操作滞留；防止关键在控制wait_timeout（建议300秒）、innodb_lock_wait_timeout（建议10～25秒）及HikariCP超时参数对齐，并杜绝事务内混入HTTP调用等外部操作。
MySQL 表级意向锁（INTENTION LOCK）本身不会“堆积”，但它是行锁/表锁的前置信号；真正卡住的是后续无法获取的行锁或表锁——而误操作（如长事务、空闲连接未释放、非 DB 操作滞留）会让意向锁长期存在，阻塞其他事务。防止的关键不在锁本身，而在掐断锁持有源头。
wait_timeout 和 interactive_timeout 设太大会让空闲连接长期持锁
MySQL 的 wait_timeout（非交互式连接）和 interactive_timeout（如 mysql 命令行）默认是 28800 秒（8 小时）。Java 应用走 JDBC，几乎全是非交互式，只受 wait_timeout 控制。
- 若应用没正确关闭连接，或连接池回收逻辑没对齐，这个连接就一直挂着，哪怕里面没执行 SQL，只要事务没提交，
INNODB_TRX里 TRX_STATE 是LOCK WAIT或RUNNING，它就持续持有意向锁甚至行锁 - 实操建议：把
wait_timeout改为300（5 分钟），配合 HikariCP 的idle-timeout: 300000—— 两端必须一致，否则连接池认为连接还可用，MySQL 却已悄悄 kill 掉，下次复用就报Connection reset或Lost connection - 改完别忘了：旧连接不会立刻失效，得等自然超时或重启应用；用
SHOW PROCESSLIST查Command = Sleep且Time > 300的连接，再关联information_schema.INNODB_TRX看是否真有未提交事务
innodb_lock_wait_timeout 设太高会掩盖真实锁争抢
innodb_lock_wait_timeout 不是死锁检测开关，它只管“等锁等到不耐烦为止”。默认 50 秒，线上 OLTP 场景下太长了。
- 设成 60 秒，一个慢查询卡在等锁，下游接口 1 分钟才报错，线程池早被耗尽，监控看到的只是“请求堆积”，根本看不出是锁问题
- 建议值：10～25 秒。足够覆盖网络抖动或轻量级竞争，又不至于让单点卡顿拖垮整条链路
- 不要全局硬调低：关键路径可临时
SET innodb_lock_wait_timeout = 5，配合应用层快速失败重试；但得先确认慢查日志里Lock wait timeout exceeded出现前的 SQL 是否真缺索引或写了全表扫描 - 注意：它不影响
innodb_deadlock_detect，死锁仍是秒级发现并回滚，这个参数只影响“活锁”类等待
HikariCP 连接池配置没对齐 MySQL 超时，等于白设
很多团队只调了 MySQL 的 wait_timeout，却忽略连接池侧的三个关键超时，结果连接池还在 happily 复用“僵尸连接”。
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
-
connection-timeout（获取连接超时）：建议 30 秒，防应用卡在 getConnection()；低于 MySQL 的connect_timeout（默认 10 秒）也没用，因为底层 TCP 层就拦住了 -
idle-timeout（空闲连接超时）：必须 ≤ MySQL 的wait_timeout，否则连接池保留着连接，MySQL 已经 close，下次 get 会触发重建，增加握手开销 -
max-lifetime（连接最大存活时间）：建议 1800000（20 分钟），强制刷新连接，避免因 MySQL 主从切换、网络闪断导致的 stale connection 问题；注意它不能小于idle-timeout - 漏掉
leak-detection-threshold（如设为 60000）：能抓到没归还连接的代码，比等maximum-pool-size耗尽再报警更早发现问题
事务内混入 HTTP 调用或文件读写，锁时间直接失控
MySQL 只认 BEGIN 到 COMMIT 的时间，不管你在事务里 sleep(5) 还是调第三方 API 花了 3 秒——它都算作“锁持有中”。
- 典型现象：
SHOW PROCESSLIST看到一堆Sleep连接，INNODB_TRX里TRX_STARTED时间戳比现在早几分钟，但TRX_STATE = RUNNING，说明事务开着但没发 SQL - 禁止写法：
@Transactional方法里直接调RestTemplate.getForObject()；必须拆成：查数据 →TransactionSynchronizationManager.unbindResource()或手动 commit → 再调外部服务 → 再开新事务写回 - 检查手段：用 AOP 在事务方法入口打日志，记录耗时；结合 SkyWalking 或 Arthas 抓出事务内实际执行路径，而不是只看 SQL 执行时间
最常被忽略的一点：意向锁本身不可见、不可手动释放，它完全由事务生命周期驱动。所谓“防止堆积”，本质是确保事务不跨非 DB 操作、连接不长期空闲、锁等待不无限延长——所有配置最终都要回归到这三件事上，缺一不可。
