江苏龙网

  1. 主页 > 生活百科 > >

系统上线前，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 ， 后面就能追溯了 。


推荐阅读


上一篇：关于2023年的黑客攻击，首席信息安全官应该了解的事

下一篇：一文速览计算机的前世今生