系统上线时SQL脚本的9大坑
系统上线时，非常容易出问题。
即使之前在测试环境，已经执行过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 null comment '籍贯';在上线时，你给dba提sql工单时，该工单被dba审核拒绝打回来了。
然后为了赶时间，你急急忙忙把多条alter语句改成一条alter语句。
例如：
alter table t_user add `work` varchar(30) default null comment '工作',add `provice` varchar(10) default null comment '籍贯';但在修改的过程中，有地方少了一个逗号，就可能会出现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脚本的顺序不对，导致最终系统上线时的数据不对。
那么这个问题要如何解决呢？
双方要事先沟通好，把另外一个同事的sql脚本加到你的初始化脚本中，你的脚本在初始化时，直接去修改数据即可。
例如：
insert into `sue`.`t_user`(`id`, `code`, `age`, `name`, `height`, `address`, `work`, `provice`) values (1, '101', 25, '周星驰', 173, '香港', null, null);这样可以避免执行顺序问题。
4 执行时机不对有些系统功能已经上线了，在后面的迭代中，为了尽量避免少影响线上功能，可以增加一个pre（即预生产环境）。
该环境跟生产环境是差不多的，连接了相同的数据库，使用了相同的apollo配置。
但唯一的区别是pre环境没有实际的用户流量，只能公司内部人员才能访问。
一般在迭代版本上线之前，先要把系统功能发布到pre环境中，测试通过之后，才能发布到prod（即生产环境）。
但有些sql脚本，却没法再pre环境中执行，不然会影响生产环境。
比如：修改了字段类型，int改成varchar了，或者初始化数据时，初始化了一条新加的枚举数据。
由于pre环境是运行的最新代码，但prod环境还是运行的老代码。
如果在发布pre环境时，直接执行sql脚本，可能会导致prod环境的功能异常。
因此要搞清楚sql脚本的执行时机，哪些是要在pre环境执行的，哪些是要在prod环境执行的。
我们在提sql工单时，千万不要一股脑就提了，一定要区分时机。
在发pre环境时，要么不提发prod环境的sql脚本。要么，在工单的名称上做区分，比如增加prod_开头的标识。
这样可以解决sql脚本执行时机的问题。
5 搞错数据库了有时候，我们的数据库做了分库分表，或者增加备份库。
在执行sql脚本的时候，由于我们自己的疏忽，提sql工单时选错数据库了，或者dba的疏忽，在执行sql工单时搞错数据库了，就会出现问题。
建议我们的sql脚本增加库名，比如：
alter table sue.t_user add `work` varchar(30) default null comment '工作';这里增加库名：sue。
这样基本可以避免选错数据库的问题。
6 脚本耗时太长有时候，我们的sql脚本需要批量修改生产环境的一些数据，正常情况下一条update语句就能搞定。
例如：
update user set status=0 where status=1;但由于user表的数据量非常大，我们在执行该sql脚本之前，没有预先评估该sql脚本的耗时情况，而选择直接在生产环境的数据库中执行。
假如该sql脚本耗时非常长，比如要10分钟才能执行完，可能会导致user表长期锁表，影响正常的业务功能。
在该sql脚本执行的过程中，极有可能会出现业务功能操作，导致的死锁问题。
因此，建议这种大批量的数据更新操作，要在用户较少的凌晨，分批多次执行。
我们要尽可能少的影响线上用户的功能。
此外，在生产环境增加字段，增加索引等操作，也能会导致长期锁表。也要避免在用户访问高峰期执行相关的sql脚本。
7 脚本无法回滚绝大多数系统上线是能够成功的，虽然过程中会遇到很多问题，但如果能够及时解决，也能够上线成功。
但如果有些问题，没法再规定的时间内解决，很有可能会导致上线失败。
如果上线失败，意味着代码和数据库的sql脚本要回滚。
如果只回滚了代码，不回滚数据库，可能会导致很多系统异常。
因此，我们在准备sql语句时，要留点心眼，顺便想想该sql语句能否回滚。
对于update语句可以加上修改时间：
update t_user set age=25,time=now(3) where id=1;这样可以通过该时间追溯一次sql操作修改的数据，方便后面做回滚。
有些时候我们要update的数据，是要通过多条sql语句查询出来的，比如：需要使用的id。
为了方便回滚我们可以增加临时表，保存这些id，后面就能追溯了。
当然有些开源的数据库管理平台，比如：archery，是有自带sql审核和回滚的功能。
8 忘了加索引我们在增加了字段之后，非常容易忽略的一件事是：加索引。
特别是当前表数据量很大，而且增加的字段是另外一张表的id时，这种情况强烈建议增加索引。
如果我们上线系统时，在sql脚本中，忘了给该字段增加索引。如果该id字段被大批量访问，全部走的全表扫描，可能会导致数据库性能直线下降，出现大量的超时问题。
所以建议我们在开发的时候，如果要增加字段的话，要养成良好习惯，想一想这个字段需不需要建索引。
如果不确定数据量的话，可以先到生产环境查询一下真实的用户数据，不然后续可能会引起比较大的生产事故。
9 字段改名对于生产环境的表字段，通常情况下，我们不允许修改名称。
如果你在发布pre环境时，通过sql脚本把某张表的某个字段名称修改了，pre环境代码使用了新的名称，系统没有问题。
但prod环境还是使用老的名称，所有使用该名称的sql语句，在代码执行过程中都会报错。
因此，禁止在生产环境通过sql脚本修改字段名称。
当然系统上线时除了sql脚本的这些坑之外，还有系统发版失败，代码合错分支，mq消息被pre消费了，无法回滚等等，还有很多问题。
这套装备能将电竞的技术和颜值提高到什么地步
纳微半导体发布第三代氮化镓平台NV6169功率芯片
利用GPRS无线网络技术实现变频调速供水的远程控制系统的设计
人工智能运用于边缘的技术挑战
助力OpenHarmony技术共建，深开鸿包揽多项荣誉
系统上线时SQL脚本的9大坑
关于超维科技智能巡检机器人的介绍
全极性霍尔元件AH464在计数呼啦圈中的应用
FLIR红外热像仪在检测PCB组件温差方面的应用
华为又一专利公开，芯片堆叠技术持续进步
IEAE广州电子展火热招商中，预定已超7成
计算机系统中的电磁兼容EMC问题解析
交叉导轨的装卸与拆卸注意事项
自主重建几乎幻灭！引入外资成JDI最后机会
工业互联加智能制造要实现转型升级需要十大关键技术的支持
重新分配FlexRAM的方法
物联网高交会上赚足眼球，专家称与国外差距仍较大
SiOnyx发布全球首款真正全天时彩色成像高清运动摄像机
8K助推电视大屏化趋势 加大技术创新势在必行
小米6放大版小米Note3对比评测：配置有高低价格却一样
即使之前在测试环境，已经执行过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 null comment '籍贯';在上线时，你给dba提sql工单时，该工单被dba审核拒绝打回来了。
然后为了赶时间，你急急忙忙把多条alter语句改成一条alter语句。
例如：
alter table t_user add `work` varchar(30) default null comment '工作',add `provice` varchar(10) default null comment '籍贯';但在修改的过程中，有地方少了一个逗号，就可能会出现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脚本的顺序不对，导致最终系统上线时的数据不对。
那么这个问题要如何解决呢？
双方要事先沟通好，把另外一个同事的sql脚本加到你的初始化脚本中，你的脚本在初始化时，直接去修改数据即可。
例如：
insert into `sue`.`t_user`(`id`, `code`, `age`, `name`, `height`, `address`, `work`, `provice`) values (1, '101', 25, '周星驰', 173, '香港', null, null);这样可以避免执行顺序问题。
4 执行时机不对有些系统功能已经上线了，在后面的迭代中，为了尽量避免少影响线上功能，可以增加一个pre（即预生产环境）。
该环境跟生产环境是差不多的，连接了相同的数据库，使用了相同的apollo配置。
但唯一的区别是pre环境没有实际的用户流量，只能公司内部人员才能访问。
一般在迭代版本上线之前，先要把系统功能发布到pre环境中，测试通过之后，才能发布到prod（即生产环境）。
但有些sql脚本，却没法再pre环境中执行，不然会影响生产环境。
比如：修改了字段类型，int改成varchar了，或者初始化数据时，初始化了一条新加的枚举数据。
由于pre环境是运行的最新代码，但prod环境还是运行的老代码。
如果在发布pre环境时，直接执行sql脚本，可能会导致prod环境的功能异常。
因此要搞清楚sql脚本的执行时机，哪些是要在pre环境执行的，哪些是要在prod环境执行的。
我们在提sql工单时，千万不要一股脑就提了，一定要区分时机。
在发pre环境时，要么不提发prod环境的sql脚本。要么，在工单的名称上做区分，比如增加prod_开头的标识。
这样可以解决sql脚本执行时机的问题。
5 搞错数据库了有时候，我们的数据库做了分库分表，或者增加备份库。
在执行sql脚本的时候，由于我们自己的疏忽，提sql工单时选错数据库了，或者dba的疏忽，在执行sql工单时搞错数据库了，就会出现问题。
建议我们的sql脚本增加库名，比如：
alter table sue.t_user add `work` varchar(30) default null comment '工作';这里增加库名：sue。
这样基本可以避免选错数据库的问题。
6 脚本耗时太长有时候，我们的sql脚本需要批量修改生产环境的一些数据，正常情况下一条update语句就能搞定。
例如：
update user set status=0 where status=1;但由于user表的数据量非常大，我们在执行该sql脚本之前，没有预先评估该sql脚本的耗时情况，而选择直接在生产环境的数据库中执行。
假如该sql脚本耗时非常长，比如要10分钟才能执行完，可能会导致user表长期锁表，影响正常的业务功能。
在该sql脚本执行的过程中，极有可能会出现业务功能操作，导致的死锁问题。
因此，建议这种大批量的数据更新操作，要在用户较少的凌晨，分批多次执行。
我们要尽可能少的影响线上用户的功能。
此外，在生产环境增加字段，增加索引等操作，也能会导致长期锁表。也要避免在用户访问高峰期执行相关的sql脚本。
7 脚本无法回滚绝大多数系统上线是能够成功的，虽然过程中会遇到很多问题，但如果能够及时解决，也能够上线成功。
但如果有些问题，没法再规定的时间内解决，很有可能会导致上线失败。
如果上线失败，意味着代码和数据库的sql脚本要回滚。
如果只回滚了代码，不回滚数据库，可能会导致很多系统异常。
因此，我们在准备sql语句时，要留点心眼，顺便想想该sql语句能否回滚。
对于update语句可以加上修改时间：
update t_user set age=25,time=now(3) where id=1;这样可以通过该时间追溯一次sql操作修改的数据，方便后面做回滚。
有些时候我们要update的数据，是要通过多条sql语句查询出来的，比如：需要使用的id。
为了方便回滚我们可以增加临时表，保存这些id，后面就能追溯了。
当然有些开源的数据库管理平台，比如：archery，是有自带sql审核和回滚的功能。
8 忘了加索引我们在增加了字段之后，非常容易忽略的一件事是：加索引。
特别是当前表数据量很大，而且增加的字段是另外一张表的id时，这种情况强烈建议增加索引。
如果我们上线系统时，在sql脚本中，忘了给该字段增加索引。如果该id字段被大批量访问，全部走的全表扫描，可能会导致数据库性能直线下降，出现大量的超时问题。
所以建议我们在开发的时候，如果要增加字段的话，要养成良好习惯，想一想这个字段需不需要建索引。
如果不确定数据量的话，可以先到生产环境查询一下真实的用户数据，不然后续可能会引起比较大的生产事故。
9 字段改名对于生产环境的表字段，通常情况下，我们不允许修改名称。
如果你在发布pre环境时，通过sql脚本把某张表的某个字段名称修改了，pre环境代码使用了新的名称，系统没有问题。
但prod环境还是使用老的名称，所有使用该名称的sql语句，在代码执行过程中都会报错。
因此，禁止在生产环境通过sql脚本修改字段名称。
当然系统上线时除了sql脚本的这些坑之外，还有系统发版失败，代码合错分支，mq消息被pre消费了，无法回滚等等，还有很多问题。
这套装备能将电竞的技术和颜值提高到什么地步
纳微半导体发布第三代氮化镓平台NV6169功率芯片
利用GPRS无线网络技术实现变频调速供水的远程控制系统的设计
人工智能运用于边缘的技术挑战
助力OpenHarmony技术共建，深开鸿包揽多项荣誉
系统上线时SQL脚本的9大坑
关于超维科技智能巡检机器人的介绍
全极性霍尔元件AH464在计数呼啦圈中的应用
FLIR红外热像仪在检测PCB组件温差方面的应用
华为又一专利公开，芯片堆叠技术持续进步
IEAE广州电子展火热招商中，预定已超7成
计算机系统中的电磁兼容EMC问题解析
交叉导轨的装卸与拆卸注意事项
自主重建几乎幻灭！引入外资成JDI最后机会
工业互联加智能制造要实现转型升级需要十大关键技术的支持
重新分配FlexRAM的方法
物联网高交会上赚足眼球，专家称与国外差距仍较大
SiOnyx发布全球首款真正全天时彩色成像高清运动摄像机
8K助推电视大屏化趋势 加大技术创新势在必行
小米6放大版小米Note3对比评测：配置有高低价格却一样