做大流量訪問級別的web應用開發的項目的時候，我們不得不經常要對應用中的各項功能不斷的進行檢測，優化以防止應用在關鍵時刻掛掉。下面作者就如何定位，排除以及避免MySQL數據庫性能問題上面發表一些看法。期望能夠幫助到同行們能夠打造更堅固，更穩定的web應用。
（1）設計表時盡量使用 innodb數據庫引擎
建表時,顯式指定使用innodb數據庫引擎，而不是myisam引擎，myisam引擎的鎖是表鎖,讀鎖和寫鎖是互斥的，讀寫操作是串行的，鎖沖突會嚴重影響並發.而innodb提供行級鎖，能提供較好的並發表現，在我們的業務場景裡，也不會引起死鎖。
（2）善用數據庫索引
對SQL語句中where條件裡使用到的字段，合理建立索引。雖然對表建立索引一定程度上會影響寫入效率，但在表數據規模不大，寫入壓力不是特別高的情況下，索引帶來的好處是更多的。
（3）合理的分庫分表
對數據應合理分庫分表，由應用層去動態的選擇庫和表。MySQL 的 innodb 引擎表雖然理論上可以存儲海量的數據，但在我們的業務場景下，數據控制在500w以下會比較合理，追求性能的話，最好控制在200w以下，合理索引。
（4）合理使用緩存
將不常修改的，數據量有限的,又是被密集查詢的信息，加載到 cache 裡，可以有效的降低數據庫壓力。在一般的業務場景裡，推薦使用開源 memcache，簡單而且高效。
（5）善用 explain 命令
項目開發完後，應經常使用 explain 命令檢查SQL語句，看是否使用到索引，是否存在 filesort 問題（即沒有將 order by 列 設置為索引）,以及檢查數據檢索的行數（rows）是否太大。一般情況下，rows<1000，是在可接受的范圍內的。rows在1000~1w之間，在密集並發訪問的情況下可能會導致性能問題，但如果不是太頻繁的訪問（頻率低於1分鐘一 次），又難再優化的話，可以接受，但需要注意觀察rows大於1萬時，應慎重考慮SQL的設計，優化SQL，優化db，一般來說不允許頻繁運行（頻率低於1小時一次）。rows達到10w級別時，堅決不能做為實時運行的SQL。但導數據場合除外，但導數據必須控制好時間， 頻度。
explain SQL語句應該是日常開發中的習慣動作，有時explain出來的結果，可能會出於偏離設計的意料之外,所以強烈建議在設計SQL語句時，尤其是稍微復雜的SQL時，一定要在測試環境甚至是實際環境上預先進行 explain 檢測。
（6）開啟 MySQL 慢查詢日志
一般應打開MySQL的慢查詢日志(在my.cnf中加入log_slow_queries和long_query_time兩個參數),會記錄所有查詢持續時間超過long_query_time的SQL語句，把這些語句log下來之後，再一一運行 explain 命令進行分析優化。
（7）監視MySQL數據庫進程列表
登陸MySQL客戶端,使用show processlist查看當前正在運行的SQL語句，如果正在運行的語句太多，且運行時間太長的話，表示MySQL效率有問題。必要的時候可以將對應的進程kill掉。
（8）監視MySQL所占用的系統進程
使用 top，vmstat 等系統命令來檢查MySQL進程占用的cpu,內存,以及磁盤IO量來對數據庫進行進一步優化。
