在mysql中，explain是SQL优化的重要工具，它可以查看表的加载顺序、表连接关系、索引使用情况以及SQL处理方式等。表示查询的一个序列号，用来表示查询中执行select子句或操作表的顺序。单表查询、join连接中，id值都是1且从上到下执行，第一行为驱动表。

先看一个生产案例数据库error.log出现下面报错，实例启动失败。2025-02-15T23:05:53.254309+08:00 4 [ERROR] [MY-012592] [InnoDB] Op

在mgr数据库执行reset slave all报错：mysql> reset slave all; ERROR 3139 (HY000): RESET SLAVE ALL FOR CHANNEL c

在mysql 8.0中，下面参数控制过期binlog自动清理。检查日志文件，binlog超过5天的日志并未清理，数据库启动以来的所有日志都在。查看binlog截断时间，每天晚上的binlog切换时间几乎一致。下面是2025.1.8的备份完成时间，与上面binlog切换时间吻合。对比别人提交的bug，问题描述基本一致。可见，当max_binlog_size设置较大，而每天生产的binlog日志量较小时，就无法进行自然切换。然而备份切换的时候由于加锁了，不让删除binlog，所以导致binlog日志一直没有清理。合理调小max_binlog_size的值。

log_output参数可以指定慢日志的存储方式，可以设置为TABLE、FILE或者NONE。log_output='FILE' # 表示将日志存入文件slow.log，默认值是'FILE'　 log

今天分析的案例中，错误日志显示有索引损坏，然后mysql实例不定期重启。2024-11-04T10:15:35.076699+08:00 116 [ERROR] InnoDB: Database page corruption on disk or a failed file read of page [page id: space=1921, page number=35458]. You may have to recover from a backup.InnoDB: Page may be an index page where index id is 2949. 从日志找到这几个关键词，下文定位问题时会用到。

change replication filter过滤配置无法持久化，重启实例失效；在mysql5.7版本中，change replication filter过滤影响mgr集群内部同步。

在数据库查询中，left join是外联接的一种，用于结合两个或多个表的联接类型，它返回左表中的所有记录，同时携带右表中匹配的记录，未匹配的行显示为null。外联接分为左外联接（left join）、

1、数据冗余，通过复制技术可以构建多副本，避免主机故障实现数据高可靠；2、集群构建，官方退出的innodb cluster中，各节点通过主从复制技术实现同步；其实binlog复制的设计初衷是，作者想实现一款轻量级的可插拔的数据库，server层记录操作日志（binlog），通过binlog复制实现多副本，而引擎层可以自由切换。但是随着MySQL不断演进，用户对并发粒度、数据安全等的要求越来越多，如

在某些复杂sql语句，或者数据分布不均衡的table中，默认的执行计划可能不是最佳方案，此时我们可以通过控制优化器策略引导执行计划发生改变。某生产库中的sql执行效率非常低，查看执行计划发现驱动表扫描行数很多且不走索引。改写SQL后执行计划依然发生了改变，然后使用优化器提示，禁止条件下推的方法固定执行计划。mysql优化器程序通过optimizer_switch系统变量控制。在不同版本中，优化器选项的值可能有所不同，所以在数据库版本升级后，可能会引发sql执行计划变化，影响到sql执行效率。修改变量后，所有后续查询操作会立刻受到影响。

日常运维中，innodb_trx视图中经常会出现running时间很长的事务，但是并没有显示sql语句，很多DBA对这类问题很困惑。比如上图中，show processlist 查看到ID对应的session一直存在，status状态时而running时而 sleep，最后分析发现，应用程序使用 begin、start transction 启动了一个大事务，不停的轮询更新数据，大事务运行时间超过 1 天。一般情况下，应用程序通过begin执行显示事务后，事务中的sql已经执行，但是该显示事务一直没有提交时就会出现这种现象。下面sql语句会查询到“空事务”中执行的上一条sql语句，拿到sql后找开发一起排查sql来源，最后尝试复现找到根因。下面案例就是“空事务”引发的锁阻塞。517487888应该为delete或者update语句，在操作主键为64404684的行记录时，加了X锁，但是

巡检报告主要包含以下内容，大家也可以根据实际需求进行增减。这部分内容是对整个巡检报告的总结，让用户从整体上了解数据库运行情况。由于我们需要远程批量巡检多套数据库，所以下图的cpu信息、内存信息、磁盘使用率信息均通过监控平台api接口获取。如果大家觉得这种方式获取数据麻烦，也可以在本地执行shell命令获取，代码就会简单很多。

应用服务连接数据库后，mysql的最大连接数自动变为214，mysql出现Too many connections的错误。配置参数中，max_connections=3000，数据库启动后连接数也显示3000。开启general log后发现错误，受限于max_open_files，数据库修改了max_connections和table_open_cache的值。执行ulimit -a查看，果不其然，open files显示为1024。升级openssh后，centos修改限制参数不生效了。这是因为limits.conf是由PAM模块pam_limits.so来加载，通过ssh访问会调用sshd PAM。如上分析，本次数据库故障是操作系统引发，建议回退openssh版本，或者修改UsePAM yes。

把IPv6改造中的一下经验和成果分享出来，欢迎大家借鉴交流

接到一起数据库故障，用户反馈主机cpu频繁告警，操作系统只安装了数据库，查看mysql后没有发现error日志，pt-query-digest分析最近1一个月的slow log，没有找到慢SQL。查看cpu耗时长的函数，都属于常规的大接口，除了软中断引发关注外，没发现其他异常函数调用。但是从这里可以看出，cpu资源几乎都被mysql服务使用了，且数据库负载较大。这里再次印证了数据库高负载。如下图，数据库查询非常大，reads/s每秒查询达到了280万行，这已是普通虚拟机的极限了。inserts/s、updates/s、deletes/s表示数据库TPS。一般好点的机器，TPS可以跑到4000多。数据库除了负载较高，并无其他异常，所以排查重点应该放在sql查询。实例中正在运行的慢sql数超过cpu核数时，cpu负载就会很高。使用pt-query-digest解析慢sql，代码段中耗时最长的sql，占用慢sql总耗时的27%，远远高于其他sql。当耗时短的sql执行频率很高时，也可能造成数据库负载。另外建议开发归档了部分历史数据，进一步提升了查询效率。优化后，数据库并发线程数降低到10个左右，

最近遇到一起大量opening tables导致数据库hang起的生产事故，借此机会总结一下。故障发生后查看show processlist，发现大量线程处于opening tables状态，大多数语句无法正常执行，甚至kill语句也会卡住。此时，如果短时间无法找到原因，最有效的解决方法是立刻重启实例，如果条件容许，建议打几个pstack，然后事后分析。当Open_tables值大于table_open_cache值，且新的连接无法命中table cache时，就需要再次打开并缓存表定义，此时就会有大量的线程处于opening tables状态。所以，当数据库负载较大时在大表执行了truncate操作，AHI维护耗时就会很长，导致其他用户线程无法获取字典锁而处于Opening tables状态。即在一个事务里修改字典数据，成功后再删除rename的临时表。查看数据库中AHI的命中率，如果命中率较低，可以考虑关闭AHI功能。

从mysql 5.7.28版本开始，安装数据库将默认开启ssl。关闭ssl后，如果想重新开启ssl，只需要在配置文件指定ssl_ca、ssl_cert和ssl_key对应文件的路径，这3个参数对应的密钥文件默认在数据目录下。

是系统后台守护进程，表示放后台运行的意思。全称应该是--daemonize[={OFF|ON}，默认ON。

执行show slave status;查看复制信息，这里可以查看到自己是谁的主库。 

学习了

GreatSQL开源数据库是适用于金融级应用的国内自主MySQL版本，专注于提升MGR可靠性及性能，支持InnoDB并行查询等特性，可以作为MySQL或Percona Server的可选替换，用于线上生产环境，且完全免费并兼容MySQL或Percona Server。GreatSQL除了提升MGR性能及可靠性，还引入InnoDB事务锁优化及并行查询优化等特性，以及众多BUG修复。

收录国产数据库文章

可能的原因是该文件的权限不正确或者所在的磁盘已满。Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.其中，mysql:mysql是指将文件的拥有者和所属组都设置为mysql用户。你可以使用如下命令查看磁盘使用情况：。找到磁盘使用率较高的目录，并清理一些不必要的文件。完成以上步骤后，你可以尝试再次修改密码。

在使用mgr的过程中，我们会经常看到以下报错，大概意思是：“由于网络故障，成员被逐出mgr集群，并将该成员状态更改为ERROR”。这因为mgr集群节点间心跳检测超时，少数派节点被驱逐导致的。2022-07-31T13:07:37.458761-00:00 0 [ERROR] [MY-011505] [Repl] Plugin group_replication reported: 'Member was expelled from the group due to network failures, changing member status to ERROR.'. 下面结合一个具体的案例，分析 Group Replication 的故障检测流程。恢复网络连接，看看各节点又是如何反应的。通过iptables 命令断开 node3 与 node1、node2 之间的网络连接。显示 node3 处于 UNREACHABLE 状态。

不能删除，否则主从中断，主从数据不一致了。

都可以，这个没有任何影响。

选择USE INDEX (emp_job2)，因为首先忽略掉IGNORE INDEX (emp_job)了。