數據庫的錯誤操作有哪些

這篇文章主要講解了“數據庫的錯誤操作有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“數據庫的錯誤操作有哪些”吧！

1.不要用聊天工具發(fā)sql語句

通常開發(fā)人員寫好sql語句之后，習慣通過聊天工具，比如：qq、釘釘、或者騰訊通等，發(fā)給團隊老大或者DBA在線上環(huán)境執(zhí)行。但由于有些聊天工具，對部分特殊字符會自動轉義，而且有些消息由于內容太長，會被自動分成多條消息。

這樣會導致團隊老大或者DBA復制出來的sql不一定是正確的。

他們需要手動拼接成一條完整的sql，有時甚至需要把轉義后的字符替換回以前的特殊字符，無形之中會浪費很多額外的時間。即使最終sql拼接好了，真正執(zhí)行sql的人，心里一定很虛。

所以，強烈建議你把要在線上執(zhí)行的sql語句用郵件發(fā)過去，可以避免使用聊天工具的一些弊端，減少一些誤操作的機會。而且有個存檔，方便今后有問題的時候回溯原因。很多聊天工具只保留最近7天的歷史記錄，郵件會保留更久一些。

別用聊天工具發(fā)sql語句!

別用聊天工具發(fā)sql語句!

別用聊天工具發(fā)sql語句!

重要的事情說三遍，它真的能減少一些誤操作。

2.把sql語句壓縮成一行

有些時候，開發(fā)人員寫的sql語句很長，使用了各種join和union，而且使用美化工具，將一條sql變成了多行。在復制sql的時候，自己都無法確定sql是否完整。(為了裝逼，把自己也坑了，哈哈哈)

線上環(huán)境有時候需要通過命令行連接數據庫，比如：mysql，你把sql語句復制過來后，在命令行界面執(zhí)行，由于屏幕滾動太快，這時根本無法確定sql是否都執(zhí)行成功。

針對這類問題，強烈建議把sql語句壓縮成一行，去掉多余的換行符和空格，可以有效的減少一些誤操作。

sql壓縮工具推薦使用：https://tool.lu/sql/

3.操作數據之前先select一下

需要特別說明的是：本文的操作數據主要指修改和刪除數據。

很多時候，由于我們人為失誤，把where條件寫錯了。但沒有怎么仔細檢查，就把sql語句直接執(zhí)行了。影響范圍小還好，如果影響幾萬、幾十萬，甚至幾百萬行數據，我們可能要哭了。

針對這種情況，在操作數據之前，把sql先改成select count(*)語句，比如：

update order set status=1 where status=0;

改成：

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

查一下該sql執(zhí)行后影響的記錄行數，做到自己心中有數。也給自己一次測試sql是否正確，確認是否執(zhí)行的機會。

4.操作數據sql加limit

即使通過上面的select語句確認了sql語句沒有問題，執(zhí)行后影響的記錄行數是對的。

也建議你不要立刻執(zhí)行，建議在正在執(zhí)行的時候，加上limit + select出的記錄行數。例如：

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

假設有一次性更新的數據太多，所有相關記錄行都會被鎖住，造成長時間的鎖等待，而造成用戶請求超時。

此外，加limit可以避免一次性操作太多數據，對服務器的cpu造成影響。

還有一個最重要的原因：加limit后，操作數據的影響范圍是完全可控的。

5.update時更新修改人和修改時間

很多人寫update語句時，如果要修改狀態(tài)，就只更新狀態(tài)，不管其他的字段。比如：

update order set status=1 where status=0;

這條sql會把status等于0的數據，全部更新成1。

后來發(fā)現(xiàn)業(yè)務邏輯有問題，不應該這么更新，需要把status狀態(tài)回滾。

這時你可能會很自然想到這條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;

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

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

主要有如下的原因：

• 為了標識非正常用戶操作，方便后面統(tǒng)計和定位問題。

• 有些情況下，在執(zhí)行sql語句的過程中，正常用戶產生數據的修改時間跟你的可能一模一樣，導致回滾時數據查多了。

6.多用邏輯刪除，少用物理刪除

在業(yè)務開發(fā)中，刪除數據是必不可少的一種業(yè)務場景。

有些人開發(fā)人員習慣將表設計成物理刪除，根據主鍵只用一條delete語句就能輕松搞定。

他們給出的理由是：節(jié)省數據庫的存儲空間。

想法是好的，但是現(xiàn)實很殘酷。

如果有條極重要的數據刪錯了，想恢復怎么辦?

此時只剩八個字：沒有數據，恢復不了。(PS：或許通過binlog二進制文件可以恢復)

如果之前設計表的時候用的邏輯刪除，上面的問題就變得好辦了。刪除數據時，只需update刪除狀態(tài)即可，例如：

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

假如出現(xiàn)異常，要恢復數據，把該id的刪除狀態(tài)還原即可，例如：

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

7.操作數據之前先做備份

如果只是修改了少量的數據，或者只執(zhí)行了一兩條sql語句，通過上面的修改人和修改時間字段，在需要回滾時，能快速的定位到正確的數據。

但是如果修改的記錄行數很多，并且執(zhí)行了多條sql，產生了很多修改時間。這時，你可能就要犯難了，沒法一次性找出哪些數據需要回滾。

為了解決這類問題，可以將表做備份。

可以使用如下sql備份：

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

先創(chuàng)建一張一模一樣的表，然后把數據復制到新表中。

也可以簡化成一條sql：

create table order_bak_2021031722 select * from`order`;

創(chuàng)建表的同時復制數據到新表中。

此外，建議在表名中加上bak和時間，一方面是為了通過表名快速識別出哪些表是備份表，另一方面是為了備份多次時好做區(qū)分。因為有時需要執(zhí)行多次sql才能把數據修復好，這種情況建議把表備份多次，如果出現(xiàn)異常，把數據回滾到最近的一次備份，可以節(jié)省很多重復操作的時間。

恢復數據時，把sql語句改成select語句，先在備份庫找出相關數據，每條數據對應一條update語句，還原到老表中。

8.中間結果寫入臨時表

有時候，我們要先用一條sql查詢出要更新的記錄的id，然后通過這些id更新數據。

批量更新之后，發(fā)現(xiàn)不對，要回滾數據。但由于有些數據已更新，此時使用相同的sql相同的條件，卻查不出上次相同的id了。

這時，我們開始慌了。

針對這種情況，我們可以先將第一次查詢的id存入一張臨時表，然后通過臨時表中的id作為查詢條件更新數據。

如果要恢復數據，只用通過臨時表中的id作為查詢條件更新數據即可。

修改完，3天之后，如果沒有出現(xiàn)問題，就可以把臨時表刪掉了。

9.表名前面一定要帶庫名

我們在寫sql時為了方便，習慣性不帶數據庫名稱。比如：

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

假如有多個數據庫中有相同的表order，表結構一模一樣，只是數據不一樣。

由于執(zhí)行sql語句的人一個小失誤，進錯數據庫了。

use trade1;

然后執(zhí)行了這條sql語句，結果悲劇了。

有個非常有效的預防這類問題的方法是加數據庫名：

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

這樣即使執(zhí)行sql語句前進錯數據庫了，也沒什么影響。

10.字段增刪改的限制

很多時候，我們少不了對表字段的操作，比如：新加、修改、刪除字段，但每種情況都不一樣。

新加的字段一定要允許為空新加的字段一定要允許為空。為什么要這樣設計呢?

正常情況下，如果程序新加了字段，一般是先在數據庫中加字段，然后再發(fā)程序的最新代碼。

為什么是這種順序?

因為如果先發(fā)程序，然后在數據庫中加字段。在該程序剛部署成功，但數據庫新字段還沒來得及加的這段時間內，最新程序中，所有使用了新加字段的增刪改查sql都會報字段不存在的異常。

好了，就按先在數據庫中加字段，再發(fā)程序的順序。

如果數據庫中新加的字段非空，最新的程序還沒發(fā)，線上跑的還是老代碼，這時如果有insert操作，就會報字段不能為空的異常。因為新加的非空字段，老代碼是沒法賦值的。

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

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

不允許刪除字段

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

為什么這么說?

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

如果先把程序部署好了，還沒來得及刪除數據庫相關表字段。當有insert請求時，由于數據庫中該字段是必填的，會報必填字段不能為空的異常。

如果先把數據庫中相關表字段刪了，程序還沒來得及發(fā)。這時所有涉及該刪除字段的增刪改查，都會報字段不存在的異常。

所以，線上環(huán)境必填字段一定不能刪除的。

根據實際情況修改字段

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

1.修改字段名稱

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術社區(qū)

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

3. 如果先把數據庫中字段名稱改了，程序還沒來得及發(fā)。這時所有涉及該字段的增刪改查，同樣也會報字段不存在的異常。

所以，線上環(huán)境字段名稱一定不要修改。

2.修改字段類型

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

tinyint改成int可以，但int改成tinyint要仔細衡量一下。

varchar改成text可以，但text改成varchar要仔細衡量一下。

3.修改字段長度

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

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

感謝各位的閱讀，以上就是“數據庫的錯誤操作有哪些”的內容了，經過本文的學習后，相信大家對數據庫的錯誤操作有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！