搞垮线上库就一秒，救火全靠日志牢不牢靠。
MySQL三大日志binlog、redo log、undo log就是数据库的后悔药，吃错顺序直接送你数据火葬场。
binlog记的是“操作命令”，像归档病历。
主从复制和数据恢复全靠它，但默认的ROW格式能把你硬盘塞爆，一条update改十万行？
日志直接飙十万条！
切回STATEMENT省空间？
小心now这种函数在主从不一致，分分钟复制翻车。
redo log才是真·救命稻草，物理记录数据页变更。
写内存前先写redo，崩溃重启就靠它追进度条。
但别以为写盘就安全——它先落缓冲区，攒够一波才刷盘。
这时候断电？
自求多福吧。
最阴险的是undo log。
回滚靠它存旧版本，MVCC读视图也靠它。
你以为删数据就干净了？
undo链里全给你留着。
长事务不杀？
undo暴涨撑爆表空间不是玩笑。
核心坑点在这：redo log和binlog得用两阶段提交绑死。
先写redo log prepare再写binlog，最后redo commit。
三步少一步？
要么丢数据要么主从不一致。
大促时DBA手抖把
innodb_flush_log_at_trx_commit设成0？
等着收离职大礼包吧。
日志配错等于埋雷。
binlog过期设七天？
误删数据想回滚？
发现最后备份是五天前的，直接裂开。
主从开MIXED格式以为高枕无忧？
遇到UUID函数照样翻车。
没事别瞎jb重启。
MySQL崩溃恢复要扫描redo log重演，undo log清理回滚段。
日志文件要是设成100M100组？
恭喜获得十分钟业务瘫痪大礼包。
重启不是重启键，按下去就真完蛋。