網路速度慢，記憶體不足，i/o吞吐量小，磁碟空間滿了等硬體問題
沒有索引或者索引失效
資料表裡的資料記錄過多
伺服器調優及各個引數設定也可能會影響
開發者編寫的sql效率
其他很多情況下，使用explain關鍵字可以讓你知道mysql是如何處理你的sql語句的，這可以幫你分析你的查詢語句，從而或許能盡快的找到優化方法以及潛在的效能問題。具體explain的使用以及各個引數的含義，請查閱相關文件即可。
select * 的查詢會加很多不必要的消耗（例如cpu、i/o等），同時，也有可能增加了使用覆蓋索引。所以select查詢時，要求直接在後面指明需要查詢的對應欄位名。
減少多餘的查詢，因為指定limit 1後，查詢到一條資料就不再繼續查詢了，使得explain中type列達到const型別，查詢語句更優。
如果你想隨機取資料，也許第乙個直接會告訴你，用隨機數取，切記，這個時候你必須控制你的大腦在這個方向繼續想下去，趕緊停止這種可怕的想法。因為這種查詢，對資料庫的效能毫無益處（消耗cpu）。更好的方案之一是先找到資料所在的條數n，然後再用limit n, 1這樣查詢。
我們應該養成一種習慣，每設計新建一張表的時候，都應該為其設計乙個id欄位，並讓其成為主鍵，而且最好是int型（也有使用uuid的），同時設定這個id欄位為自增（auto_increment）的標誌。
不要以為null不需要空間，事實是null也需要額外的空間，也許，很多有沒注意但是遇到過，null欄位在進行查詢比較的時候，是比較麻煩的。當然了，如果你實在是必須需要null的話，那沒轍，就使用吧，否則的話，就建議使用not null吧。
在mysql中有myisam和innodb兩種儲存引擎，兩者各有利弊，所以我們需要了解兩者的差異然後來做出最合適的選擇，例如innodb支援事務而myisam不支援，myisam查詢比innodb快等等；總之，如果你不知道選擇什麼的話，那就用innodb吧。
在遇到需要儲存ip位址的時候，很多人的第一想法都會是儲存varchar(15)字串型別的，而不會想到要用int整型來儲存；如果你用整型來儲存，只需要4個位元組，並且你可以有定長的字段，而且這會為你帶來查詢上的優勢。
我們都知道，檔我們對乙個字段進行null的判斷時候，會比較慢的，這是因為這個判斷會導致引擎放棄使用所有已有的索引而進行全表掃瞄搜尋。
模糊查詢，在日常開發中，我們都會經常遇到，但是我相信很多人都是直接like '%key_word%'或者like '%key_word'這樣搜尋的，這兩種搜尋方式，都會導致索引失效從而進行全表掃瞄搜尋。如果解決上面的這種模糊查詢呢，答案就是使用「使用全文索引」，具體的用法有興趣的可以自己查資料一波。
例如查詢語句select id from table where num * 2 = 50;，這樣的查詢，對欄位num做了乙個乘2的算數操作，就會導致索引失效。
排序操作會消耗較多的cpu資源，所以減少不必要的排序可以在快取命中率高等i/o足夠的情況下，會降低sql的響應時間。
有的人會說，join的效能其實也並不是很好呀，但是和子查詢比起來還是有很大的效能優勢的。具體的，可以了解一下子查詢的執行計畫相關的問題。
型別轉換主要是指在where子句**現字段的型別和傳入的引數型別不一致的時候發生的型別轉換；這是因為如果我們傳入的資料型別和字段型別不一致，mysql可能會對我們傳的資料進行型別轉換操作，也可能不進行處理而直接交由儲存引擎去處理，這樣一來，就可能會出現索引無法使用的情況而造成執行計畫問題。
在遇到需要多表聯合查詢的時候，我們設計表結構的時候，盡量保持表與表的關聯字段一致，並且都要設定索引。同時，多表連線查詢時，盡量把結果集小的表作為驅動表。
大多數的mysql伺服器都開啟了查詢快取，這是提高效能最有效的方法之一，因為查詢快取由mysql資料庫引擎自動處理，當有很多相同的查詢被執行了多次的時候，這些查詢結果會被放到乙個快取中，這樣，後續的相同的查詢就不用操作表，而直接訪問快取結果了。
union查詢可以把兩條或更多的select查詢結果合併到乙個查詢中，從而不再需要建立臨時表來完成。需要注意的是，使用union的所有select語句中的字段數目要相同。
in以及not in查詢都要慎重，因為可能會導致全表掃瞄，而對於連續的數值，能用between就不要用in了。
關於MySQL優化的幾點總結
sql執行慢的原因 網路速度慢，記憶體不足，i o吞吐量小，磁碟空間滿了等硬體問題 沒有索引或者索引失效 資料表裡的資料記錄過多 伺服器調優及各個引數設定也可能會影響 開發者編寫的sql效率 其他 1 explain分析你的select查詢 很多情況下，使用explain關鍵字可以讓你知道mysql...
Mysql優化的幾點總結
正常情況下，初創公司的流量並不是很大，mysql資料庫在未做優化的情況依然可以滿足效能要求，特別是5.6版本後mysql在效能上還是有了很大提公升，所以在初期並沒有花精力在此上面。但後來發生的一系列問題還是說明mysql效能優化在專案啟動時就應該重視起來。下面就出現問題的原因和需要注意的地方說明如下...
關於Oralce資料庫優化的幾點總結
個人理解，資料庫效能最關鍵的因素在於io，因為操作記憶體是快速的，但是讀寫磁碟是速度很慢的，優化資料庫最關鍵的問題在於減少磁碟的io，就個人理解應該分為物理的和邏輯的優化，物理的是指oracle產品本身的一些優化，邏輯優化是指應用程式級別的優化物理優化的一些原則 1 oracle的執行環境 網路，硬...