從過往MySQL資料庫生產環境的維護工作中,總結的一些小經驗和知識,未必有多深奧,但是對我們消除隱患,確保MySQL資料庫生產環境四個9的作用非常有效之一的手段,營運人員要非常注意細節,盡量減低故障發生的機率。
(一) DML語句書寫建議
(1). DML語句不允許出現@number方式替代欄位名稱
不合理的寫法:
UPDATE table_name SET @1=NOW() WHERE @2=1;
正確的寫法:
UPDATE table_name SET column_name1=NOW() WHERE column_name2=1;
(2). UPDATE OR DELETE 禁用LIMIT子句
不合理的寫法:
UPDATE table_name SET column_name1=NOW() WHERE column_name2=1 LIMIT 1;
正確的寫法:
UPDATE table_name SET column_name1=NOW() WHERE column_name2=1;
(3). INSERT語句需要寫清楚值和欄位對應關係
不合理的寫法:
INSERT INTO table_name VALUES(NOW(),DATE_ADD(NOW(),INTERVAL +1 DAY));
正確的寫法:
INSERT INTO table_name(gmt_create,gmt_modify) VALUES(NOW(),DATE_ADD(NOW(),INTERVAL +1 DAY));
(4). DML語句少用不確定性函數
常見被大家使用的不確定性函數:UUID()、RAND()、SYSDATE()等函數,若無特殊用處之外,請以確定性函數替代之。
推薦閱讀的技術文章:曾用於內部培訓的PPT內容:MySQL開發規範與實用技術交流
(二) 大資料量的DELETE OR UPDATE
可能出於某些原因和運營目的,需要對資料庫中的資料進行大量的清理或更改某欄位的值,分別舉 二個樣本:
① 網路專項整治的時期,需要刪除大量含某些關鍵詞的內容;
② 給符合某一條件(例如:等級,線上時間長度)的遊戲玩家,贈送100~1000不等數量的遊戲幣;
給出的2個資料修改需求樣本,若是直接根據相關要求去做,一個是需要用到模糊查詢,另一個資料更新條件也沒有合理索引可用,為此可能造成表對象表級鎖被長時間鎖住,而且阻塞其他更改類型資料操作服務,所以我們不得不採用更合理的辦法,建議如下步驟實施:
① 設計並建立一張表tmp_pk_data ,用於記錄將要被修改記錄的主鍵,及需要的相關資訊;
② 優先考慮在備庫上跑一條SQL命令或預存程序的方式,把主鍵及相關資料寫到表tmp_pk_data中;
③ 編寫一個預存程序,使用遊標迴圈控制獲得tmp_pd_data的資訊,根據主鍵更新或刪除目標表的資料,且建議此操作在備庫上完成(注釋:必須是雙主複製模式,才可在備庫上執行);
(三) 定期規律性清理資料的DELETE
定期規律性資料的清理,優先對目標表的資料操縱方式進行分類:
① 若是日誌類型的資料,則完全可以改為藉助分區表的方式,比如按日期刪除資料的條件,則可以用日期作為資料分區條件,然後增刪分區的方式實現資料的清理工作;
② 若是資料的UPDATE/DELETE/SELECT操縱條件,與定期清理資料的規則一致或被其包含,則可以考慮使用分區表,然後藉助刪除分區方式達到資料清理的目標;
③ 若不能使用分區表解決的,則可以考慮參考上章節介紹的“大資料量的DELETE OR UPDATE”內容;
(四) M-M架構的大資料量DML技巧
定期規律性資料的清理,優先對目標表的資料操縱方式進行分類:
① 若是日誌類型的資料,則完全可以改為藉助分區表的方式,比如按日期刪除資料的條件,則可以用日期作為資料分區條件,然後增刪分區的方式實現資料的清理工作;
② 若是資料的UPDATE/DELETE/SELECT操縱條件,與定期清理資料的規則一致或被其包含,則可以考慮使用分區表,然後藉助刪除分區方式達到資料清理的目標;
③ 若不能使用分區表解決的,則可以考慮參考上章節介紹的“大資料量的DELETE OR UPDATE”內容;