卧槽，線上數據刪錯了，差點被老板開除

前言

無論是開發、測試，還是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壓縮工具推薦使用：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;

當然，如果是高並發系統不建議這種批量更新方式，可能會鎖表一定時間，造成請求超時。

有些同學可能會問：為什么要同時更新修改人，只更新修改時間不行嗎？

主要有如下的原因：

1. 為了標識非正常用戶操作，方便后面統計和定位問題。
2. 有些情況下，在執行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操作，就會報字段不能為空的異常。因為新加的非空字段，老代碼是沒法賦值的。

所以說新加的字段一定要允許為空。

除此之外，這種設計更多的考慮是為了程序發布失敗時的回滾操作。如果新加的字段允許為空，則可以不用回滾數據庫，只需回滾代碼即可，是不是很方便？

不允許刪除字段

刪除字段是不允許的，特別是必填字段一定不能刪除。

為什么這么說？

假設開發人員已經把程序改成不使用刪除字段了，接下來如何部署呢？

1. 如果先把程序部署好了，還沒來得及刪除數據庫相關表字段。當有insert請求時，由於數據庫中該字段是必填的，會報必填字段不能為空的異常。
2. 如果先把數據庫中相關表字段刪了，程序還沒來得及發。這時所有涉及該刪除字段的增刪改查，都會報字段不存在的異常。

所以，線上環境必填字段一定不能刪除的。

根據實際情況修改字段

修改字段要分為這三種情況：

1.修改字段名稱

修改字段名稱也不允許，跟刪除必填字段的問題差不多。

1. 如果把程序部署好了，還沒來得及修改數據庫中表字段名稱。這時所有涉及該字段的增刪改查，都會報字段不存在的異常。
2. 如果先把數據庫中字段名稱改了，程序還沒來得及發。這時所有涉及該字段的增刪改查，同樣也會報字段不存在的異常。

所以，線上環境字段名稱一定不要修改。

2.修改字段類型

修改字段類型時一定要兼容之前的數據。例如：

1. tinyint改成int可以，但int改成tinyint要仔細衡量一下。
2. varchar改成text可以，但text改成varchar要仔細衡量一下。

3.修改字段長度

字段長度建議改大，通常情況下，不建議改小。如果一定要改小，要先確認該字段可能會出現的最大長度，避免insert操作時出現字段太長的異常。

此外，建議改大也需要設置一個合理的長度，避免數據庫資源浪費。

總結

本文分享了10種減少數據庫誤操作的方法，並非所有場景都適合你。特別是在一些高並發，或者單表數據量非常大的場景，你需要根據實際情況酌情選擇。但我敢肯定的是讀完這篇文章，你一定會有一些收獲，因為大部分方法對你來說是適用的，可能會讓你少走很多彎路，強烈建議收藏。

最后說一句(求關注，別白嫖我)

如果這篇文章對您有所幫助，或者有所啟發的話，幫忙關注一下，您的支持是我堅持寫作最大的動力。

求一鍵三連：點贊、轉發、在看。

關注公眾號：【蘇三說技術】，在公眾號中回復：面試、代碼神器、開發手冊、時間管理有超贊的粉絲福利，另外回復：加群，可以跟很多BAT大廠的前輩交流和學習。