網絡速度慢,內存不足,I/O吞吐量小,磁盤空間滿了等硬件問題數據庫
沒有索引或者索引失效緩存
數據表裏的數據記錄過多服務器
服務器調優及各個參數設置也可能會影響網絡
開發者編寫的SQL效率性能
其餘優化
不少狀況下,使用EXPLAIN關鍵字可讓你知道MySQL是如何處理你的SQL語句的,這能夠幫你分析你的查詢語句,從而或許能儘快的找到優化方法以及潛在的性能問題。具體EXPLAIN的使用以及各個參數的含義,請查閱相關文檔便可。spa
SELECT * 的查詢會加不少沒必要要的消耗(例如CPU、I/O等),同時,也有可能增長了使用覆蓋索引。因此SELECT查詢時,要求直接在後面指明須要查詢的對應字段名。設計
減小多餘的查詢,由於指定limit 1後,查詢到一條數據就再也不繼續查詢了,使得EXPLAIN中type列達到const類型,查詢語句更優。code
通常,每一個表咱們都會設置一個主鍵,而索引並不必定就是給主鍵。若是在你的表中,有某個字段你總要會常常用來作WHERE查詢搜索,並且是讀大於寫的,那麼,請爲其創建索引吧,有興趣瞭解更多創建索引的的原則,能夠查閱相關資料。排序
若是你想隨機取數據,也許第一個直接會告訴你,用隨機數取,切記,這個時候你必須控制你的大腦在這個方向繼續想下去,趕忙中止這種可怕的想法。由於這種查詢,對數據庫的性能毫無益處(消耗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優化的地方能夠有不少處,歡迎提出其餘優化建議,謝謝。