您好!欢迎来到北极熊网

北极熊网

热门搜索: 任正非传    神雕侠侣    红楼梦   

盘点一下数据库的误操作有哪些后悔药?

  • 时间:2021-03-25 21:38 编辑:佚名 来源:网络 阅读:230
  • 扫一扫,手机访问
摘要:前言无论是开发、测试,还是DBA,都难免会涉及到数据库的操作,比如:创建某张表,添加某个字段、添加数据、更新数据、删除数据、查询数据等等。正常情况下还好,但如果操作数据库时出现失误,比如:删除订单数据时where条件写错了,导致多删了很多用户订单。更新会员有效时间时,一次性把所有会员的有效时间都更新了。修复线上数据时,改错了,想还原。还有很多很多场景,我就不一一列举了。如果出现线上环境数据库误操作怎么办?有没有后悔药?答案是有的,请各位

前言


无论是开发、测试,还是DBA,都难免会涉及到数据库的操作,比如:创建某张表,添加某个字段、添加数据、更新数据、删除数据、查询数据等等。


正常情况下还好,但如果操作数据库时出现失误,比如:


删除订单数据时where条件写错了,导致多删了很多用户订单。


更新会员有效时间时,一次性把所有会员的有效时间都更新了。


修复线上数据时,改错了,想还原。


还有很多很多场景,我就不一一列举了。


如果出现线上环境数据库误操作怎么办?有没有后悔药?


答案是有的,请各位看官仔细往下看。


1.不要用聊天工具发sql语句


通常开发人员写好sql语句之后,习惯通过聊天工具,比如:qq、钉钉、或者腾讯通等,发给团队老大或者DBA在线上环境执行。但由于有些聊天工具,对部分特殊字符会自动转义,而且有些消息由于内容太长,会被自动分成多条消息。


这样会导致团队老大或者DBA复制出来的sql不一定是正确的。


他们需要手动拼接成一条完整的sql,有时甚至需要把转义后的字符替换回以前的特殊字符,无形之中会浪费很多额外的时间。即使最终sql拼接好了,真正执行sql的人,心里一定很虚。


所以,强烈建议你把要在线上执行的sql语句用邮件发过去,可以避免使用聊天工具的一些弊端,减少一些误操作的机会。而且有个存档,方便今后有问题的时候回溯原因。很多聊天工具只保留最近7天的历史记录,邮件会保留更久一些。


别用聊天工具发sql语句!


别用聊天工具发sql语句!


别用聊天工具发sql语句!


重要的事情说三遍,它真的能减少一些误操作。


2.把sql语句压缩成一行


有些时候,开发人员写的sql语句很长,使用了各种join和union,而且使用美化工具,将一条sql变成了多行。在复制sql的时候,自己都无法确定sql是否完整。(为了装逼,把自己也坑了,哈哈哈)


线上环境有时候需要通过命令行连接数据库,比如:mysql,你把sql语句复制过来后,在命令行界面执行,由于屏幕滚动太快,这时根本无法确定sql是否都执行成功。


针对这类问题,强烈建议把sql语句压缩成一行,去掉多余的换行符和空格,可以有效的减少一些误操作。


sql压缩工具推荐使用:https://tool.lu/sql/


3.操作数据之前先select一下


需要特别说明的是:本文的操作数据主要指修改和删除数据。


很多时候,由于我们人为失误,把where条件写错了。但没有怎么仔细检查,就把sql语句直接执行了。影响范围小还好,如果影响几万、几十万,甚至几百万行数据,我们可能要哭了。


针对这种情况,在操作数据之前,把sql先改成select count(*)语句,比如:


update order set status=1 where status=0;


改成:


select count(*) from order where status=0;


查一下该sql执行后影响的记录行数,做到自己心中有数。也给自己一次测试sql是否正确,确认是否执行的机会。


4.操作数据sql加limit


即使通过上面的select语句确认了sql语句没有问题,执行后影响的记录行数是对的。


也建议你不要立刻执行,建议在正在执行的时候,加上limit + select出的记录行数。例如:


update order set status=1 where status=0 limit 1000;


假设有一次性更新的数据太多,所有相关记录行都会被锁住,造成长时间的锁等待,而造成用户请求超时。


此外,加limit可以避免一次性操作太多数据,对服务器的cpu造成影响。


还有一个最重要的原因:加limit后,操作数据的影响范围是完全可控的。


5.update时更新修改人和修改时间


很多人写update语句时,如果要修改状态,就只更新状态,不管其他的字段。比如:


update order set status=1 where status=0;


这条sql会把status等于0的数据,全部更新成1。


后来发现业务逻辑有问题,不应该这么更新,需要把status状态回滚。


这时你可能会很自然想到这条sql:


update order set status=0 where status=1;


但仔细想想又有些不对。


这样不是会把有部分以前status就是1的数据更新成0?


这回真的要哭了,呜呜呜。


这时,送你一个好习惯:在更新数据的时候,同时更新修改人和修改时间字段。


update order set status=1,edit_date=now(),edit_user='admin' where status=0;


这样在恢复数据时就能通过修改人和修改时间字段过滤数据了。


后面需要用到的修改时间通过这条sql语句可以轻松找到:


select edit_user ,edit_date from `order` order by edit_date desc limit 50;


当然,如果是高并发系统不建议这种批量更新方式,可能会锁表一定时间,造成请求超时。


有些同学可能会问:为什么要同时更新修改人,只更新修改时间不行吗?


主要有如下的原因:


为了标识非正常用户操作,方便后面统计和定位问题。


有些情况下,在执行sql语句的过程中,正常用户产生数据的修改时间跟你的可能一模一样,导致回滚时数据查多了。


6.多用逻辑删除,少用物理删除


在业务开发中,删除数据是必不可少的一种业务场景。


有些人开发人员习惯将表设计成物理删除,根据主键只用一条delete语句就能轻松搞定。


他们给出的理由是:节省数据库的存储空间。


想法是好的,但是现实很残酷。


如果有条极重要的数据删错了,想恢复怎么办?


此时只剩八个字:没有数据,恢复不了。(PS:或许通过binlog二进制文件可以恢复)


如果之前设计表的时候用的逻辑删除,上面的问题就变得好办了。删除数据时,只需update删除状态即可,例如:


update order set del_status=1,edit_date=now(),edit_user='admin' where id=123;


假如出现异常,要恢复数据,把该id的删除状态还原即可,例如:


update order set del_status=0,edit_date=now(),edit_user='admin' where id=123;


7.操作数据之前先做备份


如果只是修改了少量的数据,或者只执行了一两条sql语句,通过上面的修改人和修改时间字段,在需要回滚时,能快速的定位到正确的数据。


但是如果修改的记录行数很多,并且执行了多条sql,产生了很多修改时间。这时,你可能就要犯难了,没法一次性找出哪些数据需要回滚。


为了解决这类问题,可以将表做备份。


可以使用如下sql备份:


create table order_bak_2021031721 like`order`;


insert into order_bak_2021031721 select * from`order`;


先创建一张一模一样的表,然后把数据复制到新表中。


也可以简化成一条sql:


create table order_bak_2021031722 select * from`order`;


创建表的同时复制数据到新表中。


此外,建议在表名中加上bak和时间,一方面是为了通过表名快速识别出哪些表是备份表,另一方面是为了备份多次时好做区分。因为有时需要执行多次sql才能把数据修复好,这种情况建议把表备份多次,如果出现异常,把数据回滚到最近的一次备份,可以节省很多重


复操作的时间。


恢复数据时,把sql语句改成select语句,先在备份库找出相关数据,每条数据对应一条update语句,还原到老表中。


8.中间结果写入临时表


有时候,我们要先用一条sql查询出要更新的记录的id,然后通过这些id更新数据。


批量更新之后,发现不对,要回滚数据。但由于有些数据已更新,此时使用相同的sql相同的条件,却查不出上次相同的id了。


这时,我们开始慌了。


针对这种情况,我们可以先将第一次查询的id存入一张临时表,然后通过临时表中的id作为查询条件更新数据。


如果要恢复数据,只用通过临时表中的id作为查询条件更新数据即可。


修改完,3天之后,如果没有出现问题,就可以把临时表删掉了。


9.表名前面一定要带库名


我们在写sql时为了方便,习惯性不带数据库名称。比如:


update order set status=1,edit_date=now(),edit_user='admin' where status=0;


假如有多个数据库中有相同的表order,表结构一模一样,只是数据不一样。


由于执行sql语句的人一个小失误,进错数据库了。


use trade1;


然后执行了这条sql语句,结果悲剧了。


有个非常有效的预防这类问题的方法是加数据库名:



update `trade2`.`order` set status=1,edit_date=now(),edit_user='admin' where status=0;


这样即使执行sql语句前进错数据库了,也没什么影响。


10.字段增删改的限制


很多时候,我们少不了对表字段的操作,比如:新加、修改、删除字段,但每种情况都不一样。


新加的字段一定要允许为空


新加的字段一定要允许为空。为什么要这样设计呢?


正常情况下,如果程序新加了字段,一般是先在数据库中加字段,然后再发程序的最新代码。


为什么是这种顺序?


因为如果先发程序,然后在数据库中加字段。在该程序刚部署成功,但数据库新字段还没来得及加的这段时间内,最新程序中,所有使用了新加字段的增删改查sql都会报字段不存在的异常。


好了,就按先在数据库中加字段,再发程序的顺序。


如果数据库中新加的字段非空,最新的程序还没发,线上跑的还是老代码,这时如果有insert操作,就会报字段不能为空的异常。因为新加的非空字段,老代码是没法赋值的。


所以说新加的字段一定要允许为空。


除此之外,这种设计更多的考虑是为了程序发布失败时的回滚操作。如果新加的字段允许为空,则可以不用回滚数据库,只需回滚代码即可,是不是很方便?


不允许删除字段


删除字段是不允许的,特别是必填字段一定不能删除。


为什么这么说?


假设开发人员已经把程序改成不使用删除字段了,接下来如何部署呢?


如果先把程序部署好了,还没来得及删除数据库相关表字段。当有insert请求时,由于数据库中该字段是必填的,会报必填字段不能为空的异常。


如果先把数据库中相关表字段删了,程序还没来得及发。这时所有涉及该删除字段的增删改查,都会报字段不存在的异常。


所以,线上环境必填字段一定不能删除的。


根据实际情况修改字段


修改字段要分为这三种情况:


1.修改字段名称


修改字段名称也不允许,跟删除必填字段的问题差不多。


如果把程序部署好了,还没来得及修改数据库中表字段名称。这时所有涉及该字段的增删改查,都会报字段不存在的异常。


如果先把数据库中字段名称改了,程序还没来得及发。这时所有涉及该字段的增删改查,同样也会报字段不存在的异常。


所以,线上环境字段名称一定不要修改。


2.修改字段类型


修改字段类型时一定要兼容之前的数据。例如:


tinyint改成int可以,但int改成tinyint要仔细衡量一下。


varchar改成text可以,但text改成varchar要仔细衡量一下。


3.修改字段长度


字段长度建议改大,通常情况下,不建议改小。如果一定要改小,要先确认该字段可能会出现的最大长度,避免insert操作时出现字段太长的异常。


此外,建议改大也需要设置一个合理的长度,避免数据库资源浪费。


来源网络,如有侵权联系删除


  • 全部评论(0)
资讯详情页最新发布上方横幅
最新发布的资讯信息
【今日头条|头条】当代的丑态丛生,资本已经到了无耻地步(2021-11-20 23:44)
【今日头条|头条】搜狐视频会员 2021年11月17日更新第4批 小爸爸搜狐视频,搜狐视频大视野,为什么艾九影视看不了火影忍者?(2021-11-18 12:03)
【程序人生|Python】Python 之父:Python 4.0 可能不会来了(2021-11-10 22:48)
【今日头条|头条】低代码发展正当时,中国有望超过美国成为全球低代码开发领域的领导者(2021-11-03 21:32)
【今日头条|头条】网盘免费下载速度慢?有好消息了(2021-11-02 21:07)
【今日头条|头条】尽快卸载这两款恶意浏览器插件!已有近50万用户安装(2021-11-01 20:52)
【今日头条|头条】都2021年了,这个国家一半电脑还在使用Windows XP(2021-10-30 22:51)
【技术文档|架构】一个轻量级、高性能的 C++ Web 框架(2021-10-30 21:02)
【程序人生|Python】10分钟教你搭建一个好玩的Python全文搜索引擎(2021-10-28 21:36)
【今日头条|前沿科技】Safari浏览器正在杀死Web(2021-10-27 19:54)
联系我们
电话:18936411277
邮箱:1044412291@qq.com
时间:09:00 - 19:00
公众号:北格软件
底部广告