?

大表數據查詢

主從復制 讀寫分離 垂直拆分 水平切分

?

?

數據庫設計和查詢原則:

盡量設定主鍵

推薦使用自增ID，不要使用UUID

字段定義為not null而不是null

密碼散列，鹽，用戶身份證號等固定長度的字符串應該使用char而不是varchar來存儲，這樣可以節省空間且提高檢索效率。

避免犯如下SQL語句錯誤

查詢不需要的數據。解決辦法：使用limit解決

多表關聯返回全部列。解決辦法：指定列名

總是返回全部列。解決辦法：避免使用SELECT *

重復查詢相同的數據。解決辦法：可以緩存數據，下次直接讀取緩存

是否在掃描額外的記錄。解決辦法：

使用explain進行分析，如果發現查詢需要掃描大量的數據，但只返回少數的行，可以通過如下技巧去優化：

使用索引覆蓋掃描，把所有的列都放到索引中，這樣存儲引擎不需要回表獲取對應行就可以返回結果。

改變數據庫和表的結構，修改數據表范式

?優化長難的查詢語句

一次性刪除1000萬的數據要比一次刪除1萬，暫停一會的方案更加損耗服務器開銷。

分解關聯查詢，讓緩存的效率更高。

執行單個查詢可以減少鎖的競爭。

count(*)會忽略所有的列，直接統計所有列數，不要使用count(列名)

MyISAM中，沒有任何where條件的count(*)非常快。

當有where條件時，MyISAM的count統計不一定比其它引擎快。

確定ON或者USING子句中是否有索引。

確保GROUP BY和ORDER BY只有一個表中的列，這樣MySQL才有可能使用索引。

優化GROUP BY和DISTINCT

這兩種查詢據可以使用索引來優化，是最有效的優化方法

如果不需要ORDER BY，進行GROUP BY時加ORDER BY NULL，MySQL不會再進行文件排序。

LIMIT偏移量大的時候，查詢效率較低

可以記錄上次查詢的最大ID，下次查詢時直接根據該ID來查詢

UNION ALL的效率高于UNION

?

應盡量避免在 where 子句中使用!=或<>操作符，否則引擎將放棄使用索引而進行全表掃描。

應盡量避免在 where 子句中使用or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：

select id from t where num=10 or num=20

-- 可以這樣查詢：

select id from t where num=10 union all select id from t where num=20

?

in?和 not in 也要慎用，否則會導致全表掃描，如：

select id from t where num in(1,2,3)

-- 對于連續的數值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

?

下面的查詢也將導致全表掃描：select id from t where name like ‘%李%’若要提高效率，可以考慮全文檢索。

如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變量，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然 而，如果在編譯時建立訪問計劃，變量的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：

select id from t where num=@num

-- 可以改為強制查詢使用索引：

select id from t with(index(索引名)) where num=@num

?

應盡量避免在 where 子句中對字段進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：

select id from t where num/2=100

-- 應改為:

select id from t where num=100*2

?

應盡量避免在where子句中對字段進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：

select id from t where substring(name,1,3)=’abc’

-- name以abc開頭的id應改為:

select id from t where name like ‘abc%’

?

不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。

?

?

沒有掌握的部分:

范式是什么意思？

超大分頁優化

?

explain就是在執行sql語句前面加個explain,mysql執行的時候會出一個"執行分析"

?

慢查詢的優化首先要搞明白慢的原因是什么？是查詢條件沒有命中索引？是load了不需要的數據列？還是數據量太大？

Reference:

[1]MySQL面試題-SQL優化

總結

以上是生活随笔為你收集整理的mysql优化积累(持续更新中)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。