SQL優化與診斷
Explain診斷
Explain各參數的含義如下:
列名 | 說明 |
---|---|
id | 執行編號,標識select所屬的行。如果在語句中沒有子查詢或關聯查詢,只有唯一的select,每行都將顯示1.否則,內層的select語句一般會順序編號,對應於其在原始語句中的位置 |
select_type | 顯示本行是簡單或復雜select,如果查詢有任何復雜的子查詢,則最外層標記為PRIMARY(DERIVED、UNION、UNION RESUIT) |
table | 訪問引用哪個表(引用某個查詢,如“derived3”) |
type | 數據訪問/讀取操作類型(All、index、range、ref、eq_ref、const/system、NULL) |
possible_key | 揭示哪一些索引可能有利於高效的查找 |
key | 顯示mysql實際決定采用哪個索引來優化查詢 |
key_len | 顯示mysql在索引里使用的字節數 |
ref | 顯示了之前的表在key列記錄的索引中查找值所用的列或常量 |
rows | 為了找到所需要的行而需要讀取的行數,估算值 |
Extra | 額外信息,如using index、filesort等 |
select_type 常見類型及其含義
- SIMPLE:不包含子查詢或者 UNION 操作的查詢
- PRIMARY:查詢中如果包含任何子查詢,那么最外層的查詢則被標記為 PRIMARY
- SUBQUERY:子查詢中第一個 SELECT
- DEPENDENT SUBQUERY:子查詢中的第一個 SELECT,取決於外部查詢
- UNION:UNION 操作的第二個或者之后的查詢
- DEPENDENT UNION:UNION 操作的第二個或者之后的查詢,取決於外部查詢
- UNION RESULT:UNION 產生的結果集
- DERIVED:出現在 FROM 字句中的子查詢
type常見類型及其含義
- system:這是 const 類型的一個特例,只會出現在待查詢的表只有一行數據的情況下
consts
:常出現在主鍵或唯一索引與常量值進行比較的場景下,此時查詢性能是最優的- eq_ref:當連接使用的是完整的索引並且是 PRIMARY KEY 或 UNIQUE NOT NULL INDEX 時使用它
ref
:當連接使用的是前綴索引或連接條件不是 PRIMARY KEY 或 UNIQUE INDEX 時則使用它- ref_or_null:類似於 ref 類型的查詢,但是附加了對 NULL 值列的查詢
- index_merge:該聯接類型表示使用了索引進行合並優化
range
:使用索引進行范圍掃描,常見於 between、> 、< 這樣的查詢條件index
:索引連接類型與 ALL 相同,只是掃描的是索引樹,通常出現在索引是該查詢的覆蓋索引的情況- ALL:全表掃描,效率最差的查找方式
阿里編碼規范要求:至少要達到 range 級別,要求是 ref 級別,如果可以是 consts 最好
key列
實際在查詢中是否使用到索引的標志字段
Extra列
Extra 列主要用於顯示額外的信息,常見信息及其含義如下:
- Using where :MySQL 服務器會在存儲引擎檢索行后再進行過濾
- Using filesort:通常出現在 GROUP BY 或 ORDER BY 語句中,且排序或分組沒有基於索引,此時需要使用文件在內存中進行排序,因為使用索引排序的性能好於使用文件排序,所以出現這種情況可以考慮通過添加索引進行優化
- Using index:使用了覆蓋索引進行查詢,此時不需要訪問表,從索引中就可以獲取到所需的全部數據
- Using index condition:查找使用了索引,但是需要回表查詢數據
- Using temporary:表示需要使用臨時表來處理查詢,常出現在 GROUP BY 或 ORDER BY 語句中
如何查看Mysql優化器優化之后的SQL
# 僅在服務器環境下或通過Navicat進入命令列界面
explain extended SELECT * FROM `student` where `name` = 1 and `age` = 1;
# 再執行
show warnings;
# 結果如下:
/* select#1 */ select `mytest`.`student`.`age` AS `age`,`mytest`.`student`.`name` AS `name`,`mytest`.`student`.`year` AS `year` from `mytest`.`student` where ((`mytest`.`student`.`age` = 1) and (`mytest`.`student`.`name` = 1))
為什么要做這個事呢?我們知道Mysql有一個最左匹配原則,那么如果我的索引建的是age,name,那我以name,age這樣的順序去查詢能否使用到索引呢?實際上是可以的,就是因為Mysql查詢優化器可以幫助我們自動對SQL的執行順序等進行優化,以選取代價最低的方式進行查詢(注意是代價最低,不是時間最短)
SQL優化
超大分頁場景解決方案
如表中數據需要進行深度分頁,如何提高效率?在阿里出品的Java編程規范中寫道:
利用延遲關聯或者子查詢優化超多分頁場景
說明:MySQL 並不是跳過 offset 行,而是取 offset+N 行,然后返回放棄前 offset 行,返回 N 行,那當 offset 特別大的時候,效率就非常的低下,要么控制返回的總頁數,要么對超過特定閾值的頁數進行 SQL 改寫
# 反例(耗時129.570s)
select * from task_result LIMIT 20000000, 10;
# 正例(耗時5.114s)
SELECT a.* FROM task_result a, (select id from task_result LIMIT 20000000, 10) b where a.id = b.id;
# 說明
task_result表為生產環境的一個表,總數據量為3400萬,id為主鍵,偏移量達到2000萬
獲取一條數據時的Limit 1
如果數據表的情況已知,某個業務需要獲取符合某個Where條件下的一條數據,注意使用Limit
說明:在很多情況下我們已知數據僅存在一條,此時我們應該告知數據庫只用查一條,否則將會轉化為全表掃描
# 反例(耗時2424.612s)
select * from task_result where unique_key = 'ebbf420b65d95573db7669f21fa3be3e_861414030800727_48';
# 正例(耗時1.036s)
select * from task_result where unique_key = 'ebbf420b65d95573db7669f21fa3be3e_861414030800727_48' LIMIT 1;
# 說明
task_result表為生產環境的一個表,總數據量為3400萬,where條件非索引字段,數據所在行為第19486條記錄
批量插入
# 反例
INSERT into person(name,age) values('A',24)
INSERT into person(name,age) values('B',24)
INSERT into person(name,age) values('C',24)
# 正例
INSERT into person(name,age) values('A',24),('B',24),('C',24);
# 說明
比較常規,就不多做說明了
like語句的優化
like語句一般業務要求都是 '%關鍵字%'
這種形式,但是依然要思考能否考慮使用右模糊的方式去替代產品的要求,其中阿里的編碼規范提到:
頁面搜索嚴禁左模糊或者全模糊,如果需要請走搜索引擎來解決
# 反例(耗時78.843s)
EXPLAIN select * from task_result where taskid LIKE '%tt600e6b601677b5cbfe516a013b8e46%' LIMIT 1;
# 正例(耗時0.986s)
select * from task_result where taskid LIKE 'tt600e6b601677b5cbfe516a013b8e46%' LIMIT 1
##########################################################################
# 對正例的Explain
1 SIMPLE task_result range adapt_id adapt_id 98 99 100.00 Using index condition
# 對反例的Explain
1 SIMPLE task_result ALL 33628554 11.11 Using where
# 說明
task_result表為生產環境的一個表,總數據量為3400萬,taskid是一個普通索引列,可見%%這種匹配方式完全無法使用索引,從而進行全表掃描導致效率極低,而正例通過索引查找數據只需要掃描99條數據即可
避免SQL中對where字段進行函數轉換或表達式計算
# 反例
select * from task_result where id + 1 = 15551;
# 正例
select * from task_result where id = 15550;
##########################################################################
# 對正例的Explain
1 SIMPLE task_result const PRIMARY PRIMARY 8 const 1 100.00
# 對反例的Explain
1 SIMPLE task_result ALL 33631512 100.00 Using where
# 說明
其實在知道了有SQL優化器之后,我個人感覺這種普通的表達式轉換應該可以提前進行處理再進行查詢,這樣一來就可以用到索引了,但是問題又來了,如果mysql優化器可以提前計算出結果,那么寫sql語句的人也一定可以提前計算出結果,所以矛盾點在這個地方,導致5.7版本以前的此種情況都無法使用索引吧,未來可能會對其進行優化
使用 ISNULL()來判斷是否為 NULL 值
說明:NULL 與任何值的直接比較都為 NULL
# 1) NULL<>NULL 的返回結果是 NULL,而不是 false。
# 2) NULL=NULL 的返回結果是 NULL,而不是 true。
# 3) NULL<>1 的返回結果是 NULL,而不是 true。
多表查詢
我所在的公司基本禁止了多表查詢,那如果必須使用到的話,我們可以一起參考一下阿里的編碼規范
Eg:超過三個表禁止 join。需要 join 的字段,數據類型必須絕對一致;多表關聯查詢時,保證被關聯的字段需要有索引
明明有索引為什么還走全表掃描
之前回答一些面試問題的時候,對某一個點的理解出現了偏差,即我認為只要查詢的列有索引則一定會使用索引去Push數據
然而實際上不僅僅是這樣,真正應該是:針對查詢的數據行占總數據量過多時會轉化成全表查詢
那么這個過多指代的是多少呢?
我的測試結果是50%,但個人認為MySQL優化器不會完全糾結於行數區分是否全表,而是有很多其他因素綜合考慮發現全表掃描的效率更高等等,所以充分認識到該問題即可
count(*) 還是 count(id)
阿里的Java編碼規范中有以下內容:
【強制】不要使用 count(列名) 或 count(常量) 來替代 count(*)
count(*) 是 SQL92 定義的標准統計行數的語法,跟數據庫無關,跟 NULL 和非 NULL 無關。
說明:count(*)會統計值為 NULL 的行,而 count(列名)不會統計此列為 NULL 值的行
字段類型不同導致索引失效
阿里的Java編碼規范中有以下內容:
【推薦】防止因字段類型不同造成的隱式轉換,導致索引失效
實際上數據庫在查詢的時候會作一層隱式的轉換,比如 varchar 類型字段通過 數字去查詢
# 正例
EXPLAIN SELECT * FROM `user_coll` where pid = '1';
type:ref
ref:const
rows:1
Extra:Using index condition
# 反例
EXPLAIN SELECT * FROM `user_coll` where pid = 1;
type:index
ref:NULL
rows:3(總記錄數)
Extra:Using where; Using index
# 說明
pid字段有相應索引,且格式為varchar
關於
感謝以下博文及其作者:
Tips
自建數據表進行測試
CREATE TABLE `student` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
`name` varchar(255) NOT NULL,
`class` varchar(255) DEFAULT NULL,
`page` bigint(20) DEFAULT NULL,
`status` tinyint(3) unsigned NOT NULL COMMENT '狀態:0 正常,1 凍結,2 刪除',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4
插入數據
DELIMITER ;;
CREATE PROCEDURE insertData()
BEGIN
declare i int;
set i = 1 ;
WHILE (i < 1000000) DO
INSERT INTO student(`name`,class,`page`,`status`)
VALUES(CONCAT('class_', i),
CONCAT('class_', i),
i, (SELECT FLOOR(RAND() * 2)));
set i = i + 1;
END WHILE;
commit;
END;;
CALL insertData();