大事务导致InnoDB锁信息“溢出”主因是未提交的undo log、行锁、锁等待链和MVCC版本链持续占用Buffer Pool及内存结构；当duration_sec＞300且trx_state为'RUNNING'或'LOCK WAIT'时，内存压力剧增，可能触发缓冲池读飙升或OOM Killer杀进程。
为什么大事务会让 InnoDB 锁信息“溢出”
不是锁本身占内存，而是大事务持续运行时，InnoDB 必须维护大量未提交的 undo log、行锁记录、锁等待链和 MVCC 版本链——这些全堆在 Buffer Pool 和内存结构里。当 duration_sec 超过 300 秒且 trx_state 是 'RUNNING' 或 'LOCK WAIT'，就说明锁信息已开始挤压内存空间，轻则触发 Innodb_buffer_pool_reads 暴涨，重则直接被 OOM Killer 杀掉进程。
怎么快速定位正在吃内存的大事务
别等崩溃再查，用这条语句实时抓：
SELECT trx_id, trx_state, trx_started, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration_sec, trx_mysql_thread_id, SUBSTRING_INDEX(trx_query,' ', 5) AS query_head FROM information_schema.INNODB_TRX ORDER BY duration_sec DESC LIMIT 3;
- 重点关注
duration_sec > 300且trx_state IN ('RUNNING', 'LOCK WAIT')的记录 - 如果
query_head是UPDATE ... WHERE created_at > '2025-01-01'这类无索引范围更新，基本就是元凶 - 补查锁等待链：
SELECT * FROM information_schema.INNODB_LOCK_WAITS;，确认是否形成环或长链 - 回溯该线程历史操作：
SELECT * FROM performance_schema.events_statements_history_long WHERE thread_id = ? ORDER BY event_id DESC LIMIT 10;（把 ? 替换为上面查出的trx_mysql_thread_id）
KILL 之前必须知道的三件事
直接 KILL 看似快，但可能让内存压力更猛：
-
KILL只中断执行，事务进入回滚阶段，undo log 反而要重放+释放，瞬时内存峰值更高 - 若该事务已持有大量行锁，
KILL后锁不会立刻释放，其他会话仍卡在LOCK WAIT，Buffer Pool 继续被占 - 回滚时间 ≈ 已执行时间 × 1.2～2 倍（尤其涉及大 BLOB/TEXT 字段时），期间
innodb_buffer_pool_pages_dirty持续上涨
真正稳妥的做法是：先用 SET GLOBAL innodb_lock_wait_timeout = 3; 缩短后续新锁等待超时；再对目标事务做 KILL QUERY（仅终止当前语句，不回滚整个事务）；最后观察 SHOW ENGINE INNODB STATUS\G 中 TRANSACTIONS 部分是否逐步清空。
避免锁信息挤爆内存的配置底线
光杀事务治标，调参才是治本。以下几项必须协同调整：
-
innodb_buffer_pool_size不要设成物理内存的 90%，混合部署建议 ≤ 50% —— Buffer Pool 不只是缓数据，还存锁结构、自适应哈希索引、change buffer，超配等于给锁信息预留“豪华单间” -
max_connections和sort_buffer_size要一起看：比如 500 连接 × 4MB = 2GB，这部分和 Buffer Pool 是叠加关系，不是互斥 - 禁用
query_cache_type（MySQL 5.7+ 默认关闭），残留配置会抢内存；key_buffer_size设为 0（除非真用 MyISAM） - 临时表相关：把
tmp_table_size和max_heap_table_size统一设为 64M，防止SELECT ... GROUP BY无声无息建出几百 MB 的 MEMORY 表
最易被忽略的是：Buffer Pool 实例数 innodb_buffer_pool_instances 设太小（如默认 1）会导致高并发下锁结构争抢同一 chunk mutex，加剧内存分配抖动——16GB 内存机器建议设为 4，32GB+ 可设 8，但别超过 CPU 核心数。
