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