關於MySQL優化的幾點總結

page_img_url

前言

現如今,數據庫的操作越來越成爲整個應用的性能瓶頸了,這點對於Web應用尤其明顯。所以,我整理了MySQL優化的幾點建議,希望這些優化技巧對您有用,總結不到的,歡迎大家補充。

SQL執行慢的原因

  1. 網絡速度慢,內存不足,I/O吞吐量小,磁盤空間滿了等硬件問題
  2. 沒有索引或者索引失效
  3. 數據表裏的數據記錄過多
  4. 服務器調優及各個參數設置也可能會影響
  5. 開發者編寫的SQL效率
  6. 其他

1、EXPLAIN分析你的SELECT查詢

很多情況下,使用EXPLAIN關鍵字可以讓你知道MySQL是如何處理你的SQL語句的,這可以幫你分析你的查詢語句,從而或許能儘快的找到優化方法以及潛在的性能問題。具體EXPLAIN的使用以及各個參數的含義,請查閱相關文檔即可。

2、SELECT查詢必須指明字段名

SELECT * 的查詢會加很多不必要的消耗(例如CPU、I/O等),同時,也有可能增加了使用覆蓋索引。所以SELECT查詢時,要求直接在後面指明需要查詢的對應字段名。

3、查詢一條數據的時候,使用 LIMIT 1

減少多餘的查詢,因爲指定limit 1後,查詢到一條數據就不再繼續查詢了,使得EXPLAIN中type列達到const類型,查詢語句更優。

4、爲搜索的WHERE字段建立索引

一般,每個表我們都會設置一個主鍵,而索引並不一定就是給主鍵。如果在你的表中,有某個字段你總要會經常用來做WHERE查詢搜索,而且是讀大於寫的,那麼,請爲其建立索引吧,有興趣瞭解更多建立索引的的原則,可以查閱相關資料。

5、千萬不要使用 ORDER BY RAND()

如果你想隨機取數據,也許第一個直接會告訴你,用隨機數取,切記,這個時候你必須控制你的大腦在這個方向繼續想下去,趕緊停止這種可怕的想法。因爲這種查詢,對數據庫的性能毫無益處(消耗CPU)。更好的方案之一是先找到數據所在的條數N,然後再用LIMIT N, 1這樣查詢。

6、保證每張表都有一個主鍵ID

我們應該養成一種習慣,每設計新建一張表的時候,都應該爲其設計一個ID字段,並讓其成爲主鍵,而且最好是INT型(也有使用UUID的),同時設置這個ID字段爲自增(AUTO_INCREMENT)的標誌。

8、儘可能的使用 NOT NULL

不要以爲NULL不需要空間,事實是NULL也需要額外的空間,也許,很多有沒注意但是遇到過,NULL字段在進行查詢比較的時候,是比較麻煩的。當然了,如果你實在是必須需要NULL的話,那沒轍,就使用吧,否則的話,就建議使用NOT NULL吧。

8、選擇合適的存儲引擎

在MySQL中有MyISAM和InnoDB兩種存儲引擎,兩者各有利弊,所以我們需要了解兩者的差異然後來做出最合適的選擇,例如InnoDB支持事務而MyISAM不支持,MyISAM查詢比InnoDB快等等;總之,如果你不知道選擇什麼的話,那就用InnoDB吧。

9、把IP地址存爲UNSIGNED INT

在遇到需要存儲IP地址的時候,很多人的第一想法都會是存儲VARCHAR(15)字符串類型的,而不會想到要用INT整型來存儲;如果你用整型來存儲,只需要4個字節,並且你可以有定長的字段,而且這會爲你帶來查詢上的優勢。

10、儘量不要在WHERE查詢時對字段進行null值判斷

我們都知道,檔我們對一個字段進行null的判斷時候,會比較慢的,這是因爲這個判斷會導致引擎放棄使用所有已有的索引而進行全表掃描搜索。

11、儘量不要使用%前綴的LIKE模糊查詢

模糊查詢,在日常開發中,我們都會經常遇到,但是我相信很多人都是直接 LIKE '%key_word%' 或者 LIKE '%key_word' 這樣搜索的,這兩種搜索方式,都會導致索引失效從而進行全表掃描搜索。如果解決上面的這種模糊查詢呢,答案就是使用“使用全文索引”,具體的用法有興趣的可以自己查資料一波。

12、避免在WHERE查詢時對字段進行表達式操作

例如查詢語句SELECT id FROM table WHERE num * 2 = 50;,這樣的查詢,對字段num做了一個乘2的算數操作,就會導致索引失效。

14、減少不必要的排序

排序操作會消耗較多的CPU資源,所以減少不必要的排序可以在緩存命中率高等I/O足夠的情況下,會降低SQL的響應時間。

14、建議用JOIN代替子查詢

有的人會說,JOIN的性能其實也並不是很好呀,但是和子查詢比起來還是有很大的性能優勢的。具體的,可以瞭解一下子查詢的執行計劃相關的問題。

15、避免發生隱式類型轉換

類型轉換主要是指在WHERE子句中出現字段的類型和傳入的參數類型不一致的時候發生的類型轉換;這是因爲如果我們傳入的數據類型和字段類型不一致,MySQL可能會對我們傳的數據進行類型轉換操作,也可能不進行處理而直接交由存儲引擎去處理,這樣一來,就可能會出現索引無法使用的情況而造成執行計劃問題。

16、避免多表查詢字段類型不一致

在遇到需要多表聯合查詢的時候,我們設計表結構的時候,儘量保持表與表的關聯字段一致,並且都要設置索引。同時,多表連接查詢時,儘量把結果集小的表作爲驅動表。

17、建議開啓查詢緩存

大多數的MySQL服務器都開啓了查詢緩存,這是提高性能最有效的方法之一,因爲查詢緩存由MySQL數據庫引擎自動處理,當有很多相同的查詢被執行了多次的時候,這些查詢結果會被放到一個緩存中,這樣,後續的相同的查詢就不用操作表,而直接訪問緩存結果了。

18、使用UNION代替臨時表

UNION查詢可以把兩條或更多的SELECT查詢結果合併到一個查詢中,從而不再需要創建臨時表來完成。需要注意的是,使用UNION的所有SELECT語句中的字段數目要相同。

19、慎用IN查詢

IN以及NOT IN查詢都要慎重,因爲可能會導致全表掃描,而對於連續的數值,能用BETWEEN就不要用IN了。

20、歡迎補充

結束語

這主要是從查詢角度去考慮優化,還有一些分表、分區技術以及讀寫分離等;以上優化之處,如果說的不到位的地方,請大家諒解,MySQL優化的地方可以有很多處,歡迎提出其他優化建議,謝謝。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章