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 from Slide 12 2

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時

Index Table2 Table1

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`.ì` > 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`.òrders`.ò_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

Technology

Overview of Optimizer Features in 5.6 and 5.7-Manyi Lu