必须了解的MySQL三大日志：binlog、redo log和undo log

binlog：记录所有SQL操作，支持STATMENT、ROW、MIXED格式，用于复制和数据恢复，具有灵活的写入机制，安全性由sync_binlog控制。

redolog：记录数据页变化，减少随机IO，提高恢复速度。
这是通过 writepos 和检查点进行管理的。
刷新策略由innodb_flush_log_at_trx_commit控制。

Undolog：记录逻辑变化，支持回滚和MVCC，存储在系统表空间中，事务提交后逐渐清理。

这三者共同构成了MySQL的高可靠架构，binlog保证复制和恢复，redolog保证持久性，undolog保证原子性和并发控制。

mysql中哪种日志不能直接cat或more

上周朋友研究了MySQL日志文件，发现重做日志（redolog）是保证事务持久性的关键。
它记录事务执行后的状态，防止发生错误时丢失尚未写入磁盘的脏页。
重做日志在事务开始后就开始写入，而不是等到提交之后才开始写入，因为有一个8 M的缓冲区（Innodb_log_buffer）来临时存储这些日志。

2 02 3 年我了解到撤消日志（undolog）的作用是保证数据的原子性。
它存储事务发生之前数据的版本，用于回滚和MVCC。
undo在事务开始前生成，并插入到链表中，提交后清理。
清理线程决定是否应该清理。

二进制日志（binlog）主要用于复制和时间点恢复。
它记录了事务的SQL语句及其反向信息。
binlog是在事务提交时写入一次，这会导致大事务的提交速度变慢。

我的朋友还提到错误日志记录了mysqld的启动、停止和运行错误。
默认情况下，错误日志记录功能是关闭的，但可以通过编辑 my.cnf 文件或命令行参数来指定日志路径。

此外，通用查询日志（generallog）记录所有查询和命令，但默认是关闭的。
慢查询日志（slowquerylog）记录执行时间过长且不使用索引的查询语句。

这部分我不太清楚，不过朋友说，配置这些日志文件的时候要注意不要日志过多，以免影响系统性能。
您可以根据自己的需要进行配置。

MySQL的binlog格式有哪些类型_它们有什么区别和影响？

说实话，当我第一次弄清楚binlog的时候，我真的很困惑。
这些形式中的每一种都有优点和缺点。
归根结底，选择取决于具体的业务场景。
我会告诉你我遇到的陷阱和我看到的危险。
可能有点长，但这是事实。

SBL，说实话，看一个老陶的视频评论就够了，提到了执行的SQL语句的原文。
我之前在测试环境中尝试过，只是使用 SET status=1 WHERE id=1 00; 进行简单的 UPDATE，只是 binlog 中的那条语句，非常短。
我当时就觉得这样挺好的。
毕竟，感觉就像阅读代码，而且很容易听。
结果呢？后来发现该系统正在执行计时功能。
主从库执行结果完全不同，数据分散。
这是SBL最大的失败。
对于随机 SQL 语句，例如 now() 和 UUID()，主服务器数据库的结果可能非常不同。
所以现在我一般不使用SBL，除非磁盘真的很紧迫，SQL任务绝对像硬件一样扎实——这种情况比较难遇到。

RBL有完全不同的想法。
它不告诉SQL，但它报告每次数据更改之前和之后的值，像拍照一样冷却更改。
我曾分享过金融系统升级，其中对数据一致性的要求是“毫米级”，RBL完美解决了我担心的所有问题。
恢复过程也非常简单，您可以在记录中准确找出错误所在。
该值是 PITR（时间点恢复）。
当然代价也不小。
当数据量较大时，binlog直接膨胀到数百MB，这对服务器的硬盘造成很大的压力。
为了运行RBL，我们在从库上放置了一块大硬盘，并调整了binlog压缩参数，否则运维直接崩溃。

MBL确实是一个折中的方案。
MySQL本身将决定SQL的安全性。
例如，如果执行简单的INSERT，SQL就会被记住；但当 NOW() 发生时，RBL 将切换为记录当前数据。
这种技巧模式，说实话，很烦人，而且在场景中效果最好。
我在小型业务系统上尝试使用MBL，运维说感觉还可以，没有什么大问题。
但有一个绊脚石，就是MySQL自身的判断逻辑无法完美。
例如，它可能无法识别某些函数调用组合，从而导致数据不一致。
探索这样的海岸会让人们发疯。

对于数据同步，SBL是基于重放SQL的。
想一想，如果问题是关于SQL本身的话，复制能配得上“同步”这个词吗？ RBL直接更改数据，就像流水线操作，出错的概率要低得多。
大多数时候，MBL 介于两者之间，但在大多数情况下您必须小心。
接收错误，SBL基本没问题，可以对接收到的数据进行插值； RBL是时间点回滚时的标准响应； MBL 介于两者之间，取决于恢复时的模式是 SBL 还是 RBL。

我建议将 RBL 作为生产环境的首选。
没有争论。
您可以在测试环境中尝试 MBL，但不要在生产环境中修改它。
SBL？除非你真的有能力让所有SQL稳定，否则不要碰它。
更改格式，应确认约定版本。
我看到MySQL 5 .x版本不支持RBL，数据库服务器直接崩溃。
必须确定复制中断的风险。
切换前最好停止写入并重建服务器数据库。
RBL必须要有资源消耗的心理准备，否则半夜运维加宝珠也不是梦。

总之，如果binlog格式选择不正确，复制延迟将会改善最坏的情况是数据丢失。
我见过大量的数据问题因为binlog格式而变得混乱，而且损失并不好玩。
因此，在选择时需要考虑业务场景。
不要只看优点，而要考虑如何应对最坏的情况。