背景介绍
数据库症状：系统高负载情况下错误日志中出现long semaphore wait信息,数据库实例本身hang住，无法提供正常的访问服务，可登录，但登录后任何操作没有反应。
数据库版本：8.0.20
操作系统版本：CentOS 7.6
主机信息：32GB内存，CPU 16cores
数据库架构：单实例MySQL
处理方式
鉴于业务端无法正常使用DB，故只能通过操作系统层面执行命令 kill -9的方式临时杀进程重启MySQL实例，以最短的时间恢复DB正常使用。
概念：
long semaphore waits 是什么？ --信号量，控制资源的并发访问 这里是信号量的等待，Semaphore就像可以容纳N人的房间，如果人不满就可以进去，如果人满了，就要等待有人出来。
背景
Innodb使用了mutex和rw_lock来保护内存数据结构，同步的机制要么是互斥，要么是读写阻塞的模式。
Innodb认为mutex和rw_lock hold的时间足够短，所以，如果有线程wait mutex或者rw_lock时间过长，那么很可能是程序有bug，所以就会异常主动crash。
trx_sys事务锁：
获取mutex锁：innodb在每个事务中，需要扫描当前已经打开的事务列表trx_list，并拷贝没有提交的事务ID。在扫描事务列表trx_list时，会使用kernel_mutex加锁，这也是性能的最大瓶颈之处。
latch又是什么?
latch一般称为闩锁（轻量级别的锁），因为其要求锁定的时间必须非常短。若持续的时间长，则应用的性能会非常差。在Innodb存储引擎中，latch又可以分为mutex（互斥量）和RW-Lock（读写锁）。其目的是用来保证并发线程操作临界资源的正确性，并且通常没有死锁检测的机制。
对于InnoDB存储引擎中的latch，可以通过命令SHOW ENGINE INNODB MUTEX来进行查看。
总结： 上面描述信息可能会有些发散，但我们归纳一下，基本上是有很多信息来自于锁:mutex 或者lock相关，也就是说MySQL在发生问题的时候产生了大量锁信息，有什么异常导致了MySQL内部产生锁导致。
总结：
大量语句并发访问相同对象，造成锁等待（mutex， rwlock这些内存锁），多线程通过轮询的方式调用系统层面的同一个共享对象/资源，当过多频繁调用，处理跟不上时会产生阻塞，夯住等现象，严重时导致DB不可用。
解决方案
提交开发相关SQL，update，delete和全表扫语句，存储过程中建议优化的SQL语句。
开发整改后，现象消失：降低SQL执行时间，减少锁等待时间。
数据库层面关闭自适应哈希索引。
原文链接：https://blog.csdn.net/mofashi_ww/article/details/135352192
