2、sql寫法過於復雜
sql寫法假如用到一些特殊的功能，比如groupby、或者多表聯合查詢的話，MySQL用到什麼方式來查詢也可以用desc來分析，我這邊用復雜sql的情況還不算多，所以不常分析，暫時就沒有好的建議。
3、配置錯誤
配置裡主要參數是key_buffer、sort_buffer_size/myisam_sort_buffer_size，這兩個參數意思是：
key_buffer=128m：全部表的索引都會盡可能放在這塊內存區域內，索引比較大的話就開稍大點都可以，我一般設為128m，有個好的建議是把很少用到並且比較大的表想辦法移到別的地方去，這樣可以顯著減少MySQL的內存占用。
sort_buffer_size=1m：單個線程使用的用於排序的內存，查詢結果集都會放進這內存裡，如果比較小，MySQL會多放幾次，所以稍微開大一點就可以了，重要是優化好索引和查詢語句，讓他們不要生成太大的結果集。
另外一些配置：
thread_concurrency=8：這個配置標配=cpu數量x2
interactive_timeout=30
wait_timeout=30：這兩個配置使用10-30秒就可以了，這樣會盡快地釋放內存資源，注意：一直在使用的連接是不會斷掉的，這個配置只是斷掉了長時間不動的連接。
query_cache：這個功能不要使用，現在很多人看到cache這幾個字母就像看到了寶貝，這是不唯物主義的。MySQL的query_cache在每次表數據有變化的時候都會重新清理連至該表的所有緩存，如果更新比較頻繁，query_cache不但幫不上忙，而且還會對效率影響很大。這個參數只適合只讀型的數據庫，如果非要用，也只能用query_cache_type=2自行用sql_cache指定一些sql進行緩存。
max_connections：默認為100，一般情況下是足夠用的，但是一般要開大一點，開到400-600就可以了，能超過600的話一般就有效率問題，得另找對策，光靠增加這個數字不是辦法。
其它配置可以按默認就可以了，個人覺得問題還不是那麼的大，提醒一下：1、配置雖然很重要，但是在絕大部分情況下都不是效率問題的罪魁禍首。2、MySQL是一個數據庫，對於數據庫最重要考究的不應是效率，而是穩定性和數據准確性。
4、機器實在負荷不了
如果做了以上調整，服務器還是不能承受，那就只能通過架構級調整來優化了。
1、MySQL同步。
通過MySQL同步功能將數據同步到數台從數據庫，由主數據庫寫入，從數據庫提供讀取。
我個人不是那麼樂意使用MySQL同步，因為這個辦法會增加程序的復雜性，並常常會引起數據方面的錯誤。在高負荷的服務中，死機了還可以快速重啟，但數據錯誤的話要恢復就比較麻煩。
2、加入緩存
加入緩存之後，就可以解決並發的問題，效果很明顯。如果是實時系統，可以考慮用刷新緩存方式使緩存保持最新。
在前端加入squid的架構比較提倡使用，在命中率比較高的應用中，基本上可以解決問題。
如果是在程序邏輯層裡面進行緩存，會增加很多復雜性，問題會比較多而且難解決，不建議在這一層面進行調整。
3、程序架構調整，支持同時連接多個數據庫
如果web加入緩存後問題還是比較嚴重，只能通過程序架構調整，把應用拆散，用多台的機器同時提供服務。
如果拆散的話，對業務是有少許影響，如果業務當中有部分功能必須使用所有的數據，可以用一個完整庫+n個分散庫這樣的架構，每次修改都在完整庫和分散庫各操作一次，或定期整理完整庫。
當然，還有一種最笨的，把數據庫整個完完整整的做拷貝，然後程序每次都把完整的sql在這些庫執行一遍，訪問時輪詢訪問，我認為這樣要比MySQL同步的方式安全。
