神奇的 SQL 之聯表細節 → MySQL JOIN 的執行過程（二）

時間 2020-01-04

標籤神奇 sql 細節 mysql join 執行過程欄目 SQL 简体版

原文原文鏈接

開心一刻

　　一頭母牛在吃草，忽然一頭公牛從遠處狂奔而來講：「快跑啊！！樓主來了！」html

　　母牛說：「樓主來了關我屁事啊？」java

　　公牛急忙說：「樓主吹牛逼呀！」mysql

　　母牛大驚，拔腿就跑，邊跑邊問：「你是公牛你怕什麼啊？」android

　　公牛無奈道：「如今的樓主不只吹牛逼，還扯蛋！」ios

　　而後小牛也在跟着跑，公牛和母牛問：「兒子你跑什麼呢？」git

　　小牛說：「樓主還扯犢子啊」算法

前情回顧

　　神奇的 SQL 之聯表細節 → MySQL JOIN 的執行過程（一）中，咱們講到了 JOIN 的部份內容，像：驅動表、JOIN 大體流程等。什麼，還沒看？趕忙去看呀，啊？你都知道呀，那你走吧sql

　　走就走，你把欠的內容還上我就走；我欠什麼了？我欠，我欠... 我好像是欠點東西數據庫

　　　　一、BKA（Batched Key Access）緩存

　　　　二、ON 和 WHERE

　　請各位坐好，我要開始表演了

環境準備

　　數據庫： MySQL 5.7.1

　　存儲引擎： InnoDB

　　建表和初始化數據

-- 查看版本和存儲引擎
SELECT VERSION();
SHOW ENGINES;
SHOW VARIABLES LIKE '%storage_engine%';

-- 表建立與數據初始化
DROP TABLE IF EXISTS tbl_user;
CREATE TABLE tbl_user (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  user_name VARCHAR(50) NOT NULL COMMENT '用戶名',
  sex TINYINT(1) NOT NULL COMMENT '性別, 1:男，0:女',
  create_time datetime NOT NULL COMMENT '建立時間',
  update_time datetime NOT NULL COMMENT '更新時間',
    remark VARCHAR(255) NOT NULL DEFAULT '' COMMENT '備註',
  PRIMARY KEY (id)
) COMMENT='用戶表';

DROP TABLE IF EXISTS tbl_user_login_log;
CREATE TABLE tbl_user_login_log (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  user_name VARCHAR(50) NOT NULL COMMENT '用戶名',
  ip VARCHAR(15) NOT NULL COMMENT '登陸IP',
  client TINYINT(1) NOT NULL COMMENT '登陸端, 1:android, 2:ios, 3:PC, 4:H5',
  create_time datetime NOT NULL COMMENT '建立時間',
  PRIMARY KEY (id)
) COMMENT='登陸日誌';
INSERT INTO tbl_user(user_name,sex,create_time,update_time,remark) VALUES
('何天香',1,NOW(), NOW(),'朗眉星目，一表人材'),
('薛沉香',0,NOW(), NOW(),'天星樓的總樓主薛搖紅的女兒，也是天星樓的少總樓主，體態豐盈，烏髮飄逸，指若春蔥，袖臂如玉，風姿卓然，高貴典雅，人稱「天星絕香」的武林第一大美女'),
('慕容蘭娟',0,NOW(), NOW(),'武林東南西北四大世家之北世家慕容長明的獨生女兒，生得玲瓏剔透，粉雕玉琢，脾氣倒是剛烈無比，又喜着火紅，因此人送綽號「火鳳凰」，是除天星樓薛沉香以外的武林第二大美女'),
('萇婷',0,NOW(), NOW(),'當今皇上最寵愛的侄女，北王府的郡主，腰肢纖細，遍體羅綺，眉若墨畫，脣點櫻紅；雖無沉香之雅重，蘭娟之熱烈，卻別現出一種空靈'),
('柳含姻',0,NOW(), NOW(),'武林四絕之一的添愁仙子董婉婉的徒弟，體態窈窕，姿容秀麗，真個是秋水爲神玉爲骨，芙蓉如面柳如腰，眉若墨畫，脣若點櫻，不弱西子半分，更勝玉環一籌; 搖紅樓、聽雨軒，琵琶一曲值千金!'),
('李凝雪',0,NOW(), NOW(),'李相國的女兒，神采奕奕，英姿颯爽，愛憎分明'),
('周遺夢',0,NOW(), NOW(),'音神傳人，湘妃竹琴的擁有者，雲髻高盤，穿了一身黑色蟬翼紗衫，愈以爲冰肌玉骨，粉面櫻脣，格外嬌豔動人'),
('葉留痕',0,NOW(), NOW(),'聖域聖女，膚白如雪，白衣飄飄，宛如仙女通常，微笑中帶着說不出的柔和之美'),
('郭疏影',0,NOW(), NOW(),'揚灰右使的徒弟，秀髮細眉，玉肌豐滑，嬌潤脫俗'),
('鍾鈞天',0,NOW(), NOW(),'天界，玄天九部 - 鈞天部的部主，超凡脫俗，仙氣逼人'),
('王雁雲',0,NOW(), NOW(),'塵緣山莊二小姐，刁蠻任性'),
('許侍霜',0,NOW(), NOW(),'藥王谷谷主女兒，醫術高明'),
('馮黯凝',0,NOW(), NOW(),'桃花門門主，嬌豔如火，千嬌百媚');
INSERT INTO tbl_user_login_log(user_name, ip, client, create_time) VALUES
('薛沉香', '10.53.56.78',2, '2019-10-12 12:23:45'),
('萇婷', '10.53.56.78',2, '2019-10-12 22:23:45'),
('慕容蘭娟', '10.53.56.12',1, '2018-08-12 22:23:45'),
('何天香', '10.53.56.12',1, '2019-10-19 10:23:45'),
('柳含姻', '198.11.132.198',2, '2018-05-12 22:23:45'),
('馮黯凝', '198.11.132.198',2, '2018-11-11 22:23:45'),
('周遺夢', '198.11.132.198',2, '2019-06-18 22:23:45'),
('郭疏影', '220.181.38.148',3, '2019-10-21 09:45:56'),
('薛沉香', '220.181.38.148',3, '2019-10-26 22:23:45'),
('萇婷', '104.69.160.60',4, '2019-10-12 10:23:45'),
('王雁雲', '104.69.160.61',4, '2019-10-16 20:23:45'),
('李凝雪', '104.69.160.62',4, '2019-10-17 20:23:45'),
('許侍霜', '104.69.160.63',4, '2019-10-18 20:23:45'),
('葉留痕', '104.69.160.64',4, '2019-10-19 20:23:45'),
('王雁雲', '104.69.160.65',4, '2019-10-20 20:23:45'),
('葉留痕', '104.69.160.66',4, '2019-10-21 20:23:45');

SELECT * FROM tbl_user;
SELECT * FROM tbl_user_login_log;


DROP TABLE IF EXISTS tbl_range_access;
CREATE TABLE tbl_range_access (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  a INT(11) NOT NULL COMMENT '測試索引', 
    name VARCHAR(50) NOT NULL COMMENT '姓名',
    age TINYINT(3) NOT NULL COMMENT '年齡',
  PRIMARY KEY (id),
    INDEX i_a(a)
) COMMENT='mrr測試';
INSERT INTO tbl_range_access(a,name,age) VALUES
(5,'123654', 23),
(8, 'asdf',20),
(1,'lljl',19),
(4, '98459',64),
(7,'zhangsan', 45),
(9,'lisi',46),
(2,'zhaoqian',25),
(6,'hello', 23),
(3,'world',100),
(10,'666',66),
(88, '888',88);

SELECT * FROM tbl_range_access;

View Code

　　表 tbl_range_access 的數據要多一點，像上面示例只有 11 條記錄，那麼即便 a 字段上有索引， SELECT * FROM tbl_range_access WHERE a BETWEEN 4 AND 9; 也不會走索引，執行計劃以下

　　數據太少，優化器以爲走索引，而後回表查詢數據，還不如直接走聚簇索引全表查詢來的快，因此沒有選擇走索引 i_a

　　既然數據太少，咱們就多造點數據，運行 data-init 下的 RangeAccessTest.java 中的 batchAddData 方法就好，輕輕鬆鬆 10W 到手！此時執行計劃以下

MRR

　　講 BKA 以前了，咱們不得不先看下 MRR，它是 BKA 的重要支柱

　　全稱 Multi-Range Read ，是對多行 IO 查詢進行優化的一種策略，詳情可看 MySQL 的 mrr-optimization 或者 MariaDB 的 Multi Range Read Optimization（MySQL 和 MariaDB 是什麼關係？呃，這麼說吧，他們是一個爹的兒子）。簡單點來講，MRR 是優化器將隨機 IO 轉化爲順序 IO 以下降查詢過程當中 IO 開銷的一種手段

什麼是讀盤與落盤（IO）

    當前絕大多少狀況下，MySQL 的數據是存在機械硬盤（SATA 盤）上的，極少數狀況下是存在固態硬盤（SSD）上的；讀盤指的是從磁盤讀取數據的過程，落盤指的是從內存持久化到磁盤的過程

爲何順序讀盤比隨機讀盤快

    這不是絕對的，多數狀況下是這樣的；至於爲何，這涉及到機械硬盤的硬件知識了，包括其組織結構，以及磁盤的讀盤過程，另外還須要瞭解 MySQL 數據的落盤與讀盤（頁爲單位），內容太多，就不在本篇講了（實際上是觸及到了樓主的知識盲區，樓主不會！）
    MariaDB 中說明了以下 3 個緣由
    1、Rotating drives do not have to move the head back and forth
    2、One can take advantage of IO-prefetching done at various levels
    3、Each disk page will be read exactly once, which means we won't rely on disk cache (or buffer pool) to save us from reading the same page multiple times

　　使用場景

　　　　不是任何狀況下 MySQL 都會使用 MRR 的，只是在某些狀況下會用 MRR 來進行優化

摘自 Multi Range Read Optimization

　　　　MySQL 中的 NDB 也會用到 MRR，通常而言，咱們無需關注，咱們只關注上圖中的狀況就好了

　　理論以後來點案例，完美！

　　range access

　　　　表 tbl_range_access 的 a 字段上咱們已經建了索引 i_a ，咱們來個範圍查詢，看下執行計劃 EXPLAIN SELECT * FROM tbl_range_access WHERE a BETWEEN 4 AND 9; 以下

　　　　此時沒有用到 MRR，執行此查詢時，磁盤 IO 訪問模式將遵循下圖中的紅線

　　　　由於是 SELECT * ，因此經過索引 i_a 先找到主鍵 ID，而後經過主鍵 ID 回表（從聚簇索引）查詢完整記錄；a 在索引 i_a 中是有序的，但不保證主鍵在 i_a 中也是有序的（關於 MySQL 的索引，推薦你們去看：MySQL的索引），這就致使回表的過程是隨機 IO

　　　　爲何 MySQL 沒有采用 MRR 來保證回表的過程是順序 IO 呢？mrr-optimization 中有這麼一段話

Two optimizer_switch system variable flags provide an interface to the use of MRR optimization. The mrr flag controls whether MRR is enabled. If mrr is enabled (on), the mrr_cost_based flag controls whether the optimizer attempts to make a cost-based choice between using and not using MRR (on) or uses MRR whenever possible (off). By default, mrr is on and mrr_cost_based is on

　　　　 mrr 和 mrr_cost_based 的默認值是 on ；我簡單畫個圖，你們就明白這兩個開關的做用了

　　　　上面的示例之因此沒使用 MRR，是優化器以爲使用 MRR 反而提高了成本，還不如不使用

　　　　咱們強制優化器使用 MRR：

-- 查看全部開關及其默認值
SELECT @@optimizer_switch;

-- mrr_cost_based設置成off,強制優化器使用 mrr
SET optimizer_switch='mrr_cost_based=off';

　　　　咱們再來看看執行計劃是什麼樣的

　　　　此時用到 MRR，執行此查詢時，磁盤 IO 訪問模式將遵循下圖中的紅線

　　　　此時回表查詢的主鍵是有序的，會採用順序 IO 來讀取數據，從而提升查詢效率

MySQL 中有個 rowids_buffer，用來緩存從索引 i_a 中查詢到的數據記錄（包含字段 a 和主鍵 ID），緩存滿了或者索引查完了，再對緩存中記錄按照主鍵 id 進行排序,再用排序後的主鍵 id 進行回表，使得回表查詢的過程是順序 IO

　　是否是感受 MRR 有點像二級索引與主鍵的 JOIN 操做，有這感受就對了，後面的 BKA 也就好理解了

BKA

　　BKA 全稱是： Batched Key Access ，是對 INL 優化後的一種聯表算法，相似與 BNL 對 SNL 的優化，但又有些不一樣，具體咱們往下看

　　先在表 tbl_user 新增一個索引 ALTER TABLE tbl_user ADD index i_aaa(user_name); ，此時查看執行計劃 EXPLAIN SELECT * FROM tbl_user_login_log tl LEFT JOIN tbl_user tu ON tl.user_name = tu.user_name; 以下圖

　　此時的聯表算法就是 INL，由於表 tbl_user_login_log 的 user_name 是無索引的，那麼從表 tbl_user_login_log 取出的 user_name 的值就是無序的，再去關聯 tbl_user ，就會隨機匹配索引 i_aaa ，相似下圖

　　是否是有點相似於前面講過的回表隨機 IO ？

　　BKA 功能默認是關閉的（ batched_key_access=off ），開啓它

SET optimizer_switch='mrr=on,mrr_cost_based=off,batched_key_access=on';

　　咱們再來看執行計劃

　　從tbl_user_login_log 查詢到的 user_name 的值先放到 join buffer，當 join buffer 滿了或者數據查完了，再對 join buffer 裏面的值進行排序，而後再去關聯 tbl_user ，此時就會順序匹配索引 i_aaa ，相似下圖

　　若是須要回表，那麼 MySQL 會按以前講到過的回表流程再優化一次

默認值的思考

　　MRR 相關的 3 個開關的默認值是這樣的 mrr=on,mrr_cost_based=on,batched_key_access=off

　　 mrr=on 表示 mrr 功能是開啓的，開啓並不表明必定會使用，但不開啓則必定享受不到 mrr 帶來的優化；

　　mrr_cost_based=on 表示優化器會基於成本考慮來決定是否使用 mrr，使用 mrr 反而使成本變高，那爲何使用 mrr ？只有 mrr 確實是帶來了效率上的提高，那麼使用它纔有意義，可是成本的計算又是優化器來完成的，並且是一個比較複雜的過程，必定能保證優化器的成本計算是準確的嗎？ 100%準確確定不敢保證，但通過這麼多年的沉澱，絕大多數狀況下，優化器的成本計算是準確的，因此 mrr_cost_based 建議就採用默認值 on ，由優化器來決定是否採用 mrr

　　 batched_key_access=off 表示默認不啓用 BKA，說實話，我沒太理解這麼作的意圖；既然是否使用 mrr 交由優化器來決定了，沒什麼不把是否使用 BKA 也交由優化器來決定？我能猜到的可能緣由之一是基本用不到，爲何這麼說？咱們回想下 BKA 會在什麼狀況下使用：驅動表在關聯的字段上無索引，而被驅動表在關聯的字段上有索引，而若是驅動表在關聯的字段上有索引了，還有必要進行緩存、排序、再關聯被驅動表嗎？很顯然沒必要了，由於索引的字段原本就是有序的了；而實際應用中，關聯的字段，不論是驅動表仍是被驅動表，每每是同時存在索引的，而不是一個存在索引而另外一個不存在索引。這只是我我的的猜測，望知道的大神能解惑下，小弟不勝感激！