系统上线前，SQL脚本的九大坑 _SQL

前言系统上线时，非常容易出问题。
即使之前在测试环境，已经执行过SQL脚本了。但是有时候，在系统上线时，在生产环境执行相同的SQL脚本，还是有可能出现一些问题。
有些小公司， SQL脚本是开发自己执行的，有很大的风险。
有些大厂，有专业的DBA把关，但DBA也不是万能的，还是有可能会让一些错误的SQL脚本被生产环境执行了，比如：update语句的顺序不对。
今天跟大家一起聊聊，系统上线时SQL脚本的9大坑，以便于大家吸取教训，能够防微杜渐，希望对你会有所帮助。

文章插图

1 漏脚本了我们上线时执行的SQL脚本，出现次数最多的问题，应该是漏脚本了。

有时候少加了一个字段。
有时候字段的注释没有及时修改。
有时候有些新表没创建。
有时候字段类型忘了修改。

等等。
我们的SQL脚本中漏脚本的情况有很多。
那么，如何解决这个问题呢？
答：将SQL脚本做成代码的一部分。在项目的代码中，创建一个专门的sql目录，在该目录下根据每个迭代创建一个子目录，比如：mv3.2.1 ，将SQL脚本存放到mv3.2.1下。
我们在开发环境任何对表的相关操作，比如：增加字段、修改字段类型、修改注释、增加索引、创建表等等，都需要通过SQL语句操作，然后把该SQL语句，整理到SQL脚本中。
最后提交到公司的GitLab上，我们在测试环境和生产环境发版时，去GitLab上找相关迭代版本的SQL脚本执行。
通过该方式基本可以解决漏脚本的问题。
2 脚本语法错误有些小伙伴看到这个标题可能有点懵， SQL脚本不是已经在测试环境执行过了吗？为什么还会出现语法错误？
比如说有这样的场景：原本你的SQL脚本没问题的，但没有按照规范，给一张表的添加多个字段，你写了多条ALTER语句。
例如：

alter table t_user add column`work` varchar(30) DEFAULT NULL COMMENT '工作';alter table t_user add column`provice` varchar(10) DEFAULT NULLCOMMENT '籍贯';

在上线时，你给DBA提SQL工单时，该工单被DBA审核拒绝打回来了。
然后为了赶时间，你急急忙忙把多条ALTER语句改成一条ALTER语句。
例如：

alter table t_user add `work` varchar(30) DEFAULT NULL COMMENT '工作',add `provice` varchar(10) DEFAULT NULLCOMMENT '籍贯';

但在修改的过程中，有地方少了一个逗号，就可能会出现SQL语法错误。
因此，不管是什么SQL语句，要养成好习惯，只要修改了一定要记得到开发环境的数据库中，先执行测试一下，切勿直接提到生产环境，即使你有很大的把握，也需要再更慎重一些。
这样基本可以避免SQL语法错误的问题。
3 脚本顺序不对有些时候，我们在上线系统时， DBA在执行SQL脚本的时候，没有报错，但最后的数据就是不对。
有可能是脚本顺序不对导致的。
比如有这样一种场景：你往某张表通过insert初始化了一条数据。
例如：

INSERT INTO `sue`.`t_user`(`id`, `code`, `age`, `name`, `height`, `address`, `work`, `provice`) VALUES (1, '101', 21, '周星驰', 173, '香港', NULL, NULL);

另外一个人要基于你这条数据，通过update修改数据。
例如：
update t_user set age=25 where id=1;你们提了两条SQL脚本。
另外一个人先提的，你后提的。
DBA先把他的SQL工单审核通过了，先update数据，此时通过id是没法找到那条数据的，影响行数为0 。
然后DBA再审核你的SQL工单，审核通过了，插入了一条数据。
由于SQL脚本的顺序不对，导致最终系统上线时的数据不对。
那么这个问题要如何解决呢？