是否可以在状态下回滚查询?将alter table提交到存储引擎'

时间:2018-03-06 13:28:24

标签: mysql mariadb innodb

我们有一个包含7000万行的InnoDB表,我们一直在尝试运行alter table语句来修改和添加几列。该查询似乎已经改变了表,现在处于将alter table提交给存储引擎的状态'。

START TRANSACTION;
ALTER TABLE table
  MODIFY COLUMN column1 int(11) NOT NULL DEFAULT 0,
  MODIFY COLUMN column2 tinyint(1) NOT NULL DEFAULT 1,
  ADD COLUMN column3 int(11),
  ADD COLUMN column4 int(11) NOT NULL DEFAULT 1,
  ADD COLUMN column5 varchar(255);
COMMIT;

这已经过夜了,现在是19小时。我们没有启用性能架构,因此无法查看估计的完成时间。我担心的是查询正在做什么以及查询是否会在被杀死时回滚。我已经看到其他问题涉及到复制到tmp表或等待表锁的查询。但是,当alter table提交时,我找不到任何关于被卡住的事情。

在此状态下终止查询是否安全,如果查询被终止,它是否会成功回滚?

服务器正在运行MariaDB 10.2

3 个答案:

答案 0 :(得分:3)

来自documentation

  

某些语句无法回滚。通常,这些语句包括数据定义语言(DDL)语句,例如创建或删除数据库的语句,创建,删除或更改表或存储例程的语句。

     

您应该将交易设计为不包含此类声明。如果您在无法回滚的事务的早期发出语句,然后另一个语句失败,则在这种情况下,通过发出ROLLBACK语句无法回滚事务的完整效果。

答案 1 :(得分:2)

我在MySQL 5.6中为InnoDB实现了ALGORITHM = INPLACE和LOCK = NONE。 根据以前的表定义,此操作可能意味着ALGORITHM = INPLACE,或者它可能会回退到ALGORITHM = COPY。 从MariaDB 10.3(MDEV-11369)开始,ADD COLUMN将是即时的;在此之前,必须重建该表。 (语法ALGORITHM = INPLACE非常容易引起误解。) 从MariaDB 10.2.13和10.3.5(MDEV-11415)开始,ALGORITHM = COPY将不再为各行写入撤消日志记录,并且回滚(如果客户端断开连接或被杀死的服务器)应该更快

答案 2 :(得分:1)

由于ALTER TABLE是DDL语句,it causes an implicit commit执行时。这意味着它无法回滚但是中断DDL(通过终止连接)将导致已应用的更改以受控方式回滚。

鉴于您正在使用默认的ALTER TABLE操作(未定义ALGORITHM),取消它应该相对较快,因为所有必须做的事情,至少根据我的知识,是丢弃它表的新副本。