在mysqldump备份文件导入过程中出现错误时的意外行为

Question

我正在使用MySQL5.5.40版本。我正在使用脚本导入一个包含大约36000行的大型.sql文件。脚本包含以下语句。

mysql -uxx -p < dumpfile.sql 2> error.log

cat error.log|mail -s“导入错误”a@something.com

执行脚本后的某个时候，我收到一封邮件，上面写着“第35687行的错误1146 (42S02)：表'dbname.tablename‘不存在。由于我在导入时不使用force选项，所以它不应该从35688行执行行到36000行。当遇到错误时，它应该中止。但是当我手动检查时，这些行似乎被执行了。这是预期的行为吗？

在mysql命令行客户机中使用源代码命令时，我们知道它的预期行为。

Answer 1

我终于得到了答案。当将mysqldump作为数据库时，它首先为视图转储临时表结构(创建一个与视图同名的表，该表仅具有不带任何位置条件的普通列，并在myisam存储引擎下联接，尽管innodb是我的默认存储引擎)。稍后，在转储结束后，即在转储数据库的所有表、结构和过程之后，为其转储最终视图结构。

示例：

-视图sample_view的临时表结构

如果存在sample_view，则删除表；

/!50001删除视图(如果存在sample_view/)；

/*!50001创建表sample_view (

colA tinyint不为空，

colB tinyint不为空

) ENGINE=MyISAM */；

-视图sample_view的最终视图结构

/!50001放置表(如果存在sample_view/)；

/!50001删除视图(如果存在sample_view/)；

/*!50001创建ALGORITHM=UNDEFINED /

/!50013 DEFINER=root@localhost安全定义器/

/!50001查看sample_view作为选择sp.colA作为colA，sp.colB为colB从tableCsp (sp.START_DATE =(选择)

马克斯(b.START_DATE)来自tableCb，其中(b.colA= sp.colA)和

(b.START_DATE <= curdate() */；

因此，在导入时，我在指定的view.Import的最终视图结构上出现了错误，在这一点上没有进一步进行并中止。即使在转储文件中的这个特定视图之后，我在数据库中找到了其余的视图，但它们是不正确的。因此mysql导入正在按预期的方式进行。

Answer 2

这种行为是正确的，根据发问者的更新，它被错误地观察到了。通过在转储中错误的SQL之后添加调试select语法的进一步调试，验证了这一点。