Overview of Optimizer Features in 5.6 and 5.7-Manyi Lu

MySQL5.6 and 5.7優化器概觀
Manyi Lu
Senior Manager, MySQL Optimizer Team

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification 2 from Slide 12
MySQL優化器
 找出優化器的查詢計畫
– 索引的選擇
– Join的順序
– 查詢轉型
 以成本為基礎的優化
– 找出不同計畫的成本,選擇最佳的

MySQL優化器
了解優化器對設計一個有效率的架構和查詢的重要性.
 不再需要做許多walkarounds
 了解如何知道優化器在作什麼事
 Joins快了許多 - 了解如何善用它發揮最佳效益

MySQL 5.6優化器的改進
 改良子查詢的執行
 SQL有小的Limit時優化檔案的排序
 索引狀況下推(Index condition pushdown)
 批量鍵值取用(Batched key access )和多域讀取(multi
range read)
 延後materialization

MySQL 5.6優化器的改進
 多表的join
 多個值在In() 中的查詢
 優化器統計的持久性
 insert, delete, 和 update 的Explain
 Optimizer traces優化器追蹤
 Explain以JSON 格式呈現結果

子查詢的優化
 由於效能不够好,5.6之前使用者常要避免使用子查詢
 5.6:優化IN 子句中的子查詢
SELECT title FROM film WHERE film_id IN
(SELECT film_id FROM film_actor);
 演算法:
– Table pullout
– Semi-join
– Materialization
 例: DBT3 Query #18
– 執行時間由數天降為數秒

小的Limit時的檔案排序優化
 網路運用– 依名稱列示前一100個產品
 避免中介檔案的排序
 以一個表掃瞄產生排序後的結果
 上列例子: 兩千萬行,用預設的排序緩沖區
=>執行間快三倍,由40秒降為10秒時

Multi Range Read (MRR)
非MRR:
 在磁碟上隨機取用base table 的資料
MRR:
 以較為有順序的方式掃瞄base table的資料

MySQL 5.5: 沒有MRR時的資料取用
Index Table
Index
scan
Random access

MySQL 5.6:有MRR時的資料取用
以InnoDB為例
Index Table
Index
scan
PKs in
index order
PKs in
PK order
Sort
Sweep-read
rows
Collect
PKs in
buffer

MySQL 5.6:一般的Nested Loop Join
沒有join buffering時
Table1 Index Table2
Table
scan

MySQL 5.6: Batched Key Access (BKA)
MRR 應用到Join Buffering
Index
PKs in join
buffer order
PKs in
PK order
Sort
Table2
Sweep-read
rows
Collect
PKs in
buffer
Table1
Join buffer

Batched Key Access和Multi Range Read
沒有BKA 和 MRR的查詢
執行時間
有BKA和MRR的查詢時間
DBT3 Q13 Customer distribution query
改進受磁碟速度限制的查詢性能

Index Condition Pushdown
 當關閉ICP時
– 15s (buffer pool 設為128Mb時)
– 1.4s (buffer pool 設為1.5Gb時)
CREATE TABLE person (
personid INTEGER PRIMARY KEY,
firstname CHAR(20),
lastname CHAR(20),
postalcode INTEGER,
age INTEGER,
address CHAR(50),
KEY k1(postalcode, age)
) ENGINE=innodb;
SELECT firstname, lastname from person
where postalcode BETWEEN 5000 and 5500 AND age BETWEEN 21 AND 22;
 開啟ICP 時
– 兩個狀況都降到90 ms

延後在FROM之內的子查詢或View做Materialization
 延後materialization:
– 加速views或子查詢的EXPLAIN
– 儘可能避免materialization, 加速脫離因境
EXPLAIN SELECT * FROM (SELECT * FROM a_big_table);

延後在FROM之內的子查詢或View做Materialization
 為derived table加上索引
– 使ref能取用 derived tables
SELECT … FROM derived_table AS dt
join table AS t WHERE dt.fld = t.dlf
=> 執行時間快240倍 (由大約8 分鐘降至約2 秒)

改進Joins很多表的查詢效率
 (表的數目越多)! 可能的組合越
可多
 大幅降低找最佳化查詢計畫的
成本
 更能優化最後選出的計畫
 5.5: 表依行數由少至多來排序
 5.6: 考量鍵值的相依性
join 24個表的查詢

在IN子句中有許多值的查詢
 以前
– 對各值以two index dive來估計行數
– 需要較久的時間來優化查詢再執行它
 現在
– 用在統計中的各值的平均筆數
– 明顯的降低優化的時間
– eq_range_index_dive_limit = 10 by default (5.6) 200 (5.7)
SELECT * FROM t1 WHERE col1 IN (large number of value);

優化器統計持久化 (InnoDB)
 更精確的統計
 更穩定的統計
 預設為開啟狀態
 預設為會重新計算統計值
 ANALYSE TABLE
 可以手動的方式更新(以測試為目地時較有用)

資料更新指令的Explain

資料更新指令的Explain (續)

Explain輸出結構化
 EXPLAIN FORMAT=JSON
 比傳統的explain更精確
 更多的資訊
 在MySQL workbench以圖示呈現
mysql> EXPLAIN FORMAT=JSON SELECT *
FROM t2 WHERE I > 1 AND j < 3;
{
"query_block": {
"select_id": 1,
"table": {
"table_name": "t2",
"access_type": ”range",
"possible_keys": [
“PRIMIARY”
],
“key”: “PRIMARY”,
“key_length”: “4”,
"rows": 2,
"filtered": 100,
”index_condition": "(`test`.`t2`.`i` > 1)”,
"attached_condition": "(`test`.`t2`.`j` < 3)"
}
}
} |

Optimizer Traces "rows_estimation": [ {
"table": "`t1`",
"range_analysis": {
"table_scan": {
"rows": 5,
"cost": 4.1
},
"potential_range_indices": [ {
"index": "v_idx",
"usable": true,
"key_parts": [
"v",
"i1” ]
}
],
"best_covering_index_scan": {
"index": "v_idx",
"cost": 2.0063,
"chosen": true
},
 Explain 列示產生的計畫
 Trace顯示計畫是如何產的,決策點,成本等
 開發者,支援部門,技術較高的用戶
 自5.6.3版引進, 隨著新版本推出,會加入更多的
tracing
SET SESSION. OPTIMIZER_TRACE=‘enabled=on’;
SELECT (SELECT 1 FROM t6 WHERE d=c)
AS RESULT FROM t5;
SELECT* FROM
INFORMATIONM_SCHEMA.OPIMIZER_TRACE;

MySQL 5.7 Explain額外的成本資料
mysql> EXPLAIN FORMAT=JSON SELECT SUM(o_totalprice) FROM
orders WHERE o_orderdate BETWEEN '1994-01-01' AND '1994-12-31';
{ "query_block": {
"select_id": 1,
"cost_info": {
"query_cost": "3118848.00"
},
"table": {
"table_name": "orders",
"access_type": "ALL",
"possible_keys": [
"i_o_orderdate" ],
"rows_examined_per_scan": 15000000,
"rows_produced_per_join": 4489990,
"filtered": 29.933,
"cost_info": {
"read_cost": "2220850.00",
"eval_cost": "897998.00",
"prefix_cost": "3118848.00",
"data_read_per_join": "582M"
},
"used_columns": [
"o_totalprice",
"o_orderDATE"
],
"attached_condition": "(`dbt3`.`orders`.`o_orderDATE` between '1994-01-
01' and '1994-12-31')" } } }
 一個查詢區塊的總查詢成本
 每個表的成本
 排序作業的成本
 讀取資料的成本
 評估狀況的成本
 prefix join的成本
 每個 join所檢視/產生的行數
 使用的欄位
 每個join所讀的資料 –
(# of rows)*(record width) in byte

5.7 在MySQL Workbench圖示化Explain

MySQL 5.7 Explain正在執行中的查詢
 以連線<id>顯示查詢計畫
 在診斷執行時間長的查詢時很有用
 當查詢計畫正在建立時是無法取得計畫的
 適用於SELECT/INSERT/DELETE/UPDATE

MySQL 5.7 利用Condition Filter
 目的: 以最低成本選擇計畫
Total Cost = cost(access_method_table1) + prefix_row_table1 *
cost(access_method_table2)
 5.6: prefix_row_table1: 是由access_method_table1傳回的行數
 5.7: prefix_row_table1: 是在table1中對所有狀況為真的行數,
prefix_row_table = #rows * filtered
 狀況篩選因為考量了所有相關的狀況,而提供更好的prefix row估計
 更精確的成本估計 -> 改進 join 的順序!

MySQL 5.7利用Condition Filter
• 在employee 表有1024行
• 在department表有12行
• hire_date BETWEEN “2012-01-01″ AND “2012-06-01″有150行
• first_name=”John”的有8行
• 有一行的first_name=”John” AND hire_date BETWEEN “2012-01-01″ AND
“2012-06-01″

MySQL 5.7利用Condition Filter
Mysql>EXPLAIN
->SELECT *
-> FROM employee JOIN department ON employee.dept_no=department.dept_no
-> WHERE employee.first_name="John" AND employee.hire_date BETWEEN "2012-01-01" AND "2012-06-01";
+----+--------------------+---------------+----------------------------+---------------+-------------+---------+-------------+
| id | table | type | possible_keys | key | ref | rows | filtered |
+----+--------------------+----------------|-----------------------------+---------------+-------------+---------+------------+
| 1 | employee | ref | name,h_date,dept | name | const | 8 | 100.00 |
| 1 | department | eq_ref | PRIMARY | PRIMARY | dept_no | 1 | 100.00 |
+----+--------------------+----------------+----------------------------+----------------+------------+---------+------------+
mysql> EXPLAIN
-> SELECT *
-> FROM employee JOIN department ON employee.dept_no=department.dept_no
-> WHERE employee.first_name="John" AND employee.hire_date BETWEEN "2012-01-01" AND "2012-06-01";
+----+-------------------+--------------+------------------------------+---------------+-------------+----------+-----------+
| id | table | type | possible_keys | key | ref | rows | filtered |
+----+-------------------+--------------+-------------------------------+--------------+-------------+----------+-----------+
| 1 | employee | ref | name,h_date,dept | name | const | 8 | 16.31 |
| 1 | department | eq_ref | PRIMARY | PRIMARY | dept_no | 1 | 100.00 |
+----+-------------------+--------------+-------------------------------+---------------+------------+----------+-----------+
5.6
5.7

MySQL 5.7 在 UNION ALL 時避免建立臨時表
 5.6: 一向在臨時表materialize UNION ALL的結果
 5.7: 不在臨時表materialize, 除非用於排序, 記錄直接送到前端
 5.7: 前端會更快的收到第一筆記錄, 不需等最後一個查詢區塊一完成才
能收到
 5.7: 消耗較少記憶體和磁碟

MySQL 5.7: 優化器成本模型
 新的成本模式API
 讓存儲引擎為鍵值查找,表掃,區域掃等…提供精確且動態的成本估計
‒ 讓未來支持額外的因素
 資料是否在RAM, SSD, HDD
 重點放在使成本可被配置
‒ 基於您的硬體的性能特性
 改進記錄每個鍵的估計
 在Explain的JSON格式輸出中包含成本值

在我們的路線圖上有啥?
 改進指令的效能
 支援functional index
 重設計cost model, 加上 histogram
 自底層重寫解析器
 持續重構優化器

Graphic Section Divider

Overview of Optimizer Features in 5.6 and 5.7-Manyi Lu

More Related Content

What's hot

Similar to Overview of Optimizer Features in 5.6 and 5.7-Manyi Lu

More from 郁萍 王

Recently uploaded

Overview of Optimizer Features in 5.6 and 5.7-Manyi Lu

More from 郁萍王