为什么数据库 DDL 不支持事务回滚?

一、为什么数据库DDL不支持事务回滚

一般数据库的实现，以Oracle为例，在执行DDL后会隐式提交。所以你看上去好像DDL不会回滚。其实你可以做个实验，在同一个事务里执行几条DML，再执行DDL，再回滚。你会发现DDL之前执行的DML也不会回滚，因为数据库已经帮你提交了。

当然你会问为什么这么实现，这是因为内存空间有限，DDL是修改数据字典，而且通常不会有长时间的DDL执行。数据库自动提交有助于控制数据字典的内存占用，把更多的空间留给DML。

Oracle为了实现DDL可以回滚的功能，且实现多版本读一致性，那么就必须在DDL发生后，将修改的表锁定,避免其他会话的访问造成不一致这会导致Oracle中出现锁升级的情况，并且严重的影响Oracle的并发性，而且会大大增加死锁产生的几率要知道，Oracle的锁机制和多版本读一致性使得Oracle的并发性在所有数据库产品中首屈一指。

显然为了实现DDL的回滚而损失最值得称道的并发性，Oracle认为得不偿失。  

延伸阅读：

二、SQL TRUNCATE TABLE清空表语句

SQL TRUNCATE TABLE 语句用来删除表中的所有记录，也即清空表，它类似于不带 WHERE 子句的 DELETE FROM 语句。

TRUNCATE TABLE 和 DROP TABLE

DROP TABLE 用来删除表，包括删除该表的数据、结构、索引、触发器、约束等所有信息。一旦使用 DROP TABLE 删除了表，则该表的所有信息都将丢失，该表再也无法使用了。如果您希望存储一些数据，就只能重新创建该表。
TRUNCATE TABLE 仅仅删除表的所有记录，表的结构、索引、触发器、约束等将被保留，后续仍然可以使用该表。

TRUNCATE TABLE 和 DELETE FROM

不带 WHERE 子句的 DELETE FROM 语句同样可以达到清空表的效果，但是 TRUNCATE TABLE 使用的系统资源和日志资源更少，因此比 DELETE FROM 更加快速。
DELETE FROM 语句每删除一行，都会在事务日志中为所删除的行记录一项。TRUNCATE TABLE 通过释放表中数据所用的数据页来删除数据，只会在事务日志中记录页的释放。
此外，TRUNCATE TABLE 还能重置具有自动递增（AUTO_INCREMENT）属性的字段，而 DELETE FROM 却不具备该功能。

总结