前言

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

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

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

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

3. 修复线上数据时，改错了，想还原。

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

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

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

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 压缩工具推荐使用：tool.lu/sql/

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

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

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

update order set status=1 where status=0; 

点击并拖拽以移动

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

点击并拖拽以移动

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

4.操作数据 sql 加 limit

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

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

点击并拖拽以移动

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

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

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

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

update order set status=1 where status=0;

点击并拖拽以移动

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

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

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; 

点击并拖拽以移动

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

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

点击并拖拽以移动

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

有些同学可能会问：为什么要同时更新修改人，只更新修改时间不行吗？

主要有如下的原因：

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

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

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

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

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

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

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

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

此时只剩八个字：没有数据，恢复不了。（PS：或许通过 binlog 二进制文件可以恢复）

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

点击并拖拽以移动

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

点击并拖拽以移动

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

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

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

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

create table order_bak_2021031721 like`order`;insert into order_bak_2021031721 select * from`order`;

点击并拖拽以移动

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

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 操作，就会报字段不能为空的异常。因为新加的非空字段，老代码是没法赋值的。

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

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

不允许删除字段

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

为什么这么说？

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

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

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

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

根据实际情况修改字段

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

1.修改字段名称

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

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

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

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

2.修改字段类型

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

1. tinyint 改成 int 可以，但 int 改成 tinyint 要仔细衡量一下。

2. varchar 改成 text 可以，但 text 改成 varchar 要仔细衡量一下。

3.修改字段长度

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

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

总结

本文分享了 10 种减少数据库误操作的方法，并非所有场景都适合你。特别是在一些高并发，或者单表数据量非常大的场景，你需要根据实际情况酌情选择。但我敢肯定的是读完这篇文章，你一定会有一些收获，因为大部分方法对你来说是适用的，可能会让你少走很多弯路，强烈建议收藏。

推荐阅读

零基础程序员，用这个方式写简历拿到了百万年薪？

Leetcode刷题的50个小技巧

程序员面试必备的软技巧

看完三件事❤️

如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：

点赞，转发，有你们的 『点赞和评论』，才是我创造的动力。

关注公众号 『 Java 斗帝 』，不定期分享原创知识。

同时可以期待后续文章 ing🚀