# MySQL运维避坑案例整理
> 整理自用户提供的《新炬运维避坑指南合集》41 篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 **34 个案例**。期数按专辑标题编号；来源链接取自离线文章元数据。
[查看或下载 Markdown 原稿](新炬运维避坑案例整理.md)
## 案例目录
- [第 41 期｜MySQL swap 90%+并逐渐耗尽问题分析](#case-1)
- [第 39 期｜MySQL 备份恢复后启动数据库报错问题分析](#case-2)
- [第 38 期｜MySQL迁移达梦微服务无法正常启动问题分析](#case-3)
- [第 38 期｜MySQL迁移达梦 平台功能无法正常使用问题分析](#case-4)
- [第 34 期｜MySQL重建主备问题分析](#case-5)
- [第 34 期｜MySQL赋权使用通配符时可能出现权限覆盖问题](#case-6)
- [第 33 期｜mysql复制延迟及数据一致性问题](#case-7)
- [第 33 期｜MySQL备份异常](#case-8)
- [第 33 期｜mysql数据库磁盘使用率异常](#case-9)
- [第 33 期｜mysql数据库服务不可用](#case-10)
- [第 31 期｜mysql无法正常备份](#case-11)
- [第 31 期｜mysql定时任务不跑](#case-12)
- [第 27 期｜MYSQL数据库排序规则报错 ERROR 1267](#case-13)
- [第 27 期｜mysql主库的服务器由于硬件问题导致服务器宕机重启](#case-14)
- [第 26 期｜MYSQL数据库](#case-15)
- [第 26 期｜MYSQL数据库](#case-16)
- [第 22 期｜MySQL双主单写集群的从节点报错主从复制中断](#case-17)
- [第 22 期｜MySQL存在主从延迟](#case-18)
- [第 21 期｜MySQL测试环境修改root密码报错](#case-19)
- [第 21 期｜mysql从库故障，报错重复的分区名](#case-20)
- [第 21 期｜mysql备库日志应用延迟问题分析](#case-21)
- [第 13 期｜mysql5.7升级版本后版本回退导致数据文件损坏](#case-22)
- [第 12 期｜MYSQL主从从复制从库中断处置](#case-23)
- [第 10 期｜mysql从库延迟持续增长，从库长时间卡在insert into as select事务上](#case-24)
- [第 10 期｜mysql误删数据恢复](#case-25)
- [第 10 期｜mysql执行一条join语句很慢](#case-26)
- [第 7 期｜mysql二进制日志未自动清理处置](#case-27)
- [第 6 期｜Mysql 性能全面下降，业务访问超时无响应](#case-28)
- [第 4 期｜MYSQL单表损坏恢复](#case-29)
- [第 4 期｜MYSQL主从同步延迟处置](#case-30)
- [第 3 期｜MYSQL从库的延迟告警处置](#case-31)
- [第 3 期｜MYSQL主从同步异常处置](#case-32)
- [第 2 期｜mysql频繁崩溃重启，导致业务中断](#case-33)
- [第 2 期｜MySQL数据库被业务误删除](#case-34)
## 第 41 期｜MySQL swap 90%+并逐渐耗尽问题分析
- 专辑文件：`01.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247568126&idx=1&sn=5c70643df2d7921483070f36dfc24fa2&chksm=f88d5afc1c9d4ff2e8d61031f12da621c29e3d27be34c690bf1fa4fe8a3b8cb6840422f97ffb#rd)
- **现象：** MySQL所在龙蜥8.6服务器swap 90%+并逐渐耗尽，物理内存使用不到40%，/etc/sysctl.conf中配置的vm.swappiness=1，即尽可能的使用内存，实际却是尽可能使用swap，vm.swappiness=1并未生效。；测试在龙蜥8.6 、centos 8.5中都会出现此（4.x内核），在centos 7.9中不会出现此。；/sys/fs/cgroup/memory/system.slice/mysqld.service/memory.swappiness
- **处置过程：** cat /proc/$(pidof mysqld)/cgroup --> "2:memory:/system.slice/mysqld.service" mysqld进程已经被放进 system.slice/mysqld.service 这个 cgroup;；cat /sys/fs/cgroup/memory/system.slice/mysqld.service/memory.swappiness --> 60 该值并不为1;
- **运维建议：** 永久固化 MySQL 服务 cgroup 的 swappiness 配置，将其固定为 1，保证数据库优先使用物理内存，严控 Swap 使用；完善同类操作系统参数配置标准，针对 4.x 内核系统，新增 cgroup 内存参数检查项，统一数据库服务配置规范；增加服务器 Swap 使用率监控告警，及时发现异常置换行为，提前干预处置
## 第 39 期｜MySQL 备份恢复后启动数据库报错问题分析
- 专辑文件：`03.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567258&idx=1&sn=cb8acfe46934b2308d8a1d2fdffbd82d&chksm=f86bd7bd1375aa91592abd5c32a6a03bcf4bf5511b5019700146f1431f58d23e38d09f81e217#rd)
- **现象：** 备份恢复后启动数据库报错。
- **处置过程：** 问题一：无法打开undo tablespace；备份恢复完成无报错，启动数据库失败，报错提示；unable to open undo tablespace
- **运维建议：** 备份恢复前，必须将源库 my.cnf 完整同步到目标库，仅修改路径，不改动业务参数；innodb_undo_tablespaces、innodb_redo_log_capacity、plugin_load；等关键配置
## 第 38 期｜MySQL迁移达梦微服务无法正常启动问题分析
- 专辑文件：`04.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566942&idx=1&sn=beb8d9dedea5fbd7b5f81620ec6c1ee9&chksm=f88cfa4e3c4c1978f4683d85661e69ba8b3c849532f6c72297a026479f161a1222e1a769f6c5#rd)
- **现象：** 使用flyway迁移，微服务无法正常启动。
- **处置过程：** 使用flyway迁移微服务；发现服务一直启动不了，通过查看日志发现关键报错；“Schema ""snc_data_platform"" contains a failed migration to version 1.41.0.202503271100 ”
- **运维建议：** 微服务启动失败优先排查 Flyway 迁移状态；快速删除失败记录恢复服务。；MySQL 迁移达梦必须做 SQL 脚本适配
## 第 38 期｜MySQL迁移达梦 平台功能无法正常使用问题分析
- 专辑文件：`04.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566942&idx=1&sn=beb8d9dedea5fbd7b5f81620ec6c1ee9&chksm=f88cfa4e3c4c1978f4683d85661e69ba8b3c849532f6c72297a026479f161a1222e1a769f6c5#rd)
- **现象：** 对cmdb服务数据库从mysql迁移到达梦后，平台功能无法正常使用。
- **处置过程：** 迁移达梦后服务正常启动无异常报错；主要异常情况有以下几点；平台再接入主机的时候，观测洞察中不能同步监控指标情况，监控模板中可以正常获取到样本数据，查看服务也没看见报错信息，流批也正常运行中；
- **运维建议：** clobAsString=1（或clobAsString=true）是达梦数据库JDBC连接URL中的一个关键参数，主要作用是将数据库中的CLOB（含TEXT）大文本字段直接映射为Java字符串类型，以简化开发中的数据处理；达梦JDBC驱动默认将CLOB字段映射为dm.jdbc.driver.DmdbClob对象，而非直接的Java字符串；这意味着当你查询CLOB字段时，ResultSet.getObject()返回的是一个CLOB对象的地址（如`dm.jdbc.driver.DmdbNClob@3b*****`），而不是实际的文本内容。尝试直接使用该对象进行序列化、JSON转换或字符串拼接时，极易出现类型转换异常。
## 第 34 期｜MySQL重建主备问题分析
- 专辑文件：`08.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565290&idx=1&sn=2eb4aab29ad488b7725e5c6e405ba395&chksm=f811046cbfbaa3f59adfb44e20f36ead80b5ea06f11d7b5c428d3ff5cc0b33e6df6446c0b3c8#rd)
- **现象：** 客户MySQL架构为级联主备，主-->备-->备库的备，由于备库的备只是作为应急恢复使用，不影响业务正常使用，所以没有配备告警，导致同步延迟不断积累已经差异1月左右，无法自动恢复，需要重建主备。
- **处置过程：** 由于客户担心主备断连，会有风险，所以经最后验证确认，；决定使用XtraBackup热备进行恢复。；在BCLinux系统安装xbk，需要把libgcrypt.so.11、libgcrypt.so.11.8.2上传到/usr/lib64下 否则无法使用。
- **运维建议：** 生产环境必须实施全面的监控覆盖，以主动发现并规避潜在风险；备份策略应严格依据系统架构进行定制，确保其有效性及可恢复性
## 第 34 期｜MySQL赋权使用通配符时可能出现权限覆盖问题
- 专辑文件：`08.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565290&idx=1&sn=2eb4aab29ad488b7725e5c6e405ba395&chksm=f811046cbfbaa3f59adfb44e20f36ead80b5ea06f11d7b5c428d3ff5cc0b33e6df6446c0b3c8#rd)
- **现象：** MySQL赋权使用通配符时可能出现权限覆盖的问题。
- **处置过程：** mysql> show grants ;；+-----------------------------------------------+；| Grants
- **运维建议：** 尽量不要使用对数据库的通配赋权
## 第 33 期｜mysql复制延迟及数据一致性问题
- 专辑文件：`09.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564523&idx=1&sn=c8803dd8c63037aa584df7b8066885b5&chksm=f8a6eb1d08fa541fe00a67de53f6231f35a27610eadaf907f9f6b337f9eb86d055b16ce1515b#rd)
- **现象：** 关于MySQL复制延迟及数据一致性问题。
- **处置过程：** MySQL主从复制效率低下，一直被诟病，复制延迟可能影响故障切换的响应时间；；由于配置及管理因素也常常引发主从数据不一致；复制延迟及一致性问题可能导致严重的业务风险。
- **运维建议：** 确保binlog格式为rowW；；谨慎设置slave-skip-errors,修复主从错误时谨值跳过错误或事务；；设置备库只读，避免误操作从库；
## 第 33 期｜MySQL备份异常
- 专辑文件：`09.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564523&idx=1&sn=c8803dd8c63037aa584df7b8066885b5&chksm=f8a6eb1d08fa541fe00a67de53f6231f35a27610eadaf907f9f6b337f9eb86d055b16ce1515b#rd)
- **现象：** 因业务需要重新搭建备库，MySQL数据库主库全量备份报错。；LSN不匹配导致MySQL备份异常。
- **排查与原因：** 这套库是从别的库复制过来的，业务复制的时候导致LSN与实际的LSN不一致。；备份复制的数据页比日志更新，导致无法通过日志恢复一致性。；备份期间持续写入
- **处置过程：** 检查表文件完整性（无异常）；；调整重做日志配置（未解决）；；重做备份-使用mysqldump进行逻辑备份全库，再导入备库搭建主从同步。
- **运维建议：** 该从库原先是业务侧搭建的；；实施方案需经过评审。
## 第 33 期｜mysql数据库磁盘使用率异常
- 专辑文件：`09.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564523&idx=1&sn=c8803dd8c63037aa584df7b8066885b5&chksm=f8a6eb1d08fa541fe00a67de53f6231f35a27610eadaf907f9f6b337f9eb86d055b16ce1515b#rd)
- **现象：** mysql数据库磁盘使用率异常上升（一天上涨大概300G）。
- **处置过程：** 排查发现数据库五分钟binlog日志平时十几M现在激增至2G左右，查看当前数据库是否有长事务会话和执行频率高的更新删除语句，查看发现有几十万条更新语句一直在执行。；因为业务使用canal来监听数据库binlog日志，一直未释放磁盘，在数据库找到异常的binlog连接，kill会话，因为canal有重连机制，还会读取断开时间点的日志，在canal上找到kill是异常的日志，确定是哪个任务。；删除对应的canal任务，重建后数据库磁盘释放。
- **运维建议：** 第三方系统一直推送异常数据，kafka消费异常，代码上存在循环更新错误逻辑，五分钟就会更新200万条数据。
## 第 33 期｜mysql数据库服务不可用
- 专辑文件：`09.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564523&idx=1&sn=c8803dd8c63037aa584df7b8066885b5&chksm=f8a6eb1d08fa541fe00a67de53f6231f35a27610eadaf907f9f6b337f9eb86d055b16ce1515b#rd)
- **现象：** 业务高峰期时，认证系统的采购服务用户反馈服务不可用，同时监控也发出多个应用服务拨测超时的告警。应用组对purchase-service服务做内存快照及线程快照，线程无阻塞，进入等待线程发现疑似有线程死锁情况，其他方面内存、磁盘、负载、cpu、网络均无异常。数据库查看只有几条执行了4分钟左右的SQL，开发反馈与该SQL无关。；应用同事将连接池连接数配置从8修改为200，并重启purchase-service服务，告警恢复，但一段时间后告警重新出现。此时查看数据库，发现有60多个线程在运行该SQL，执行时间超过10分钟。
- **处置过程：** 该SQL（多表联查）执行计划虽然均走索引，但是其中一张表使用的索引效率很低，开发反馈该业务近期没有改动，过去该SQL执行正常也很快。；在上周五夜间，业务组有上线操作，对该SQL中的一张表写入了80多万行数据，数据发生较大变化，导致相关业务SQL执行计划改变，周一业务高峰期查询性能下降。；删除该低效索引；
- **运维建议：** 当该参数condition_fanout_filter值为ON时；优化器在估算多表连接的行数时，会结合存储引擎层过滤（基于索引的 rows 值）和 Server 层过滤（基于 WHERE 条件的 filtered 值），最终行数估算公式为：rows × filtered / 100；；当设置为 OFF时
## 第 31 期｜mysql无法正常备份
- 专辑文件：`11.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563572&idx=1&sn=a1a1d2d99648a7eb07a728a262bf1174&chksm=f8e81ffa8afda84dad2f023ac6523d6c54e59de7815ea6d2468289bceebfd6d4c4238c2ad2d4#rd)
- **现象：** mysql-xtrabackup备份时发生堵塞，无法正常备份。
- **处置过程：** 检查备份日志；备份日志中出现长事务导致备份无法完成.分析长事务的sql，优化完sql后，备份正常。；xtrabackup备份时添加了ftwrl-wait-timeout参数，但是没有添加kill-long-queries-timeout参数。
- **运维建议：** 使用xtrabackup备份时，如果开启ftwrl-wait-timeout参数,可同步添加kill-long-queries-timeout参数和kill-long-query-type=select参数，避免备份时出现堵塞。
## 第 31 期｜mysql定时任务不跑
- 专辑文件：`11.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563572&idx=1&sn=a1a1d2d99648a7eb07a728a262bf1174&chksm=f8e81ffa8afda84dad2f023ac6523d6c54e59de7815ea6d2468289bceebfd6d4c4238c2ad2d4#rd)
- **现象：** Mysql数据库开了定时任务，但是任务不跑，需要排查原因。
- **处置过程：** Show variables like ‘%event%’,event_scheduler参数开启；手动创建event；发现event确实不跑。
- **运维建议：** 需要对mysql-error日志进行监控分析，如果出现error级别的错误通过短信告警的方式通知出来，避免出现定时任务不跑导致数据丢失的情况。
## 第 27 期｜MYSQL数据库排序规则报错 ERROR 1267
- 专辑文件：`15.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562000&idx=1&sn=8c906945a61862b190e5d4e425f949b4&chksm=f88e88553a72b2d8ffa17f7835b3d93ee7ad2f5a5f5719a161a343b041194351ba125fd68b1e#rd)
- **现象：** MySQL8.0.21调用视图，排序规则报错；ERROR 1267；(HY000): Illegal mix
- **处置过程：** 查看视图定义；发现涉及到的俩张表的字符集排序规则不同，创建视图时 MySQL 会自动使用 convert 函数转换字符集，；mysql8.0 utf8mb4
- **运维建议：** 创建数据库实例时需指定参数；character_set_database（默认值：utf8mb4）；；character_set_server（默认值：utf8mb4）
## 第 27 期｜mysql主库的服务器由于硬件问题导致服务器宕机重启
- 专辑文件：`15.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562000&idx=1&sn=8c906945a61862b190e5d4e425f949b4&chksm=f88e88553a72b2d8ffa17f7835b3d93ee7ad2f5a5f5719a161a343b041194351ba125fd68b1e#rd)
- **现象：** MYSQL数据库；ysql主库的服务器由于硬件问题导致服务器宕机重启，主从切换后，复制报错；Could not
- **处置过程：** 查看高可用组件日志，主从切换的GTID一致，并未丢数；在从库执行show slave status\G；发现从库比主库多了一个GTID，用mysqlbinlog解析这个gtid，发现这个事务涉及的表和报错表是同一张。
- **运维建议：** 本次故障的一个重要教训是，在生产环境中应尽量避免使用非事务表；（如MEMORY表）；内存表虽然具有访问速度快、不占用磁盘空间等优点，但其数据在数据库重启时会丢失，这可能导致复制中断、数据不一致等严重问题。因此，在生产环境中应优先考虑使用事务表
## 第 26 期｜MYSQL数据库
- 专辑文件：`16.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561730&idx=1&sn=03127efd7dfb31578888f6c12a416961&chksm=f8a9b6214a200ad061848edb6ad1a642ecc32c2ddffbde5e0c712542d9d3558824806032f0d5#rd)
- **现象：** 并发查询索引失效,导致cpu打满。
- **处置过程：** 通过processlist抓取当前慢查询，定位到慢sql语句。；查看执行计划、表结构、表中索引和数据分布情况来分析这条SQL，is_hide is null or t.is_hide = '0'约为全表数据，biz_name上有一个区分度较差的索引，但是ignore index限制了该索引的使用，location 为varchar类型，location in (1000,2000,6600,)写法会导致索引失效，且in后面接了超过200个值，即便是值加上单引号书写正确，在MySQL里面也不会走上索引(参数限制eq_range_index_dive_limit，超过限制不会用该索引预估cost，因为dive开销太大)。；所以突破的关键在
- **运维建议：** 清晰了解何种条件下满足索引合并；当查询条件涉及多个字段，且这些字段上都有索引时，可以考虑使用索引合并来优化查询性能。；在优化SQL时，要充分考虑表结构、索引和数据分布情况
## 第 26 期｜MYSQL数据库
- 专辑文件：`16.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561730&idx=1&sn=03127efd7dfb31578888f6c12a416961&chksm=f8a9b6214a200ad061848edb6ad1a642ecc32c2ddffbde5e0c712542d9d3558824806032f0d5#rd)
- **现象：** MySQL主从出现大量延迟。
- **处置过程：** 电渠数据告警延迟，登录数据库中排查发现备库一直卡死到某个gitd中，导致备库执行时间很长，通过解析binlog日志发现为一条delete全表删除语句，该表数据6千万左右，通过和客户业务沟通后，备库跳过该gtid事物，快速恢复备库复制状态。；处理具体步骤；登陆MySQL备库，检查备库延迟状态，获取到执行到主库的binlog
- **运维建议：** 对SQL语句进行严格的评估和测试；从这次故障中，我们深刻认识到DELETE全表数据操作的危害性。在数据量较大的情况下，DELETE全表操作会导致长时间的锁表，进而影响数据库的性能和可用性。；因此，我们在上线前对SQL语句进行严格的评估和测试，禁止使用DELETE全表数据操作。对于需要清空表数据的情况，可以考虑使用DROP TABLE后重新CREATE TABLE的方式，或者使用TRUNCATE TABLE语句。
## 第 22 期｜MySQL双主单写集群的从节点报错主从复制中断
- 专辑文件：`20.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560119&idx=1&sn=ac3ac27b52a1dc3dc065c76f65d347ee&chksm=f88a0a6e919773fa9c8827629aa096351f5593291a841dc5d109e455eccd9957689dc8ea0c9f#rd)
- **现象：** MySQL双主单写集群的从节点，按如下顺序执行变更操作后，主节点业务正常读写，但从节点报错主从复制中断。；基于原表结构创建一个新表；create table
- **处置过程：** 定位详细报错信息，此时错误日志记录的错误信息为；[ERROR] [MY-013146] [Repl] Replica SQL；for channel
- **运维建议：** DDL变更应在主节点执行；在MySQL双主单写集群中，所有DDL变更（如表结构修改、索引创建或删除等）都应在主节点上执行，以确保变更的一致性和同步性。从节点应仅用于数据复制和读取操作，以避免复制中断和数据不一致的风险。；数据一致性
## 第 22 期｜MySQL存在主从延迟
- 专辑文件：`20.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560119&idx=1&sn=ac3ac27b52a1dc3dc065c76f65d347ee&chksm=f88a0a6e919773fa9c8827629aa096351f5593291a841dc5d109e455eccd9957689dc8ea0c9f#rd)
- **现象：** 巡检发现有一套接维的MySQL存在主从延迟的情况，核实表数据较大，检查从库发现某条delete语句执行耗时，导致从库SQL线程一直在执行此事务卡死。
- **处置过程：** 检查MySQL主从状态；存在主从延迟问题。；show full processlist检查MySQL进程
- **运维建议：** 加强SQL审核流程；细化审核标准；在SQL语句上线之前，应建立严格的审核流程，包括但不限于对SQL语句的性能评估、安全性检查以及是否符合数据库设计规范。审核时应特别关注SQL语句是否可能引发性能问题，如全表扫描、大量数据操作等。
## 第 21 期｜MySQL测试环境修改root密码报错
- 专辑文件：`21.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559855&idx=1&sn=6d6126bdf60a61d0700bfbc30a6164cd&chksm=f8ecb6b58fc8f4602cc5f55f65682bff8f616bf575b7f97eb33a866aea324e42d26a2435be1b#rd)
- **现象：** Mysql测试环境-root忘记密码，设置skip-grant-tables修改root密码报错。；error 1396:opeartion；alter user failed for
- **处置过程：** 查看mysql版本：mysql 8.0.31。；查询一下安全模式开关；show variables like
- **运维建议：** 深入了解数据库版本特性；不同的数据库版本在功能和安全性方面可能存在显著差异。在处理特定问题时，首先需要确认数据库的具体版本，以便了解该版本特有的行为、限制和最佳实践。；在本次事件中，我们注意到MySQL 8.0.31版本对sql_safe_updates的设置更为严格，这直接影响了我们尝试通过UPDATE语句直接修改authentication_string字段的能力。
## 第 21 期｜mysql从库故障，报错重复的分区名
- 专辑文件：`21.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559855&idx=1&sn=6d6126bdf60a61d0700bfbc30a6164cd&chksm=f8ecb6b58fc8f4602cc5f55f65682bff8f616bf575b7f97eb33a866aea324e42d26a2435be1b#rd)
- **现象：** mysql从库故障，报错重复的分区名。
- **处置过程：** 查看报错，从库在执行ddl的时候出现了问题，报错原因分区重复。；检查主库和从库的表结构信息，表结构，分区一样。；检查从库是否有添加分区的任务，show events查看发现有一个job在启用。
- **运维建议：** 理解错误本质；分区重复错误；当MySQL在从库执行DDL操作时遇到分区重复的错误，通常意味着尝试创建的分区名称已经存在。这种错误可能是由于同步过程中的数据不一致或配置错误导致的。
## 第 21 期｜mysql备库日志应用延迟问题分析
- 专辑文件：`21.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559855&idx=1&sn=6d6126bdf60a61d0700bfbc30a6164cd&chksm=f8ecb6b58fc8f4602cc5f55f65682bff8f616bf575b7f97eb33a866aea324e42d26a2435be1b#rd)
- **现象：** mysql备库日志应用延迟，sql_thread提示等待 Waiting for Replica Worker queue，延迟161143+秒。
- **处置过程：** show processlist查看等待的执行语句，delete from t where date>'2021-01-01';分析表上无主键、无索引，数据量400w+，删除行数200w+。；典型的无主键大数量操作导致延迟的问题。row模式的同步在备库这种情况，其实是要进行200w+次全表扫描，即使使用了batched delete，也是很庞大的操作量。；处理方案可选的有
- **运维建议：** 强化数据表创建标准；主键的重要性；在数据库设计中，主键是不可或缺的一部分。它不仅帮助唯一标识表中的每一行，还能极大地提升查询、更新和删除操作的效率。
## 第 13 期｜mysql5.7升级版本后版本回退导致数据文件损坏
- 专辑文件：`29.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247553647&idx=1&sn=a4e3034acc8ffb27e39eeeba5ab3d053&chksm=f8ee8d04a3f80fd5f349f67890eef740ef2bd2e9c34b4805420d6d8fee25f6181b4f53cba4a5#rd)
- **现象：** mysql5.7升级mysql8版本回退出现引发数据文件损坏，数据库启动失败。
- **处置过程：** 通过分析数据库日志，当回退mysql版本到5.7时，以mysqld_safe安全方式启动mysqld进程，拉起服务时读取ibdata共享表空间文件失败，无法加载表元数据到服务层；初步判断ibdata数据文件损坏。；由于备份共享存储空间不足，导致最近的备份失败，所以无法采用全备方式来恢复数据
- **运维建议：** 在进行任何升级或回退操作之前，详细评估版本兼容性和官方文档，确保所有步骤符合最佳实践和兼容性指南；强化数据备份机制，确保备份任务的成功执行，并定期验证备份数据的完整性和可恢复性；扩展或优化备份存储空间，避免由于存储空间不足导致的备份失败
## 第 12 期｜MYSQL主从从复制从库中断处置
- 专辑文件：`30.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552823&idx=1&sn=9693ecf3a5d69404fc032c4793a7f490&chksm=f85b749fb8c5158e15da1fdec6ed0ca79c79038f8b7842455dec3e42fe349048f133597fcc9c#rd)
- **现象：** 业务mysql以主从从的方式进行搭建，其中主从io进程断开，导致主从从失败。
- **处置过程：** 因国产化系统替换，数据库迁移到国产BC系统，执行数据交换任务，以全量数据写入的方式写入当天最新的数据，对应写入的表数据量较大，缓冲区过小，心跳机制检查失误产生报错。根据告警时间，定位到具体的数据交换任务。；调整任务时间，使其错开执行，未再出现 IO 复制异常的问题。
- **运维建议：** 尽量避免一次性提交大量更改：将大型事务拆分为较小的子事务，并在每个子事务之间定期提交，以减轻IO压力。
## 第 10 期｜mysql从库延迟持续增长，从库长时间卡在insert into as select事务上
- 专辑文件：`32.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247551782&idx=1&sn=3f4082f334675de4fbfeed4c1b694d0d&chksm=f8672a0da5e362ca96f9b36b5dc6a8bc14c98dd5cb0d14a149dc1b2ff52b5a6d8b42d5083ced#rd)
- **现象：** mysql从库延迟持续增长，从库长时间卡在insert into as select事务上。；由于业务主库数据不受影响，卡住的事务只能等待执行完成后追加延迟事务，通过该像业务发起性能优化；业务文本字段使用专门的文本存储，数据库放文本存储的地址。
- **处置过程：** 查看卡住事务走索引，不存在sql性能问题；；检查insert数据大小差不多3万多条，数据量也不大；；检查表结构发现表有2个大文本字段，通过统计发现数据大小差不多2G；
- **运维建议：** 文本字段使用专门的文本存储，数据库放文本存储的地址。
## 第 10 期｜mysql误删数据恢复
- 专辑文件：`32.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247551782&idx=1&sn=3f4082f334675de4fbfeed4c1b694d0d&chksm=f8672a0da5e362ca96f9b36b5dc6a8bc14c98dd5cb0d14a149dc1b2ff52b5a6d8b42d5083ced#rd)
- **现象：** 业务反馈一张表执行delete操作没加where 条件，需要进行数据恢复。
- **处置过程：** 定位业务操作删除时间点范围，查询当前binlog日志类型是否为row；；通过业务方提供时间点，解析对应binlog日志，找到binlog日志中删除表的gtid、位点信息，记录下位点；；通过binlog2sql解析原数据binlog特定位点之间进行内容，生成反向业务sql语句；
- **运维建议：** 定期对于数据的全备、binlog备份做检查，通过自动化平台每天早上巡检，巡检结果邮件通知，保障数据库的可用性和可靠性。；对于恢复的业务数据验证，需要在测试环境进行校验，不要直接导入至生成环境中，以防导入数据有问题和重新再导入，影响现有生产环境性能。；执行相应删除操作，需特别注意，最好双人复核，减少人为操作引起的故障。
## 第 10 期｜mysql执行一条join语句很慢
- 专辑文件：`32.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247551782&idx=1&sn=3f4082f334675de4fbfeed4c1b694d0d&chksm=f8672a0da5e362ca96f9b36b5dc6a8bc14c98dd5cb0d14a149dc1b2ff52b5a6d8b42d5083ced#rd)
- **现象：** 业务反馈一条关联join语句执行很慢，查询时间超过半小时左右。
- **处置过程：** 找到业务提供相应的sql语句或通过查询相应慢日志；；查询对应的关联表结构和相应表的数据量大小；；通过初步分析，join关联语句后面条件判定确实满足驱动表为小表，被驱动表所查询的列为索引；
- **运维建议：** 业务低峰期修改表字符集，保证join关联语句生效；；业务修改后，目前该语句得到了优化，查询时间从未优化前半小时左右，提升到几分钟内。；注意隐藏的转换，如字符串类型等于整型、被驱动表查询的列未使用到索引、索引查询数量大于30%等；
## 第 7 期｜mysql二进制日志未自动清理处置
- 专辑文件：`35.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247548418&idx=1&sn=26252ff7559fe5a415057991c65fb400&chksm=f8e206d71ca6c58cda2f9738f9c6135e14f34d93d75c26026f6f95b4243c7ee87399027622a0#rd)
- **现象：** mysql8.0.23，二进制日志未自动清理，设置了binlog_expire_logs_seconds的值，由于日志未自动清理，导致挂载点使用率过高报警。
- **处置过程：** 经过查询mysql8.0存在以下两个参数；expire_log_days和binlog_expire_logs_seconds两个参数，binlog_expire_logs_seconds的优先级高于expire_log_days。binlog_expire_logs_seconds的值设置为604800（单位秒，即7天），expire_log_days的值为0（表示日志不自动清理）。；经过检查发现，在修改过参数之后未执行flush logs使参数生效。
- **运维建议：** 完善变更步骤，在变更步骤中确保flush logs被执行。
## 第 6 期｜Mysql 性能全面下降，业务访问超时无响应
- 专辑文件：`36.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247547362&idx=1&sn=e81f89caa975c5168690b4aaa64a34e3&chksm=f8214034dc2cdac26f9fcee01a8c4389ddf22c0fdb982fb6b71d6397e4bb9a3a3d2fba160f78#rd)
- **现象：** mysql sql性能全面下降，业务访问超时无响应。
- **处置过程：** 优先检查主机内存、cpu、io；发现故障时间io写入降为零。；检查sql，发现业务那个时段业务在跑批量更新数据。；观察实时io发现，数据频繁的读写一块盘，且该块盘的最大iO才3M-5M之间；后通过主机检查发现该业务进行了多次少量扩容，底层挂了12块盘，从最开始的50G扩容到400G，最大的一块盘150G。
- **运维建议：** 多次扩容的虚拟机需要进行单盘io评估。
## 第 4 期｜MYSQL单表损坏恢复
- 专辑文件：`38.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545681&idx=1&sn=8aeb394823bc8a6be300364dc7faa8a6&chksm=f833e66cee5e5c651ecb8df3eab3acb1292e41d478c62576c0782b1789dd0cb51b78935f5a87#rd)
- **现象：** mysql单表损坏，导致业务受阻。
- **排查与原因：** 判断为os层文件损坏,通过mos进一步确认为文件损坏；；通过设置innodb_force_recovery尝试恢复,从value 1--6仍然无法恢复,和业务沟通先drop故障表,恢复其他业务；；使用备份+binlog异机恢复故障表,业务确认数据后导出并导入生产库。
- **处置过程：** mysql不断crash重启,日志提示访问表的page错误；Trying to access page number 1212435777；space 27, space
- **运维建议：** 一定要做备份；；必须做定期恢复演练。
## 第 4 期｜MYSQL主从同步延迟处置
- 专辑文件：`38.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545681&idx=1&sn=8aeb394823bc8a6be300364dc7faa8a6&chksm=f833e66cee5e5c651ecb8df3eab3acb1292e41d478c62576c0782b1789dd0cb51b78935f5a87#rd)
- **现象：** Mysql主从同步延迟。
- **处置过程：** 监控短信告知mysql主从复制的延迟时间。；登录数据库查看从库的SLAVE日志(SHOW SLAVE STATUS),发现当前延迟（Seconds_Behind_Master:3500）较大。；SHOW PROCESSLIST未发现事务锁，且当前活跃连接数大概10几个（4核的CPU），某几条delete、update执行时间过长。
- **运维建议：** 调整数据库服务器的磁盘IO监控告警阈值。；配置合适的延迟监控项告警阈值。；对参数进行调整innodb_flush_log_at_trx_commit=2 sync_binlog=0
## 第 3 期｜MYSQL从库的延迟告警处置
- 专辑文件：`39.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545071&idx=1&sn=aac931fa16e31d4a7cab4b63ed930cf2&chksm=f8b74916863b9b6abd37c1a3aa35465d11acaacf942e0030e03a53422fdb3ad465b87d821d9e#rd)
- **现象：** mysql从库的延迟告警，并且延迟越来越大。
- **处置过程：** 查看延迟的从库，并没有发现有大事务正在执行，这里排除大事务导致的复制延迟；；没有发现metadata lock排除对表DDL导致的复制延迟；；查看线程具体等待情况，有等待提交的 、有等待MTS顺序提交，等待提交锁要主要是由一条flush table with read lock导致的；
- **运维建议：** 避免在从库执行 flush table with read lock语句。；slave_preserve_commit_order=0 关闭从库 binlog 的顺序提交，避免这个死锁的出现。；从库监控flush table with read lock语句。
## 第 3 期｜MYSQL主从同步异常处置
- 专辑文件：`39.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545071&idx=1&sn=aac931fa16e31d4a7cab4b63ed930cf2&chksm=f8b74916863b9b6abd37c1a3aa35465d11acaacf942e0030e03a53422fdb3ad465b87d821d9e#rd)
- **现象：** Mysql主从同步异常。
- **处置过程：** 主从同步异常，从库执行inster语句失败，使用mysqlbinlog命令查询报错时间点的sql语句，根据此sql删除从库重复数据。；查看从库bin-log日志发现故障前从库有做inster操作。；查看从库read_only配置，发现从库未开启read_only。
- **运维建议：** 应用用户不允许有super权限，加强权限管控。；增加从库read_only参数检查。
## 第 2 期｜mysql频繁崩溃重启，导致业务中断
- 专辑文件：`40.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247543426&idx=1&sn=287cc6eaa6e98153ec19c45ea5989f33&chksm=f8170fa7cd7203246038852d2d0dab5a1d82b83c11b76b2ba4dd0275f67a6a1d255f198ce891#rd)
- **现象：** mysql频繁崩溃重启，导致业务中断。
- **处置过程：** 排查mysql日志，出现了got 11 error的错误，这是由于bug or 机器硬件导致的。；检查操作系统日志，并未发现硬件的错误。；检查mysql日志，发现mysql使用了8.0.29的版本，此版本由于出现重大bug，开源社区已回收此版本，需升级到8.0.30.在升级过程中，由于mysql频繁重启，导致实例崩溃恢复无法完成，故升级无法进行。需将原备份导入到新实例中，问题解决。
- **运维建议：** 及时关注官网信息，定期对数据库进行升级；。检查所有生产环境是否存在8.0.29版本数据库，如果存在，需要及时升级到最新版本。
## 第 2 期｜MySQL数据库被业务误删除
- 专辑文件：`40.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247543426&idx=1&sn=287cc6eaa6e98153ec19c45ea5989f33&chksm=f8170fa7cd7203246038852d2d0dab5a1d82b83c11b76b2ba4dd0275f67a6a1d255f198ce891#rd)
- **现象：** MySQL数据库被业务误删除导致部分业务停止。
- **处置过程：** 从库io异常导致复制停止。；从库导出误删数据库，进行恢复至主库。；解析binlog恢复增量数据。
- **运维建议：** 对业务账号权限进行规划管控，按照权限最小化原则进行赋权，防止赋权过大。；对业务操作变更操作进行管理，防范未经评审变更。；所有数据库都要进行备份，