mysql的wait_events表不采集内核信号量锁事件，因其属os层原语；应结合performance_schema同步对象等待、perf调度分析、/proc状态及strace追踪semop调用综合诊断。
Wait_Events 表里根本查不到信号量锁相关事件
MySQL 的 performance_schema.events_waits_summary_global_by_event_name 或线程级等待汇总，压根不采集内核层信号量（如 semop、semctl）的等待。这些是操作系统内核原语，MySQL 自身无感知，wait/io/、wait/synch/ 下所有事件都停留在用户态同步机制（如 mutex、rwlock、cond）层面。想靠 events_waits_history_long 找 “semaphore contention”，注定为空。
真正该盯住的是 performance_schema 中的 sync_object 等待和 OS 层指标联动
内核信号量竞争往往反映为 MySQL 内部同步对象（尤其是 wait/synch/mutex/innodb/ 和 wait/synch/rwlock/innodb/）的高延迟或长等待次数，但根源可能在 OS 调度或资源争抢。此时需交叉验证：
- 查
performance_schema.events_waits_summary_by_thread_by_event_name，过滤出wait/synch/mutex/innodb/类事件中SUM_TIMER_WAIT异常高、且COUNT_STAR大的线程（对应THREAD_ID） - 用
ps -T -p $mysqld_pid查出该线程的 LWP ID，再结合perf record -e sched:sched_stat_sleep,sched:sched_switch -p $lwp_id -g -- sleep 10捕获调度行为 - 观察
/proc/$mysqld_pid/status中的voluntary_ctxt_switches和nonvoluntary_ctxt_switches—— 后者突增常伴随信号量休眠唤醒频繁
用 strace 抓实时 semop 调用确认是否真有内核锁竞争
当怀疑是信号量导致卡顿，最直接的方式是动态追踪 mysqld 进程的系统调用：
strace -p $mysqld_pid -e trace=semop,semctl,shmat,shmdt -T 2>&1 | grep -E "(SEM_OP|TIMEDOUT|EAGAIN|EINTR)"
若持续看到 semop(..., IPC_NOWAIT) = -1 EAGAIN 或长时间阻塞在 semop 返回（<... semop resumed> ) = 0</...> 且耗时 >10ms，基本可断定内核信号量队列积压。注意：启用 strace 本身有开销，仅用于短时诊断，不可长期开启。
innodb_sync_array_size 和 innodb_spin_wait_delay 不解决内核信号量问题
这两个参数调优针对的是 InnoDB 用户态自旋锁行为，影响的是进入内核等待前的忙等时长。它们无法缓解已落入内核态的 semop 阻塞。真正要降低信号量竞争概率，得从源头减负：
- 避免单实例承载过多并发连接（尤其短连接风暴），控制
max_connections并搭配连接池 - 检查是否启用了
innodb_adaptive_hash_index = ON—— 高并发 DML 下它会加剧 buffer pool 共享结构的锁争用，间接推高底层信号量请求频率 - 确认文件系统未使用 ext3（其 jbd 进程与 MySQL 写入易在信号量上冲突），优先用 xfs 或 ext4
内核信号量问题从来不是单点配置能绕过的，它暴露的是负载模型与 OS 资源分配之间的错配。盯着 events_waits_summary 找不到答案，是因为那根本不是 MySQL 的观测边界。
