mysql 資料庫是被廣泛應用的關係型資料庫，其體積小、支援多處理器、開源並免費的特性使其在 internet 中小型**中的使用率尤其高。在使用 mysql的過程中不規範的 sql 編寫、非最優的策略選擇都可能導致系統效能甚至功能上的缺陷。
恰巧就在前幾天，本人所在公司的雲事業部舉辦了一場關於 mysql 的技術交流會，其中乙個 part 正是聚焦於開發過程中 mysql 資料庫設計及使用的常見問題，並提出相關優化方案。根據會議內容並查閱相關資料，本人對這個 part 進行了一次小結，結合自己的工作經歷及理解形成此文以供分享，希望能有助於各位同行解決工作中的相關問題。
一、庫表設計
1、引擎選擇
在 mysql 5.1 中，引入了新的外掛程式式儲存引擎體系結構，允許將儲存引擎載入到正在運新的 mysql 伺服器中。使用 mysql 外掛程式式儲存引擎體系結構，允許資料庫專業人員或者設計庫表的軟體開發人員為特定的應用需求選擇專門的儲存引擎，完全不需要管理任何特殊的應用編碼要求，也無需考慮所有的底層實施細節。因此，儘管不同的儲存引擎具有不同的能力，應用程式是與之分離的。此外，使用者可以在伺服器、資料庫和**三個層級中儲存引擎，提供了極大的靈活性。
mysql 常用的儲存引擎包括 myisam、innodb 和 memory，其中各自的特點如下：
1）myisam: 全表鎖，擁有較高的執行速度，乙個寫請求請阻塞另外相同**的所有讀寫請求，併發效能差，占用空間相對較小，mysql 5.5 及以下僅 myisam 支援全文索引，不支援事務。
2）innodb：行級鎖（sql 都走索引查詢），併發能力相對強，占用空間是 myisam 的 2.5 倍，不支援全文索引（5.6 開始支援），支援事務。
3）memory: 全表鎖，儲存在記憶體當中，速度快，但會占用和資料量成正比的記憶體空間且資料在 mysql 重啟時會丟失。
基於以上特性，建議絕大部份都設定為 innodb 引擎，特殊的業務再考慮選用 myisam 或 memory ，如全文索引支援或極高的執行效率等。2、分表方法
在資料庫表使用過程中，為了減小資料庫伺服器的負擔、縮短查詢時間，常常會考慮做分表設計。分表分兩種，一種是縱向分表（將本來可以在同乙個表的內容，人為劃分儲存在為多個不同結構的表）和橫向分表（把大的表結構，橫向切割為同樣結構的不同表）。
其中，縱向分表常見的方式有根據活躍度分表、根據重要性分表等。其主要解決問題如下：
1）表與表之間資源爭用問題；
2）鎖爭用機率小；
3）實現核心與非核心的分級儲存，如udb登陸庫拆分成一級二級**庫；
4）解決了資料庫同步壓力問題。
橫向分表是指根據某些特定的規則來劃分大資料量表，如根據時間分表。其主要解決問題如下：
1）單錶過大造成的效能問題；
2）單錶過大造成的單伺服器空間問題。
3、索引問題
索引是對資料庫表中乙個或多個列的值進行排序的結構，建立索引有助於更快地獲取資訊。 mysql 有四種不同的索引型別：
1）主鍵索引 ( primary )
2）唯一索引 ( unique )
3）普通索引 ( index )
4）全文索引（fulltext , myisam 及 mysql 5.6 以上的 innodb ）
建立索引的目的是加快對錶中記錄的查詢或排序，索引也並非越多越好，因為建立索引是要付出代價的：一是增加了資料庫的儲存空間，二是在插入和修改資料時要花費較多的時間維護索引。
在設計表或索引時，常出現以下幾個問題：
1）少建索引或不建索引。這個問題最突出，建議建表時 dba 可以一起協助把關。
2）索引濫用。濫用索引將導致寫請求變慢，拖慢整體資料庫的響應速度（5.5 以下的 mysql 只能用到乙個索引)。
3）從不考慮聯合索引。實際上聯合索引的效率往往要比單列索引的效率更高。
4）非最優列選擇。低選擇性的字段不適合建單列索引，如 status 型別的字段。
二、慢 sql 問題
1、導致慢 sql 的原因
在遇到慢 sql 情況時，不能簡單的把原因歸結為 sql 編寫問題(雖然這是最常見的因素)，實際上導致慢 sql 有很多因素，甚至包括硬體和 mysql 本身的 bug。根據出現的概率從大到小，羅列如下：
1）sql編寫問題
2）鎖3）業務例項相互幹繞對 io/cpu 資源爭用
4）伺服器硬體
5）mysql bug
2、由 sql 編寫導致的慢 sql 優化
針對sql編寫導致的慢 sql，優化起來還是相對比較方便的。正如上一節提到的正確的使用索引能加快查詢速度，那麼我們在編寫 sql 時就需要注意與索引相關的規則：
1）字段型別轉換導致不用索引，如字串型別的不用引號，數字型別的用引號等，這有可能會用不到索引導致全表掃瞄；
2）mysql 不支援函式轉換，所以字段前面不能加函式，否則這將用不到索引；
3）不要在字段前面加減運算；
4）字串比較長的可以考慮索引一部份減少索引檔案大小，提高寫入效率；
5）like % 在前面用不到索引；
6）根據聯合索引的第二個及以後的字段單獨查詢用不到索引；
7）不要使用 select *；
8）排序請盡量使用公升序 ;
9）or 的查詢盡量用 union 代替 （innodb）；
10）復合索引高選擇性的字段排在前面；
11）order by / group by 字段包括在索引當中減少排序，效率會更高。
除了上述索引使用規則外，sql 編寫時還需要特別注意以下幾點：
1）盡量規避大事務的 sql，大事務的 sql 會影響資料庫的併發效能及主從同步；
2）分頁語句 limit 的問題；
3）刪除表所有記錄請用 truncate，不要用 delete；
4）不讓 mysql 幹多餘的事情，如計算；
5）輸寫 sql 帶欄位，以防止後面表變更帶來的問題，效能也是比較優的 ( 涉及到資料字典解析，請自行查詢資料)；
6）在 innodb上用 select count(*)，因為 innodb 會儲存統計資訊；
7）慎用 oder by rand()。
三、分析診斷工具
在日常開發工作中，我們可以做一些工作達到預防慢 sql 問題，比如在上線前預先用診斷工具對 sql 進行分析。常用的工具有：
1、mysqldumpslow
2、mysql profile
3、mysql explain
具體使用及分析方法在此就不贅述，網上有豐富的資源可以參考。
四、誤操作、程式 bug 時怎麼辦
提出這個問題顯然主要是針對剛開始工作的年輕同行們……實際上誤操作和程式 bug 導致資料誤刪或者混亂的問題並非少見，但是剛入行的開發工作者會比較緊張。乙個成熟的企業往往會有完善的資料管理規範和較豐富的資料恢復方案（初創公司除外），會進行資料備份和資料容災。
當你發現誤操作或程式 bug 導致線上資料被誤刪或誤改動時，一定不能慌亂，應及時與 dba 聯絡，第一時間進行資料恢復（嚴重時直接停止服務），盡可能減少影響和損失。對於重要資料（如資金）的操作，在開發時一定要反覆進行測試，確保沒有問題後再上線。
為什麼MySQL使用B 樹？
首先需要理解磁碟io的原理 硬碟中一般會有多個碟片組成，每個碟片包含兩個面，每個盤面都對應地有乙個讀 寫磁頭。將磁軌劃分為若干個弧段，每個磁軌上乙個弧段被稱之為乙個扇區 圖踐綠色部分 扇區是磁碟的最小組成單元。硬碟通常由重疊的一組碟片構成，每個盤面都被劃分為數目相等的磁軌，並從外緣的 0 開始編號，...
聯想x250為什麼這麼貴 國產奶粉為什麼這麼貴
近期看到了 國產奶粉為什麼這麼貴 這個話題，目前國內奶粉品牌主要有君樂寶 聖元 伊利 貝因奶 雅士利 飛鶴，而 為什麼這麼貴，我覺得原因有很多，但主要還是下面這幾個方面吧 國產奶粉為什麼這麼貴 一 成本 這裡所說的成本並不是只有奶粉的生產原料成本，奶粉的生產原料成本也就在幾十塊錢左右。但是，從奶粉的...
python基礎裡的那些為什麼？
好，我們就以輸出hello world這個例子來比較兩種方式的不同 第一種方式 直譯器裡執行 第二種方式 檔案執行 有圖有真相，見下圖 實現使用者輸入使用者名稱和密碼，當使用者名為seven且密碼為123時，顯示登陸成功，否則登陸失敗 username input 請輸入使用者名稱 passward...