MySQL8.0 · 優化器新特性 · Cost Model, 直方圖及優化器開銷優化

摘要： MySQL當前已經發布到MySQL8.0版本，在新的版本中，可以看到MySQL之前被人詬病的優化器部分做了很多的改動，由於筆者之前的工作環境是5.6，最近切換到最新的8.0版本，本文涵蓋了一些本人感興趣的和優化器相關的部分，主要包括MySQL5.7的cost model以及MySQL8.0的直...

SQL/">MySQL當前已經發布到MySQL8.0版本，在新的版本中，可以看到MySQL之前被人詬病的優化器部分做了很多的改動，由於筆者之前的工作環境是5.6，最近切換到最新的8.0版本，本文涵蓋了一些本人感興趣的和優化器相關的部分，主要包括MySQL5.7的cost model以及MySQL8.0的直方圖功能。

本文基於當前最新的MySQL8.0.12版本，主要是講下cost model 和 histogram的用法和相關程式碼

Cost Model

Configurable cost constants

為什麼需要配置cost model常量 ? 我們知道MySQL已經發展了好幾十年的歷史，但是在優化器中依然使用了hardcode的權重值來衡量io, cpu等資源情況，而這些權重值實際上是基於多年前甚至十來年前的經驗設定的。想想看，這麼多年硬體的發展多麼迅速。幾十上百個核心的伺服器不在少數甚至在某些大型公司大規模使用，ssd早就成為主流，NVME也在崛起。高速RDMA網路正在走入尋常百姓家。這一切甚至影響到資料庫系統的實現和變革。顯而易見，那些hardcode的權值已經過時了，我們需要提供給使用者可定義的方式，甚至更進一步的，能夠智慧的根據硬體環境自動設定。

MySQL5.7引入兩個新的系統表, 通過這兩個系統表暴露給使用者來進行更新，如下：

root@(none) 04:05:24>select * from mysql.server_cost;
+------------------------------+------------+---------------------+---------+---------------+
| cost_name| cost_value | last_update| comment | default_value |
+------------------------------+------------+---------------------+---------+---------------+
| disk_temptable_create_cost|NULL | 2018-04-23 13:55:20 | NULL|20 |
| disk_temptable_row_cost|NULL | 2018-04-23 13:55:20 | NULL|0.5 |
| key_compare_cost|NULL | 2018-04-23 13:55:20 | NULL|0.05 |
| memory_temptable_create_cost |NULL | 2018-04-23 13:55:20 | NULL|1 |
| memory_temptable_row_cost|NULL | 2018-04-23 13:55:20 | NULL|0.1 |
| row_evaluate_cost|NULL | 2018-04-23 13:55:20 | NULL|0.1 |
+------------------------------+------------+---------------------+---------+---------------+
6 rows in set (0.00 sec)

其中default_value是generated column，其表示式已經固定死了預設值：

`default_value` float GENERATED ALWAYS AS (
(case `cost_name` 
when _utf8mb3'disk_temptable_create_cost' then 20.0 
when _utf8mb3'disk_temptable_row_cost' then 0.5 
when _utf8mb3'key_compare_cost' then 0.05 
when _utf8mb3'memory_temptable_create_cost' then 1.0 
when _utf8mb3'memory_temptable_row_cost' then 0.1 
when _utf8mb3'row_evaluate_cost' then 0.1 else NULL end)) VIRTUAL

root@(none) 04:05:35>select * from mysql.engine_cost;
+-------------+-------------+------------------------+------------+---------------------+---------+---------------+
| engine_name | device_type | cost_name| cost_value | last_update| comment | default_value |
+-------------+-------------+------------------------+------------+---------------------+---------+---------------+
| default|0 | io_block_read_cost|NULL | 2018-04-23 13:55:20 | NULL|1 |
| default|0 | memory_block_read_cost |NULL | 2018-04-23 13:55:20 | NULL|0.25 |
+-------------+-------------+------------------------+------------+---------------------+---------+---------------+

你可以通過update語句來進行更新, 例如：

root@(none) 04:05:52>update mysql.server_cost set cost_value = 40 where cost_name = 'disk_temptable_create_cost';
Query OK, 1 row affected (0.05 sec)
Rows matched: 1Changed: 1Warnings: 0

root@(none) 04:07:13>select * from mysql.server_cost where cost_name = 'disk_temptable_create_cost';
+----------------------------+------------+---------------------+---------+---------------+
| cost_name| cost_value | last_update| comment | default_value |
+----------------------------+------------+---------------------+---------+---------------+
| disk_temptable_create_cost |40 | 2018-06-23 16:07:05 | NULL|20 |
+----------------------------+------------+---------------------+---------+---------------+
1 row in set (0.00 sec)


//更新後執行一次flush optimizer_costs操作來更新記憶體
//但老的session還是會用老的cost資料
root@(none) 10:10:12>flush optimizer_costs;
Query OK, 0 rows affected (0.00 sec)

可以看到用法也非常簡單，上面包含了兩張表：server_cost及engine_cost，分別對server層和引擎層進行配置

相關程式碼:

全域性cache Cost_constant_cache

全域性cache維護了一個當前的cost model資訊, 使用者執行緒在lex_start時會去判斷其有沒有初始化本地指標，如果沒有的話就去該cache中將指標拷貝到本地

初始化全域性cache:

Cost_constant_cache::init
:

建立Cost_model_constants， 其中包含了兩類資訊: server層cost model和引擎層cost model, 類結構如下：


Cost_constant_cache ----> Cost_model_constants
---> Server_cost_constants
//server_cost
---> Cost_model_se_info 
--->SE_cost_constants
//engine_cost 如果儲存引擎提供了介面函式get_cost_constants的話,則從儲存引擎那取

從系統表讀取配置，適用於初始化和flush optimizer_costs並更新cache：

read_cost_constants()
|--> read_server_cost_constants
|--> read_engine_cost_constants

由於使用者可以動態的更新系統表，執行完flush optimizer_costs後，有可能老的版本還在被某些session使用，因此需要引用計數，老的版本ref counter被降為0後才能被釋放

執行緒cost model初始化

• Cost_model_server

在每個執行緒的thd上，掛了一個Cost_model_server的物件THD::m_cost_model, 在lex_start()時，如果發現執行緒的m_cost_model沒有初始化，就會去獲取全域性的指標，儲存到本地：

Cost_model_server::init

const Cost_model_constants *m_cost_constants = cost_constant_cache->get_cost_constants();
// 會增加一個引用計數，以確保不會在引用時被刪除

const Server_cost_constants *m_server_cost_constants = m_cost_constants->get_server_cost_constants();
// 同樣獲取的是全域性指標

可見thd不建立自己的cost model, 只引用cache中的指標

Table Cost Model

struct TABLE::m_cost_model, 型別：Cost_model_table

其值取自上述thd中儲存的cost model物件

Cost_estimate

統一的物件型別cost_estimate來儲存計算的cost結果，包含四個維度：

double io_cost;///< cost of I/O operations
double cpu_cost;///< cost of CPU operations
double import_cost;///< cost of remote operations
double mem_cost;///< memory used (bytes)

未來

目前來看，除非根據工作負載，經過充分的測試才能得出合理的配置值，但如何配置，什麼是合理的值，個人認為應該是可以自動調整配置的。關鍵是找出配置和硬體條件的對應關係。 這也是我們未來可以努力的一個方向。

reference:

Histogram

直方圖也是MySQL一個萬眾期待的功能了，這個功能實際上在其他資料庫產品中是很常見的，可以很好的指導優化器選擇執行路徑。利用直方圖儲存了指定列的資料分佈。MariaDB從很早的10.0.2版本支援這個功能 ， 而MySQL在最新的8.0版本中也開始支援

使用

MySQL裡使用直方圖是通過ANALYZE TABLE 語法來執行：

ANALYZE [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name
UPDATE HISTOGRAM ON col_name [, col_name] ...
[WITH N BUCKETS]

ANALYZE [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name
DROP HISTOGRAM ON col_name [, col_name] ...

舉個簡單的例子：

我們以普通的sysbench表為例：

root@sb1 05:16:33>show create table sbtest1\G
*************************** 1. row ***************************
Table: sbtest1
Create Table: CREATE TABLE `sbtest1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`k` int(11) NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=200001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.01 sec)


# 建立直方圖並存儲到資料詞典中

root@sb1 05:16:38>ANALYZE TABLE sbtest1 UPDATE HISTOGRAM ON k with 10 BUCKETS;
+-------------+-----------+----------+----------------------------------------------+
| Table| Op| Msg_type | Msg_text|
+-------------+-----------+----------+----------------------------------------------+
| sb1.sbtest1 | histogram | status| Histogram statistics created for column 'k'. |
+-------------+-----------+----------+----------------------------------------------+
1 row in set (0.55 sec)

root@sb1 05:17:03>ANALYZE TABLE sbtest1 UPDATE HISTOGRAM ON k,pad with 10 BUCKETS;
+-------------+-----------+----------+------------------------------------------------+
| Table| Op| Msg_type | Msg_text|
+-------------+-----------+----------+------------------------------------------------+
| sb1.sbtest1 | histogram | status| Histogram statistics created for column 'k'.|
| sb1.sbtest1 | histogram | status| Histogram statistics created for column 'pad'. |
+-------------+-----------+----------+------------------------------------------------+
2 rows in set (7.98 sec)

刪除pad列上的histogram:
root@sb1 05:17:51>ANALYZE TABLE sbtest1 DROP HISTOGRAM ON pad;
+-------------+-----------+----------+------------------------------------------------+
| Table| Op| Msg_type | Msg_text|
+-------------+-----------+----------+------------------------------------------------+
| sb1.sbtest1 | histogram | status| Histogram statistics removed for column 'pad'. |
+-------------+-----------+----------+------------------------------------------------+
1 row in set (0.06 sec)

root@sb1 05:58:12>ANALYZE TABLE sbtest1 DROP HISTOGRAM ON k;
+-------------+-----------+----------+----------------------------------------------+
| Table| Op| Msg_type | Msg_text|
+-------------+-----------+----------+----------------------------------------------+
| sb1.sbtest1 | histogram | status| Histogram statistics removed for column 'k'. |
+-------------+-----------+----------+----------------------------------------------+
1 row in set (0.08 sec)


# 如果不指定bucket的話，預設Bucket的數量是100

root@sb1 05:58:27>ANALYZE TABLE sbtest1 UPDATE HISTOGRAM ON k;
+-------------+-----------+----------+----------------------------------------------+
| Table| Op| Msg_type | Msg_text|
+-------------+-----------+----------+----------------------------------------------+
| sb1.sbtest1 | histogram | status| Histogram statistics created for column 'k'. |
+-------------+-----------+----------+----------------------------------------------+
1 row in set (0.56 sec)

直方圖統計資訊儲存於InnoDB資料詞典中，可以通過information_schema表來獲取

root@information_schema 05:34:49>SHOW CREATE TABLE INFORMATION_SCHEMA.COLUMN_STATISTICS\G
*************************** 1. row ***************************
View: COLUMN_STATISTICS
Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`mysql.infoschema`@`localhost` SQL SECURITY DEFINER VIEW `COLUMN_STATISTICS` AS select `mysql`.`column_statistics`.`schema_name` AS `SCHEMA_NAME`,`mysql`.`column_statistics`.`table_name` AS `TABLE_NAME`,`mysql`.`column_statistics`.`column_name` AS `COLUMN_NAME`,`mysql`.`column_statistics`.`histogram` AS `HISTOGRAM` from `mysql`.`column_statistics` where can_access_table(`mysql`.`column_statistics`.`schema_name`,`mysql`.`column_statistics`.`table_name`)
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set (0.00 sec)

從column_statistics表的定義可以看到，有一個名為mysql.column_statistics系統表，但被隱藏了，沒有對外暴露

以下舉個簡單的例子：

root@sb1 05:58:55>ANALYZE TABLE sbtest1 UPDATE HISTOGRAM ON k WITH 4 BUCKETS;
+-------------+-----------+----------+----------------------------------------------+
| Table| Op| Msg_type | Msg_text|
+-------------+-----------+----------+----------------------------------------------+
| sb1.sbtest1 | histogram | status| Histogram statistics created for column 'k'. |
+-------------+-----------+----------+----------------------------------------------+
1 row in set (0.63 sec)

# 查詢表上的直方圖資訊

root@sb1 06:00:43>SELECT JSON_PRETTY(HISTOGRAM) FROM INFORMATION_SCHEMA.COLUMN_STATISTICS WHERE SCHEMA_NAME='sb1' AND TABLE_NAME = 'sbtest1'\G
*************************** 1. row ***************************
JSON_PRETTY(HISTOGRAM): {
"buckets": [
[
38671,
99756,
0.249795,
17002
],
[
99757,
100248,
0.500035,
492
],
[
100249,
100743,
0.749945,
495
],
[
100744,
172775,
1.0,
16630
]
],
"data-type": "int",
"null-values": 0.0,
"collation-id": 8,
"last-updated": "2018-09-22 09:59:30.857797",
"sampling-rate": 1.0,
"histogram-type": "equi-height",
"number-of-buckets-specified": 4
}
1 row in set (0.00 sec)

從輸出的json可以看到，在執行了上述語句後產生的直方圖，有4個bucket，資料型別為Int, 型別為equi-height，即等高直方圖(另外一種是等寬直方圖，即SINGLETON)。每個Bucket中，描述的資訊包括：數值的上界和下界, 頻率以及不同值的個數。通過這些資訊可以獲得比較精確的資料分佈情況，從而優化器來根據這些統計資訊決定更優的執行計劃。

如果列上存在大量的重複值，那麼MySQL也可能選擇等寬直方圖，例如上例，我們將列k上的值更新為一半10一半為20， 那麼出來的直方圖資料如下：

root@sb1 10:41:17>SELECT JSON_PRETTY(HISTOGRAM) FROM INFORMATION_SCHEMA.COLUMN_STATISTICS WHERE SCHEMA_NAME='sb1' AND TABLE_NAME = 'sbtest1'\G
*************************** 1. row ***************************
JSON_PRETTY(HISTOGRAM): {
"buckets": [
[
10,
0.499995
],
[
20,
1.0
]
],
"data-type": "int",
"null-values": 0.0,
"collation-id": 8,
"last-updated": "2018-09-22 14:41:17.312601",
"sampling-rate": 1.0,
"histogram-type": "singleton",
"number-of-buckets-specified": 100
}
1 row in set (0.00 sec)

如上，對於SINGLETON型別，每個bucket只包含兩個值：列值，及對應的累計頻率（即百分之多少的資料比當前Bucket裡的值要小或相等）

注意這裡的sampling-rate, 這裡的值為1，表示讀取了表上所有的資料來進行統計，但通常對於大表而言，我們可能不希望讀太多的資料，因為可能產生過度的記憶體消耗，因此MySQL還提供了一個引數histogram_generation_max_mem_size 來限制記憶體的使用上限。

如果表上的DML不多，那直方圖基本是穩定的，但頻繁寫入的話，那我們就可能需要去定期更新直方圖，MySQL本身不會去主動更新。

優化器通過histogram來計算列的過濾性，大多數的謂詞都可以使用到。具體參閱官方文件

關於直方圖影響查詢計劃，這篇部落格 及這篇部落格

相關程式碼

程式碼結構：

以MySQL8.0.12為例，主要程式碼在sql/histogram目錄下:

ls sql/histograms/
equi_height_bucket.cc
equi_height_bucket.h
equi_height.cc
equi_height.hhistogram.cc
histogram.hsingleton.cc
singleton.h
value_map.cc
value_map.h
value_map_type.h


類結構：

namespace histograms
|---> Histogram//基類
|--> Equi_height //等高直方圖，模板類，例項化引數為資料型別，需要針對型別顯示定義
// 見檔案 "equi_height.cc"
|--> Singleton
//等寬直方圖，只有值和其出現的頻度被儲存下來

建立及儲存histogram:

處理histogram的相關函式和堆疊如下:

Sql_cmd_analyze_table::handle_histogram_command
|--> update_histogram//更新histogram
|-->histograms::update_histogram//呼叫namespace內的介面函式
a. 判斷各個列：
//histograms::field_type_to_value_map_type:檢查列型別是否支援
//covered_by_single_part_index: 如果列是Pk或者uk，不會為其建立histogram
//如果是generated column, 則找到其依賴的列加入到set中
b. 判斷取樣的半分比，這主要受引數histogram_generation_max_mem_size限制，如果設的足夠大，則會去讀取全表資料進行分析
|-> fill_value_maps//開始從表上讀取需要分析的列資料
|->ha_sample_init
|->ha_sample_next
|-->handler::sample_next //讀取下一條記錄，通過隨機數的方式來進行取樣
Value_map<T>::add_values // 將讀到的資料加入到map中
|->...
|->ha_sample_end

|-> build_histogram //建立histogram物件
a. 確定histogram型別：如果值的個數小於桶的個數，則使用Singleton，否則使用Equi_height型別
|->Singleton<T>::build_histogram
|->Equi_height<T>::build_histogram

|-> Histogram::store_histogram //將histogram資訊儲存到column_statistic表中
|-> dd::cache::Dictionary_client::update<dd::Column_statistics>

|--> drop_histogram //刪除直方圖

使用histogram

使用的方式就比較簡單了:

首先在表物件TABLE_SHARE中，增加成員m_histograms，其結構為一個unordered map，key值為field index, value為相應的histogram物件

獲取列值過濾性的相關堆疊如下：

get_histogram_selectivity
|-->Histogram::get_selectivity
|->get_equal_to_selectivity_dispatcher
|->get_greater_than_selectivity_dispatcher
|->get_less_than_selectivity_dispatcher
|-->write_histogram_to_trace // 寫到optimizer_trace中

MySQL支援多種操作型別對直方圖的使用，包括：

col_name = constant
col_name <> constant
col_name != constant
col_name > constant
col_name < constant
col_name >= constant
col_name <= constant
col_name IS NULL
col_name IS NOT NULL
col_name BETWEEN constant AND constant
col_name NOT BETWEEN constant AND constant
col_name IN (constant[, constant] ...)
col_name NOT IN (constant[, constant] ...)

通過直方圖，我們可以根據列上的條件判斷出列值的過濾性，來輔助選擇更優的執行計劃。在沒有直方圖之前我們需要通過在列上建立索引來獲得相對精確的列值分佈。但我們知道索引是有很大的維護開銷的，而直方圖則可以靈活的按需建立。

reference

其他

優化rec_per_key

MySQL通過rec_per_key 介面來估算記錄的個數（暗示每個索引Key對應的記錄個數），但在早前版本中這個數字是整數，對於小數會取整，不能表示準確的rec_per_key，從而影響到索引的選擇，因此在5.7版本中，將其記錄的值改成了float型別

引入資料cache狀態計算開銷

相關worklog:

在之前的版本中，優化器是無法知道資料的狀態，是否是cache在記憶體中，還是需要從磁碟讀出來的，缺乏這部分資訊，導致優化器統一認為資料屬於磁碟的來計算開銷。這可能導致低效的執行計劃。

相關程式碼：

server層新增api，用於獲取表或索引上有百分之多少的資料是儲存在cache中的

handler::table_in_memory_estimate
 handler::index_in_memory_estimate

而在innodb層，增加了一個全域性變數buf_stat_per_index (對應型別為buf_stat_per_index_t ) 來維護每個索引在記憶體中的leaf page個數, 其內部實現了一個lock-free的hash結構，Key值為(m_space_id) << 32 | m_index_id) , 在讀入page時或者記憶體中建立新page時， 如果對應的page是leaf page，就遞增計數；當從page hash中移除時，則遞減計數。

為了減少效能的影響，計數器是通過lock-free hash的結構儲存的，對應的結構為ut_lock_free_hash_t 。

基本的實現思路是：hash是一個定長的陣列，陣列元素為(key, val), 根據Key計算一個hash值再模上array size, 找到對應的槽位, 如果槽位被佔用了，則向右查詢一個空閒的slot。

當陣列滿了的時候，會建立一個新的更大的陣列，在資料還沒Move到這個新hash之前，所有的search都需要查詢兩個陣列。當所有的記錄到遷移到新陣列，並且沒有執行緒訪問老的陣列時，就可以把老的hash刪除掉了。

在hash中儲存的counter本身，也考慮到多核和numa架構，避免同時更新引起的cpu cache失效。在大量core的場景下這個問題可能很明顯。Innodb封裝計數操作到類ut_lock_free_cnt_t 中，使用陣列維護counter, 按照cpu no作為index更新，需要獲取counter值時則累加陣列中的值。

這個Lock free hash並不是個通用場景的hash結構：例如處理衝突的時候，可能佔用其他key的槽位，hash不夠用時，需要遷移到新的array中。實際上mysql本身實現了一個lf_hash，在擴充套件Hash時無需遷移資料，有空單獨開篇部落格講一下。

你可以從information_schema.innodb_cached_indexes 表中讀取到每個索引cache的page個數。

當定義好介面，並且Innodb提供相應的統計資料後，優化器就可以利用這些資訊來計算開銷：

• Cost_model_table::page_read_cost
• Cost_model_table::page_read_cost_index