Mysql FlywayDB:迁移失败，出现“错误执行语句”，但手动运行迁移SQL代码有效

我有一个play framework 2.2.2 scala应用程序，使用play flyway 1.0.3

以下迁移应通过flyway运行：

ALTER TABLE  `user_visits` ADD  `FirstSiteRequestTime` DATETIME NOT NULL ;
UPDATE `user_visits` SET `FirstSiteRequestTime`=(SELECT `Time` FROM `user_siterequests` WHERE `user_siterequests`.`Visit`=`user_visits`.`ID` ORDER BY `Time` ASC LIMIT 1) ;

因此，我向表中添加一列，然后使用update语句以编程方式填充它

第一行执行良好，但updatestatemens失败

FlywaySqlScriptException: Error executing statement at line 2: UPDATE `user_visits` SET `FirstSiteRequestTime`=(SELECT `Time` FROM `user_siterequests` WHERE `user_siterequests`.`Visit`=`user_visits`.`ID` ORDER BY `Time` ASC LIMIT 1)
com.googlecode.flyway.core.command.FlywaySqlScriptException: Error executing statement at line 2: UPDATE `user_visits` SET `FirstSiteRequestTime`=(SELECT `Time` FROM `user_siterequests` WHERE `user_siterequests`.`Visit`=`user_visits`.`ID` ORDER BY `Time` ASC LIMIT 1)
com.googlecode.flyway.core.dbsupport.SqlScript.execute(SqlScript.java:92)
com.googlecode.flyway.core.resolver.sql.SqlMigrationExecutor.execute(SqlMigrationExecutor.java:72)
com.googlecode.flyway.core.command.DbMigrate$2.doInTransaction(DbMigrate.java:243)
com.googlecode.flyway.core.command.DbMigrate$2.doInTransaction(DbMigrate.java:241)
com.googlecode.flyway.core.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:72)

然而，当我使用迁移SQL代码并使用phpmyadmin运行它时，它工作得很好，尽管运行需要2-5秒，但表相当大

我的mysql.log看起来像

                  128 Query SET autocommit=0
                  128 Query ALTER TABLE  `user_visits` ADD  `FirstSiteRequestTime` DATETIME NOT NULL
140412  4:40:43   128 Query UPDATE `user_visits` SET `FirstSiteRequestTime`=(SELECT `Time` FROM `user_siterequests` WHERE `user_siterequests`.`Visit`=`user_visits`.`ID` ORDER BY `Time` ASC LIMIT 1)
140412  4:40:44   128 Query rollback
                  128 Query SET autocommit=1

flyway有什么暂停吗？日志文件显示它将查询发送到mysql服务器，但随后回滚。为什么？如前所述，查询是正确的。当我手动运行它时，它工作

编辑：

运行迁移后，执行ALTERTABLE语句并提交该表，尽管mysql.log说它已回滚。第二个命令真的被击退了

我还尝试在两次迁移中拆分这两个SQL命令。然后第一个ALTER TABLE运行正常，第二个失败

编辑2：

这可能是某种超时问题。通过只更新一些行来提高执行速度

ALTER TABLE  `user_visits` ADD  `FirstSiteRequestTime` DATETIME NOT NULL ;
UPDATE `user_visits` SET `FirstSiteRequestTime`=(SELECT `Time` FROM `user_siterequests` WHERE `user_siterequests`.`Visit`=`user_visits`.`ID` ORDER BY `Time` ASC LIMIT 1) WHERE user_visits.id<1000;

在flyway中也能正确运行。

说，从MySQL 5.5.3开始，大多数在执行前导致隐式提交的语句在执行后也会这样做。这似乎包括MySQL 5.5.3及更高版本中的ALTERTABLE语句

请注意，在问题中显示的日志中，autocommit是禁用的。可以肯定的是，在语句之间使用显式提交，如下所示：

ALTER TABLE  `user_visits` ADD  `FirstSiteRequestTime` DATETIME NOT NULL ;
COMMIT ;
UPDATE `user_visits` SET `FirstSiteRequestTime`=(SELECT `Time` FROM `user_siterequests` WHERE `user_siterequests`.`Visit`=`user_visits`.`ID` ORDER BY `Time` ASC LIMIT 1) ;

或者将它们放置在单独且连续的迁移文件中，如下所示：

ALTER TABLE  `user_visits` ADD  `FirstSiteRequestTime` DATETIME NOT NULL ;
COMMIT ;
UPDATE `user_visits` SET `FirstSiteRequestTime`=(SELECT `Time` FROM `user_siterequests` WHERE `user_siterequests`.`Visit`=`user_visits`.`ID` ORDER BY `Time` ASC LIMIT 1) ;

文件V1\uu alter\u table.sql：

ALTER TABLE  `user_visits` ADD  `FirstSiteRequestTime` DATETIME NOT NULL ;

UPDATE `user_visits` SET `FirstSiteRequestTime`=(SELECT `Time` FROM `user_siterequests` WHERE `user_siterequests`.`Visit`=`user_visits`.`ID` ORDER BY `Time` ASC LIMIT 1) ;

文件V2\u update\u table.sql：

ALTER TABLE  `user_visits` ADD  `FirstSiteRequestTime` DATETIME NOT NULL ;

UPDATE `user_visits` SET `FirstSiteRequestTime`=(SELECT `Time` FROM `user_siterequests` WHERE `user_siterequests`.`Visit`=`user_visits`.`ID` ORDER BY `Time` ASC LIMIT 1) ;

---

添加提交不会改变任何事情。另外，当将其分为两次迁移时，第二次迁移仍然失败。请参见上面的编辑。我似乎误诊了这个问题。我道歉。但至少现在，迁移分离后，问题应该更容易调试。请验证Flyway是否认为第一个迁移ALTER表已成功。使用flyway信息或检查schema_版本表。如果第一次迁移失败，正如回滚所暗示的那样，这就是问题所在。如果成功，请检查数据库结构以确保ALTER TABLE命令成功，然后尝试使用phpmyadmin再次运行UPDATE命令并验证结果。第一次迁移成功，第二次迁移失败。第二个的日志：256查询集自动提交=0 256查询更新用户\u访问集FirstSiteRequestTime=从用户\u siterequests中选择时间，其中用户\u siterequests.Visit=用户\u访问.ID按时间排序ASC限制1 256查询回滚256查询集自动提交=1在phpmyadmin中运行第二个仍然有效。我认为这是一个超时问题。现在问题更清楚了。由于超时，事务似乎正在回滚。我怀疑是MySQL在回滚它，但它可能是Flyway/Java堆栈中的某个东西。请验证显示变量的输出，如%timeout%；。对变量进行了解释。这似乎类似于。Flyway没有设置任何特定的超时。这一切都发生在DB端。