mysql 在row模式下truncate 与 delete 二进制日志记录的差异

二进行日志的格式为row

mysql> show variables like ‘binlog_format‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
1 row in set (0.00 sec)

在testdb库下执行

mysql> select * from t1;
+----+------+
| id | name |
+----+------+
|  1 | NULL |
|  2 | chen |
|  3 | li   |
+----+------+
3 rows in set (0.00 sec)

mysql> select * from t2;
+------+--------+
| id   | course |
+------+--------+
|    1 | NULL   |
|    2 | chen   |
|    3 | math   |
+------+--------+
3 rows in set (0.00 sec)

mysql> truncate table t1;

mysql> delete from t2;

执行命令:mysqlbinlog --no-defaults -vv good.000001:主要看红色加粗字体部分:

# at 2162
#160303 11:02:51 server id 4  end_log_pos 2248 CRC32 0x3544cc1f     Query    thread_id=2755623    exec_time=0    error_code=0
SET TIMESTAMP=1456974171/*!*/;
truncate table t1
/*!*/;
# at 2248
#160303 11:05:40 server id 4  end_log_pos 2322 CRC32 0xf5126972     Query    thread_id=2756326    exec_time=0    error_code=0
SET TIMESTAMP=1456974340/*!*/;
BEGIN
/*!*/;
# at 2322
#160303 11:05:40 server id 4  end_log_pos 2372 CRC32 0xba9c0edd     Table_map: `testdb`.`t2` mapped to number 12204
# at 2372
#160303 11:05:40 server id 4  end_log_pos 2432 CRC32 0xd1433d85     Delete_rows: table id 12204 flags: STMT_END_F

BINLOG ‘
BKrXVhMEAAAAMgAAAEQJAAAAAKwvAAAAAAEABnRlc3RkYgACdDIAAgMPAhQAA90OnLo=
BKrXViAEAAAAPAAAAIAJAAAAAKwvAAAAAAEAAgAC//4BAAAA/AIAAAAEY2hlbvwDAAAABG1hdGiF
PUPR
‘/*!*/;
### DELETE FROM `testdb`.`t2`
### WHERE
###   @1=1 /* INT meta=0 nullable=1 is_null=0 */
###   @2=NULL /* INT meta=20 nullable=1 is_null=1 */
### DELETE FROM `testdb`.`t2`
### WHERE
###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
###   @2=‘chen‘ /* VARSTRING(20) meta=20 nullable=1 is_null=0 */
### DELETE FROM `testdb`.`t2`
### WHERE
###   @1=3 /* INT meta=0 nullable=1 is_null=0 */
###   @2=‘math‘ /* VARSTRING(20) meta=20 nullable=1 is_null=0 */
# at 2432
#160303 11:05:40 server id 4  end_log_pos 2463 CRC32 0x225aa989     Xid = 8390829
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET [email protected]_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
可以看到二者的不同,truncate直接是以一条语句复杂过来,而delete命令是直接把每条删除的语句一条条记录下来,所以假如要删除全表的数据,用truncate命令会比用delete命令少记录很多内容,日志内容会大减少,肯效率会更高

另外:delete与truncate还有以下的不同:1. truncatedelete只删除数据不删除表的结构(定义) 

2.delete语句是dml,这个操作会放到rollback segement中,事务提交之后才生效;如果有相应的trigger,执行的时候将被触发. truncateddl, 操作立即生效,原数据不放到rollback segment中,不能回滚. 操作不触发trigger. 

3.delete语句不影响表所占用的extent, 高水线(high watermark)保持原位置不动 显然drop语句将表所占用的空间全部释放 truncate 语句缺省情况下见空间释放到 minextents个 extent,除非使用reuse storage; truncate 会将高水线复位(回到最开始). 

4.速度,一般来说: truncate > delete 

5.安全性:小心使用drop 和truncate,尤其没有备份的时候.否则哭都来不及. 

使用上,想删除部分数据行用delete,注意带上where子句. 回滚段要足够大. 想保留表而将所有数据删除. 如果和事务无关,用truncate即可. 如果和事务有关,或者想触发trigger,还是用delete. 如果是整理表内部的碎片,可以用truncate跟上reuse stroage,再重新导入/插入数据/

Normal
0

7.8 磅
0
2

false
false
false

EN-US
ZH-CN
X-NONE

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:普通表格;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.5pt;
mso-bidi-font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;}

时间: 2024-12-16 21:20:28

mysql 在row模式下truncate 与 delete 二进制日志记录的差异的相关文章

MySQL 解密 --> 如何查看二进制日志ROW模式下最原始的SQL语句

MySQL的binlog的ROW模式解析          在mysql5.6以后,对主从数据一致性要求变高了,statement格式逐渐不太适合业务的需求了,所以生产环境大家都采用了row模式,row模式是传输最底层的数据变化的insert的模块来进行主从数据的传输,那么在binlog里面就和普通的statement模式有何差别?能否看到最原始的sql语句呢? 1.准备录入数据 mysql> create table test1(id int,c1 varchar(20),type int,a

MySQL备份方案-->(利用mysqldump以及binlog二进制日志)

From:http://blog.csdn.net/mchdba/article/details/11575605 随着数据不断增加,而且为了兼容以后的innodb存储引擎, 所以考虑采用mysqldump全备+日志增量备份的策略.使用mysqldump对于MySQL大部分mysql存储引擎比如myisam.innodb都有很好的支持. 方案一:mysqldump全备份+日志增量备份 1, mysqldump备份方案: 周一凌晨3点全备 周二到周日凌晨3点增量备份 2, 备份步骤 (1)    

binlog_format=ROW模式下mysql表无主键造成的从库延迟(卡住)

场景: MySQL-5.6.30, 主从架构, 只读从库的SQL线程卡在某一个事务两个多小时没有动过, show processlist发现从库当时没有连接和慢查询语句;show open TABLES where In_use >0; 发现一个表被锁定如下: mysql> show open TABLES where In_use >0; +----------+---------------+--------+-------------+ | Database | Table | I

部署tomcat在windows服务器下,将tomcat控制台日志记录到日志文件中

在Linux系统中,Tomcat 启动后默认将很多信息都写入到 catalina.out 文件中,我们可以通过tail  -f  catalina.out 来跟踪Tomcat 和相关应用运行的情况. 在windows下,我们使用startup.bat启动Tomcat以后,会发现catalina日志与Linux记录的内容有很大区别,大多信息只输出到屏幕而没有记录到catalina.out里面. 本文的内容就是要实现在windows下,将相关的控制台输出记录到后台的catalina.out文件中以便

mysql dba系统学习(6)二进制日志binlog之二

MySQL 5.5 中对于二进制日志 (binlog) 有 3 种不同的格式可选:Mixed,Statement,Row,默认格式是 Statement.总结一下这三种格式日志的优缺点. MySQL Replication 复制可以是基于一条语句 (Statement Level) ,也可以是基于一条记录 (Row Level),可以在 MySQL 的配置参数中设定这个复制级别,不同复制级别的设置会影响到 Master 端的 bin-log 日志格式. 1. Row日志中会记录成每一行数据被修改

mysql binlog_format row and Statement 比较

两种模式的对比: Statement 优点 历史悠久,技术成熟: 产生的 binlog 文件较小: binlog 中包含了所有数据库修改信息,可以据此来审核数据库的安全等情况: binlog 可以用于实时的还原,而不仅仅用于复制: 主从版本可以不一样,从服务器版本可以比主服务器版本高: Statement 缺点: 不是所有的 UPDATE 语句都能被复制,尤其是包含不确定操作的时候: 调用具有不确定因素的 UDF 时复制也可能出现问题: 运用以下函数的语句也不能被复制: * LOAD_FILE(

MySQL在Django框架下的基本操作(MySQL在Linux下配置)

[原]本文根据实际操作主要介绍了Django框架下MySQL的一些常用操作,核心内容如下: ------------------------------------------------------------------------------------------------- 1. Linux环境下MySQL的安装与配置 2. [Linux]MySQL在Django框架下的基本操作 3. 本文相关的一些参考网址 注:本文会根据实践,持续更新文档,如有错误,希望读者指出哈!~ -----

Azure ARM (12) ARM模式下,在负载均衡器上设置多个公网IP地址

<Windows Azure Platform 系列文章目录> 最近在帮助一个客户设置WAF (Web Application Firewall),WAF厂商要求在负载均衡器上,设置多个公网IP地址.架构如下图: 我研究了一下,在Azure ARM模式下可以实现,在这里记录一下. 在默认情况下,Azure负载均衡器可以有5个公网IP地址. https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits 如果我们想

sql server 备份与恢复系列三 简单恢复模式下的备份与还原

原文:sql server 备份与恢复系列三 简单恢复模式下的备份与还原 一.概述 前面讲了备份的一些理论知识,这篇开始讲在简单恢复模式下的备份与还原.在简单模式下是不能做日志备份的,发生灾难后,数据库最后一次备份之后做的数据修改将是全部丢失的,所以在生产环境下,数据又很重要,一般不建议使用这种模式. 例如对一个数据库有5次完整数据备份,时间是t5,  之后发生灾难,就会部丢失. 当数据库越来越大,完整备份时间会越来越长,为了减少丢失风险,引入差异备份.例如下图演示:在第一次建立数据库完整备份后