mysql 社区版本8.0.23 重启

可以打开日志分析，从946行开始，提示  A long semaphore wait，这通常是因为 InnoDB 内部的 mutex 或者 lock 互斥等待

这表示系统负载太高了，也可能是因为叠加了某些bug导致

当信号量互斥等待事件 持续太久（记得是900秒）后，MySQL 就会自行重启（不重启的话其他啥也做不了，也没意义）

可以看日志 26222 行，关键信息
--Thread 139608855705344 has waited at trx0undo.ic line 129 for 928 seconds the semaphore:

可能原因及可选解决办法
1. 垃圾SQL太多，需要进行优化垃圾SQL，能看到有些事务修改多行记录，看起来效率也很低
2. 数据库层面关闭自适应哈希索引（innodb_adaptive_hash_index = OFF），也可能是这个引起的
3. 加强监控，不少事务活跃时间太久了，一直没提交。垃圾SQL（事务）长时间不结束，会占用更多资源，之后一起玩完。参考 https://greatsql.cn/docs/8.0.32- ... g-and-alerting.html
4. 可能系统层I/O设备有故障，能看到多个事务处于PREPARED状态，此时可能因为物理I/O设备故障导致无法提交/刷新数据。
5. 最后建议升级到 GreatSQL 8.0.32-25 版本，相对MySQL社区版更稳定可靠。

yejr 发表于 2024-5-24 17:19
可以打开日志分析，从946行开始，提示  A long semaphore wait，这通常是因为 InnoDB 内部的 mutex 或者 lo ...

感谢大佬指点

yejr 发表于 2024-5-24 17:19
可以打开日志分析，从946行开始，提示  A long semaphore wait，这通常是因为 InnoDB 内部的 mutex 或者 lo ...

开源版本的MYSQL问题不少啊，如果企业客户没有技术能力强悍的内核开发人员，还真解决不了。

15167759230 发表于 2024-5-24 19:43
开源版本的MYSQL问题不少啊，如果企业客户没有技术能力强悍的内核开发人员，还真解决不了。 ...

所以才要选择万里数据库这种能提供内核支持的团队啊 ：）