僅個人總結，歡迎一起交流！
MySQL優化的本質：
1. 結合MySQL資料庫的主要特性（資料存盤與資料查詢），使得資料存盤占用空間更小，更新、查詢速度更快，并發程度更高，使得服務器資源利用率更高，
2. 尤其是對于大資料量、高并發的業務場景，避免因不合理的設計拖垮資料庫，造成資料庫宕機、資料丟失、業務無法正常進行等問題，保證服務的可用性，
以下為本人總結的部分優化建議：
-
選擇InnoDB引擎，InnoDB引擎支持事務、行級鎖、并發性能更好，CPU及記憶體快取頁優化使得資源利用率更高，
-
使用UTF8字符集，UTF-8MB4，無需轉碼，不存在亂碼的風險，更節省空間，
-
減少存盤程序、視圖、觸發器等使用，盡量將計算邏輯設計運用至業務代碼層面，避免因耗時計算影響到資料庫的并發，嚴重時拖垮資料庫，
-
使用自增主鍵，Innodb是基于B+樹的索引組織表，使用自增主鍵，資料行寫入可以提高插入性能，可以避免頁分裂，減少表碎片提升空間和記憶體的使用，
-
禁止使用外鍵，外鍵導致表和表之間的耦合，更新和洗掉操作涉及關聯的表，極大地影響sql的性能，甚至可能造成死鎖，
-
禁止使用TEXT、BLOB型別，更多的磁盤和記憶體空間將被浪費，且大欄位查詢將會清理掉熱點資料的快取，導致快取命中率急劇下降并影響資料庫性能，如有必要，創建另一個表記錄，將熱點資料與大欄位資料分離，
-
適當的建立索引，避免全表掃描，
-
不要過多的建立索引，建議控制在5個以內，索引的本質是對資料順序的記錄，占用存盤空間，不宜過多，可使用EXPLAIN來查看了解索引命中情況，
-
索引的建立原則：為常用于where或orderby陳述句后的欄位建立索引，但對于資料值變化少（區分度不大）的情況不適用，如“性別”欄位，一般值為“男/女/未知”等，建立這種索引并不能加快查詢速度，卻浪費了磁盤空間，
-
更新十分頻繁的欄位上不宜建立索引，更新操作會變更B+樹，重建索引，這個程序十分耗性能，
-
聯合索引的建立要滿足“最左匹配”原則，將命中率更高的欄位建立在最前面，
-
列值設定默認值，禁止null值，以防破壞索引，影響查詢效率，
-
不在where陳述句后使用函式或者運算式計算，會造成索引失效，
-
不使用NOT IN和<>操作，%開頭的模糊查詢，避免全表掃描；
-
避免使用屬性隱式轉換，如phone='123456789’為字串不寫成phone=123456789，
-
盡量建立覆寫索引，避免回表查詢，
-
唯一/普通索引的選擇，唯一索引需要唯一性檢查，不能利用 change buffer特性，需要頻繁從磁盤讀取資料，涉及隨機 IO 的訪問，效率變低，所以能使用普通索引的場景盡量不使用唯一索引，
-
更新條件列要使用索引，避免無法通過索引鍵加鎖而升級為表級鎖，
-
varchar欄位過長時考慮使用前綴索引，
-
禁止對大型表使用JOIN查詢或子查詢，會生成臨時表，消耗記憶體和CPU，極大地影響資料庫性能，關聯查詢可在業務代碼層拆分為多次單表查詢，
-
避免存盤大檔案，大檔案可存至專門的檔案系統，如OSS，
-
根據業務需要合理地確定欄位型別與長度，避免空間浪費，
-
大事務盡量拆成多個小事務，減少鎖記錄和時間，
-
最長事務代碼塊盡量放在程式的最后執行，
-
盡量減少基于范圍的資料檢索過濾條件更新，避免間隙鎖帶來的影響而鎖定了不該鎖定的記錄，
-
注意間隙鎖，批量更新&洗掉操作盡量避免并發，以免造成意外的死鎖，
-
資料量大的業務系統，考慮分庫分表，按業務系統的劃分垂直分庫，單表資料量過大考慮分表（水平/垂直分表）
需要IT學習資料的同學，可以關注VX公眾號【八戒程式猿】，獲取更多教程，學無止境，愿大家都能夠少走彎路，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/239654.html
標籤：其他
下一篇：Seata集成實戰