innodb中，truncate table与drop table操作分析

一、现象：

此问题是源于今天早上如龙发在群里面的一个讨论，

当时的场景是一个truncate table操作执行了很长的时间，大家在分析为什么

当时我对执行慢不太奇怪，奇怪的是，后来说分析log中发现truncate table操作中是Delete rows操作。

 

二、疑问：

说truncate table操作是Delete row,这个我没法理解了。

 

按照通常的理解，Drop table 和truncate table都应该属DDL操作,

而truncate table应该是drop 后再create 一个新的table,

其执行速度也应该是差不多的，这样符合常理，实现也优雅

 

三、实际情况：

但是通过跟代码，发现在innodb 引擎下，truncate table 确实是以delete row by row的方式进行truncate table 操作，只不过这个delete操作有优化的

为什么innodb会以这么笨重的方式来进行truncate table 操作？

代码中的说明这么做的原因是：

Row-by-row truncation if the engine does not support table recreation.

对这个说明我刚开始没看明白，开始以为Innodb引擎的结构上面是不是有什么限制，所以才不支持table recreation, 后来查看了drop table的执行过程，

最后，我认为，这么做的原因是因为 。。。。。。。mysql开发人员没有实现此功能，而不是innodb不支持 table recreation。

 

Truncate table 操作：

ha_innobase::delete_all_rows(void)

–> error = row_truncate_table_for_mysql(prebuilt->table, prebuilt->trx);

Drop table 操作：

ha_innobase::delete_table

–> error = row_drop_table_for_mysql(norm_name, trx,thd_sql_command(thd) == SQLCOM_DROP_DB);

 

四、得到的推论

对于innodb :

truncate table速度 <  drop table 速度

truncate 实际实现上类DML,但被划为DDL;

truncate table 实现上不等同于drop table,但可以用drop table + recreate table 进行替代而优化速度；

mysql开发人员的开发进度真的很慢。。。很慢。。。很慢。。。。