目录
1、 Binlog详解，包括记录格式、内容解析、清除、落盘分析
4、慢查询日志中，Rows sent和Rows examined有什么区别
10、MySQL是怎样判断哪些Undo Log是可以Purge的?
11、Binlog和Redo Log有什么区别?Undo Log和Redo Log有什么区别?
1、 Binlog详解，包括记录格式、内容解析、清除、落盘分析
定义与概念 Binlog（二进制日志）是 MySQL 数据库的一种日志文件，它记录了数据库中所有的更改操作（如插入、删除、更新），以二进制的形式存储。主要用于数据恢复、主从复制等场景。
记录格式
STATEMENT 格式：
记录的是执行的 SQL 语句本身。例如，当执行INSERT INTO table_name (column1, column2) VALUES ('value1', 'value2');操作时，Binlog 中会记录这条完整的 SQL 语句。这种格式的优点是日志文件比较紧凑，占用空间相对较小。但是，在某些情况下可能会出现问题，比如如果 SQL 语句中包含了依赖数据库状态（如使用了用户自定义函数或存储过程中的非确定性操作）的内容，在从库重放这些语句时可能会导致数据不一致。
ROW 格式：
记录的是每一行数据的实际更改情况。对于插入操作，会记录插入的每一行数据的具体值；对于删除操作，记录被删除行的主键等信息；对于更新操作，记录更新前后行的具体内容。这种格式的优点是能够更精确地进行主从复制，确保数据的一致性，即使在复杂的操作环境下也能很好地工作。但缺点是日志文件可能会比较大，因为它详细记录了每一行的变化。
MIXED 格式：
这是一种混合格式，MySQL 会根据操作的类型自动选择是使用 STATEMENT 格式还是 ROW 格式进行记录。一般情况下，对于简单的、确定性的 SQL 语句（如简单的插入、更新、删除操作）使用 STATEMENT 格式记录；对于复杂的操作（如使用了存储过程、包含不确定函数的操作等）则使用 ROW 格式记录。这种格式结合了前两种格式的优点，在保证数据一致性的同时，尽量减小日志文件的大小。
内容解析
工具使用：
可以使用mysqlbinlog工具来解析 Binlog 文件的内容。
show master status\G --查看位点
mysqlbinlog --start-position=155 mysql-bin.xxx -vv >/data/01.sql
实际解析示例：
假设 Binlog 中记录了一个更新操作，以 ROW 格式记录。在使用mysqlbinlog工具解析时，可能会看到类似如下内容（简化示例）：
plaintext
复制
### UPDATE `test_table`
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### SET
### @2='new_value' /* VARCHAR(255) meta=255 nullable=1 is_null=0 */
这里表示在test_table表中，对主键（@1对应的列，这里假设是主键）值为 1 的行进行了更新，将某个列（@2对应的列，这里假设是一个 VARCHAR 类型的列）的值更新为new_value。
清除 Binlog 文件
自动清除设置：
可以通过设置expire_logs_days参数来控制 Binlog 文件的自动清除。这个参数在 MySQL 配置文件（如my.cnf或my.ini）中的[mysqld]部分设置。例如，设置expire_logs_days = 7，表示 Binlog 文件会在生成 7 天后自动清除。这种自动清除机制可以防止 Binlog 文件占用过多的磁盘空间。
手动清除方法：
可以使用PURGE BINARY LOGS语句来手动清除 Binlog 文件。例如，PURGE BINARY LOGS TO 'binlog - file - name';命令会清除指定 Binlog 文件之前（包括该文件）的所有 Binlog 文件。或者使用PURGE BINARY LOGS BEFORE 'date - time';命令来清除指定日期时间之前的 Binlog 文件。不过在手动清除时要谨慎，确保不会误删除需要用于数据恢复或主从复制的重要 Binlog 文件。
落盘分析
写入机制：
Binlog 是在事务提交阶段写入磁盘的。当一个事务成功提交时，MySQL 会将该事务对应的 Binlog 记录写入磁盘。这是为了保证数据更改操作和日志记录的顺序一致性，以及在系统崩溃等情况下能够通过 Binlog 进行数据恢复。
同步方式：
可以通过设置sync_binlog参数来控制 Binlog 写入磁盘的同步方式。当sync_binlog = 0时，MySQL 不进行 Binlog 的强制同步，而是依赖操作系统的缓存机制来将 Binlog 写入磁盘，这种方式性能较好，但在系统崩溃时可能会丢失部分 Binlog 记录。当sync_binlog = 1时，MySQL 会在每次事务提交时强制将 Binlog 写入磁盘，这种方式数据安全性高，但性能相对较低。一般在对数据安全性要求较高的场景下，建议设置sync_binlog = 1。
开启binlog
log-bin = /data/mysql/binlog/mysql-bin
查看binlog是否开启
show variables like '%log_bin%';
如果要关闭，可在配置文件中加
skip_log_bin
关闭当前会话
set sql_log_bin=0;
设置文件大小，可在配置文件重加入
max-binlog-size=512M
解析binlog详细步骤
首先执行create语句 show master status\G create table haohao.binlog_test(id int); insert into haohao.binlog_test select 1; show master status\G 切到binlog所在路径 cd /data/mysql/binlog/ 基于位点解析 mysqlbinlog --start-position=155 mysql-bin.xxx -vv >/data/01.sql 基于时间解析 mysqlbinlog --start-datetime="2022-01-01 00:00:00" mysql-bin.000001 > 02.sql 基于gtid解析 mysqlbinlog --include-gtids 'ec992f67-a08b-11ed-9a9f-024255bd70b6:10279' mysql-bin.000007 -vv > /data/03.sql 在两个库里执行create语句 show master status\G use haohao create table binlog_test_01(id int); use test create table aaa(id int); show master status\G 解析单库binlog mysqlbinlog --start-position=2568 --stop-position=2966 -d haohao mysql-bin.000007 -vv > /data/04.sql 在配置文件中【mysqld】中加入如下语句开启binlog加密： early-plugin-load = keyring_file.so keyring_file_data = /data/mysql/keyring binlog_encryption = on 重启之后在查看binlog列表 show binary logs; 再创建一张测试表，以用于产生新的binlog内容： show master status\G create table haohao.binlog_test_02(id int); show master status\G 尝试mysqlbinlog解析最新的binlog，具体如下： mysqlbinlog --read-from-remote-server -uroot -pxxx --start-position=155 mysql-bin.xxx -vv >/data/05.sql --read-from-remote-server 参数表示从MySQL服务器读取binlog，而不是读取本地日志文件。
对不用的binlog进行清除
动态调整binlog保留时间 set global binlog_expire_logs_seconds = 1296000; 或：SHOW VARIABLES LIKE 'expire_logs_days'; 然后执行： flush logs; 删除指定binlog之前的文件： show binary logs; purge binary logs to 'mysql-bin.000002'; show binary logs; 在查看binlog文件，确认是否删除 ll /data/mysql/binlog/ 删除指定日志之前的binlog文件： purge binary logs before '2025-02-02 00:00:00'; 查看binlog文件： ll /data/mysql/binlog/
GTID解析
GTID（Global Transaction ID）定义 GTID 是 MySQL 5.6 版本引入的一种全局事务标识符。它是一个唯一的标识符，用于在复制环境（主从复制）中标记事务，并且在整个复制拓扑结构中全局唯一。这意味着无论在主库还是从库，每个事务都可以通过 GTID 进行唯一标识。 GTID 的工作原理 在主库上： 当一个事务在主库上提交时，MySQL 会为这个事务分配一个 GTID。这个 GTID 会被记录在主库的二进制日志（binlog）中。 主库的 binlog 会将包含 GTID 的事务事件发送到从库，用于从库的复制操作。 在从库上： 从库在接收到主库发送的包含 GTID 的事务事件后，会首先检查自己的 GTID 集合（gtid_executed）。如果该 GTID 对应的事务尚未在从库执行，从库就会应用这个事务，从而实现与主库的数据同步。 从库会维护一个已经执行的 GTID 集合，用于避免重复执行事务。例如，如果由于网络问题导致某个事务事件被重复发送，从库可以通过检查已经执行的 GTID 集合来识别并忽略这个重复的事务。 GTID 的优势 简化复制配置和故障恢复： 在传统的基于二进制日志文件位置和偏移量的复制方式中，配置主从复制比较复杂，并且在故障恢复时，需要精确地指定从哪个位置开始恢复复制。而使用 GTID，复制配置变得更加简单，只需要指定主库的 GTID 信息，从库就可以自动识别并应用未执行的事务。例如，在主库发生故障后，将新的主库连接到从库时，从库可以很容易地根据 GTID 确定哪些事务已经执行，哪些事务需要从新主库获取并执行，从而实现快速的故障恢复。 减少了因位置和偏移量错误导致的复制问题。在复杂的复制拓扑结构中，使用 GTID 可以降低复制出错的概率，因为 GTID 提供了一种更直观、更全局的事务标识方式。 兼容性问题： GTID 是从 MySQL 5.6 版本开始引入的，较旧版本的 MySQL 不支持 GTID。如果你的数据库环境中存在不同版本的 MySQL，并且需要进行复制操作，需要注意版本兼容性。例如，在将一个基于旧版本 MySQL（如 5.5）的从库升级到支持 GTID 的版本时，需要谨慎地进行配置和数据迁移，以确保复制功能的正常运行。 性能影响： 在某些情况下，GTID 的使用可能会对数据库性能产生一定的影响。由于需要维护和管理 GTID 相关的信息（如 gtid_executed 集合），可能会增加数据库的存储开销和处理事务的时间。不过，在大多数实际应用场景中，这种性能影响相对较小，但在对性能要求极高的场景下，需要对 GTID 的使用进行性能测试和评估。 事务顺序和冲突： 在多主复制或复杂的复制拓扑结构中，需要注意事务的顺序和可能出现的冲突。虽然 GTID 可以标识事务，但如果不同主库上的事务存在逻辑冲突（如对同一行数据进行冲突的修改），仍然可能导致数据不一致。因此，在设计复制拓扑结构和应用程序时，需要考虑如何处理这种潜在的事务冲突。
2、 General Log介绍及使用
-
General Log（通用日志）是 MySQL 数据库用于记录所有客户端连接和执行的 SQL 语句的日志。它可以详细记录数据库中发生的各种操作，包括查询、插入、更新、删除以及连接建立和断开等信息，就像是数据库活动的一个详细记录账本。
会话级开启
show global variables like "general%"; set global general_log = on;
永久生效，编辑配置文件【mysqld】中补充如下
general_log = on general_log_file = /data/mysql/log/mysql-general.log
查看general log的输出方式
show global variables like "log_output";
查看general log 文件
tail /data/mysql/log/mysql-general.log
诊断问题、比如慢查询或死锁，通过分析general log找到产生问题的时间点，并根据日志的详细信息跟进排查。
也可用于分析工具原理，例如pt-online、mysqldmp在执行过程中会执行哪些命令。
安全审计：追踪哪些用户在什么时候执行了什么操作。
缺点：
性能开销，只要开启就会增加服务器负载，尤其是在高并发环境
日志文件过大
安全性问题
3、 Slow Log的开启及查看
动态开启
set global slow_query_log = 1; set global slow_query_log_file="/data/mysql/log/mysql-slow.log" set global long_query_time = 1;
如果需要MySQL重启也生效，则在MySQL的配置文件的【mysqld】中补充如下内容：
slow_query_log = 1 slow_query_log_file = /data/mysql/log/mysql-slow.log long_query_time &标签：binlog,log,04,Binlog,DBA,MySQL,mysql,日志,GTID From： https://blog.csdn.net/Timebro/article/details/144988865