信号量等待本质是InnoDB多层资源瓶颈叠加所致，需优先排查长事务、缺失索引和磁盘IO饱和，而非直接调参或重启。
MySQL InnoDB 在高并发更新时出现信号量等待，本质是内部资源争用暴露出来的症状，不是“偶然故障”，而是锁、缓冲池、IO 或内核信号量等多层瓶颈叠加的结果。直接改 innodb_lock_wait_timeout 或重启服务，基本无效。
信号量等待 ≠ 锁等待，但常由锁等待引发
InnoDB 用信号量（semaphore）保护关键共享资源，比如缓冲池页、字典缓存、插入缓冲区、事务系统结构体等。当线程申请这些资源被阻塞超过 600 秒，日志就会报 InnoDB: Warning: a long semaphore wait。
常见诱因包括：
-
row0ins.cc行插入卡住：高并发 INSERT/UPDATE 没走索引，触发全表扫描+行锁升级，大量线程挤在插入缓冲（insert buffer）或聚簇索引页上抢 RW-latch -
mtr0mtr.ccmini-transaction 卡住：大事务修改大量页，未及时刷脏，导致 mtr 提交时反复等待日志写入或页刷新完成 - DDL 操作（如
ALTER TABLE）持有字典锁（dict0dict.cc），阻塞后续所有 DML 的元数据访问 - 长事务未提交，持续持有行锁+间隙锁，其他事务在相同索引范围反复尝试加锁失败，最终退化为等待底层信号量
Linux 内核信号量参数过小会放大问题
MySQL 依赖系统级信号量做线程同步。若 /proc/sys/kernel/sem 第三列（semopmax）太小（默认常为 32），高并发下大量线程同时调用 semop() 就会排队，加剧等待。这不是 MySQL bug，是 OS 层面的资源配额不足。
检查和调整方法：
- 运行
cat /proc/sys/kernel/sem，看输出四列值，重点关注第三列（单次 semop 最大操作数） - 临时生效：
echo "kernel.sem = 250 32000 100 128" >> /etc/sysctl.conf && sysctl -p - 注意：仅调大第三列（如从 32 → 100），不要盲目调高全部；该参数影响全局进程，需配合压测验证
真正该优先排查的三个地方
信号量等待是现象，背后必有更上游的瓶颈。别一上来就查内核参数或源码行号，先确认这三项：
- 是否存在运行超 60 秒的事务？查
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - TRX_STARTED) > 60，重点看TRX_QUERY和TRX_STATE - UPDATE/DELETE 是否缺失索引？用
EXPLAIN看执行计划是否出现type: ALL或rows过大；没有索引的 WHERE 条件会让行锁变成隐式全表扫描锁 - 磁盘 IO 是否饱和？
iostat -x 1观察%util是否长期 >90、await是否突增到 50ms+；InnoDB 刷脏慢会拖垮整个 latch 链路
最容易被忽略的一点：很多信号量等待日志里带 btr0cur.cc 或 buf0buf.cc，表面看是 B+ 树游标或缓冲池问题，实际根源可能是某张表的二级索引严重碎片化，或者 innodb_buffer_pool_size 设置远小于热数据集——这时再怎么调内核参数也没用，得先做索引重建或扩容 buffer pool。
