正常情況下，初創公司的流量並不是很大，mysql資料庫在未做優化的情況依然可以滿足效能要求，特別是5.6版本後mysql在效能上還是有了很大提公升，所以在初期並沒有花精力在此上面。但後來發生的一系列問題還是說明mysql效能優化在專案啟動時就應該重視起來。下面就出現問題的原因和需要注意的地方說明如下：
開發人員之前多數使用oracle，由於oracle強大的效能和所做專案多是內部企業應用，不太可能出現效能問題。在這樣的背景下，開發人員依然按照原來的方式來寫**，導致後來效能問題，總結有以下幾點：
1.sql多表聯合查詢，常常是3，4張表聯合查詢
2.sql中使用大量函式
3.sql中直接select *
4.表字段缺少索引或者索引方式不對
5.表設計考慮不周，出現大量空欄位
6.表主鍵設計成uuid，由於使用傳統機械硬碟，對定址非常不利
7.過多使用觸發器
8.sql中存在複雜計算
首先通過慢日誌過濾出大於1s的sql語句，解決mysql效能問題，一定要利用好慢日誌。然後通過執行計畫（explain）來檢視sql的執**況。具體優化措施如下：
如果此sql是聯合查詢，首先確認是否是可以拆分成單錶查詢，然後通過程式來進行處理資料。最多不能超過兩表聯合查詢。
通過執行計畫，對全表掃瞄的查詢一定要建立索引，在建立索引時，一定要考慮到此字段是否有大量空欄位，字段值是否大量重複，可區分度是否高，不然建立索引的意義不大，反而是影響insert 和 delete操作。對於長字元型別的字段，增加算因時，需要增加字首，計算方式為：select count(distinct left(b,5)) /count(distinct b) as left5,count(distinct left(b,6))/count(distinct b) as left6 from test_unique
limit 1，其中5，6是預估值，對於uuid這樣長字元型別，一般字首是6.增加索引時sql語句為：alter table test.test_unique add key (left(6));。 對於不能重複的字段，建議使用唯一索引，一是保證插入值唯一，二是提高查詢速度 。 在where、order 、group by後面的字段，盡量建立索引，通過需要注意的是如果where後面是多字段，那麼需要建立聯合索引，而不是單個建立索引，並且需要注意聯合索引的順序，例如where a='x' and b = 'y'，在其它sql中出現where
b=『z』這樣的情況，那麼聯合索引順序為（b,a），而不是單獨建立（a,b）和（b）兩個索引，因為在建立聯合索引（b,a）時，mysql會建立兩個索引(b)，（b,a）兩個索引。
在字段上使用函式將會使索引失效，因此一定要避免在左側字段使用函式，而是提前在程式裡處理好。
mysql提供了大量的函式，但對於這些函式，盡量不要用，而是在程式裡進行處理，目前mysql對於這些函式優化工作做的並不是很好，往往有時候會導致嚴重的效能問題。
表主鍵盡量採用自增序列，這樣可以充分mysql的儲存特性，mysql採用b+樹儲存。需要注意的地方在於：如果是分庫分表，那麼需要不能直接使用自增序列，需要採用其他方法來完成，常用的方式通過redis來維護一套id。
關於MySQL優化的幾點總結
網路速度慢，記憶體不足，i o吞吐量小，磁碟空間滿了等硬體問題 沒有索引或者索引失效 資料表裡的資料記錄過多 伺服器調優及各個引數設定也可能會影響 開發者編寫的sql效率 其他很多情況下，使用explain關鍵字可以讓你知道mysql是如何處理你的sql語句的，這可以幫你分析你的查詢語句，從而或許能...
關於MySQL優化的幾點總結
sql執行慢的原因 網路速度慢，記憶體不足，i o吞吐量小，磁碟空間滿了等硬體問題 沒有索引或者索引失效 資料表裡的資料記錄過多 伺服器調優及各個引數設定也可能會影響 開發者編寫的sql效率 其他 1 explain分析你的select查詢 很多情況下，使用explain關鍵字可以讓你知道mysql...
MySQL優化的幾點建議
設計資料表的時候要遵守三正規化，但是不要嚴格遵守。可以適度打破正規化。乙個表字段不適合過多。常用表中只要保留常用的字段 盡量給每個字段新增not null 根據表的特點來選擇合適的表引擎，如果這個表經常被寫，應該選擇innodb,但是mysql5.6一般都是選擇innodb 根據表存放的資料來決定字...