数据库大事务操作影响很严重, ORACLE 这里好像也不挺严重的,因为它是物理备库, 物理就是  数据文件 某个区被修改了,直接传输给备库,这个区域一般就是8K大小.

而MYSQL 是逻辑备库, 传递的是 SQL语句, 虽然 BINLOG 改成了ROW模式,其实也是SQL语句,不过原本一条 比如说DELETE FROM ORDER表 ;只传一条SQL语句到从库执行, ROW模式 是ORDER 表有多少行记录,就传多少条SQL过去, 大概像这样 DELETE FROM ORDER WHERE ID=???;
并且那么多条语句打包成一个事务发到从库去执行!

其实也没有什么,顶多是慢了而已,只要系统稳定,最终都要执行完的.不过很多从库都要执行读写分离,需要承担业务读的功能,必然一定程度影响了业务.

大事务在MYSQL上最可怕的是 膨胀和回滚操作!

从本图可知,它会导致 UNDO LOG 的膨胀,ORACLE它也无法避免,UNDO LOG 也会膨胀 达到32GB; 不过如果你限制了UNDO 表空间大小,大事务可能没有UNDO可用空间分配而报错, 一报错就跳到回滚操作,又是个超长时间的回滚! 我想MYSQL 的UNDO LOG 膨胀到最大值 也会阻塞其它事务的进行,因为无法获得 UNDOLOG 空间.

ORACLE 的 REDO LOG 文件 可以进行归档, MYSQL的REDO LOG 会循环被覆盖,其实这点也没啥,就是恢复,回滚的时候 MYSQL需要BINLOG的参与,BINLOG记录的才是完整的事务.且是提交的事务!

说到BINLOG MYSQL的每个线程有个BINLOG CACHE 缓存 你可以把它看成LOG BUF. 如果写满了BINLOG CAHCE ,那么CACHE会写进磁盘, 隐藏的临时文件.

所以大事务会膨胀UNDO LOG和 BINLOG ;膨胀最大值就涉及LINUX系统文件大小限制,磁盘空间限制!

如果失败需要恢复和回滚操作

大事务问题多多,最终如何防止大事务呢? 很遗憾是没有什么办法的

OB  数据库设计的是 REDO LOG 只 保存 已提交的事务日志, 这样就可以 减少REDO LOG写. 恢复的时候也不需要做回滚操作,只要重新做一边事务 !

那么只是在恢复的情况下,大事务就影响不到了! 因为不需要回滚大事务的脏数据,实例恢复速度就快!

必然就要学BINLOG CACHE  BINLOG TMP方式 搞个REDO CACHE REDO TMP 每个事务!

这样也好 如果系统不崩溃,磁盘空间足够,不过整体来说解决50%问题.

其实本来MYSQL应该提供一个参数 限制每个事务的修改行数 

TRX_ROWS_LIMIT=10000;

现实MYSQL是没有这个参数的,那么我们只能开启安全更新参数,

安全更新参数部分解决问题, 安全更新参数要求 要么有索引,要么有ID,要么有LIMIT. 

另外 我们可以在SQL审核的时候设置这个规范,且可以借助审核工具实现,

SQLE 可以审核MAP文件.

如果是JAVA开发的,那么我们可以进行改写,最后在DML语句 添加LIMIT

自然 ORACLE 也有ROWNUM<=10000 

MYSQL 安全更新测试

DBA手写个JAVA拦截器改SQL

max_binlog_cache_size  这个是限制一个事务 里面的 binlog event 大小 https://www.bookstack.cn/read/aliyun-rds-core/45223a06c6f7b951.md

比如  max_binlog_cache_size 设置 512M ， 一个大事务持续写入 binlog cache 中，放不下就临时文件，如果最终大于512M ,就报错了，这个事务就是回滚了，算是取巧，不是很准确也要结合业务能不能容忍报错，可以在准生产设置小点，业务报错直接就拆了大事务，

这个逻辑是对的，但是这个是控制磁盘文件大小的，不是控制event大小的吧，一个个event不断生成，不断写入binlog临时磁盘文件，超过max_binlog_cache_size就报错。这个参数也可以限制事务大小