数据库大事务操作影响很严重, 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系统文件大小限制,磁盘空间限制!
如果失败需要恢复和回滚操作
从本图可知,它会导致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
