MySQL8.0 · 优化器新特性 · Cost Model, 直方图及优化器开销优化

时间 2019-12-05

标签 mysql8.0 mysql 优化特性 cost model 直方图开销栏目 MySQL 繁體版

原文原文链接

MySQL当前已经发布到MySQL8.0版本，在新的版本中，能够看到MySQL以前被人诟病的优化器部分作了不少的改动，因为笔者以前的工做环境是5.6，最近切换到最新的8.0版本，本文涵盖了一些本人感兴趣的和优化器相关的部分，主要包括MySQL5.7的cost model以及MySQL8.0的直方图功能。html

本文基于当前最新的MySQL8.0.12版本，主要是讲下cost model 和 histogram的用法和相关代码mysql

Cost Model

Configurable cost constants

为何须要配置cost model常量 ? 咱们知道MySQL已经发展了好几十年的历史，可是在优化器中依然使用了hardcode的权重值来衡量io, cpu等资源状况，而这些权重值其实是基于多年前甚至十来年前的经验设定的。想一想看，这么多年硬件的发展多么迅速。几十上百个核心的服务器不在少数甚至在某些大型公司大规模使用，ssd早就成为主流，NVME也在崛起。高速RDMA网络正在走入寻常百姓家。这一切甚至影响到数据库系统的实现和变革。显而易见，那些hardcode的权值已通过时了，咱们须要提供给用户可定义的方式，甚至更进一步的，可以智能的根据硬件环境自动设定。sql

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语句来进行更新, 例如：json

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: 1  Changed: 1  Warnings: 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层和引擎层进行配置api

将来

目前来看，除非根据工做负载，通过充分的测试才能得出合理的配置值，但如何配置，什么是合理的值，我的认为应该是能够自动调整配置的。关键是找出配置和硬件条件的对应关系。这也是咱们将来能够努力的一个方向。

reference:

1. Cost Model官方文档
 2. 官方博客1:The MySQL Optimizer Cost Model Project
3. 官方博客2: A new dimension to MySQL query optimizations
4. Optimizer Cost Model Improvements in MySQL 5.7.5 DMR
5.Slide: MySQL Cost Model

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来计算列的过滤性，大多数的谓词均可以使用到。具体参阅官方文档

关于直方图影响查询计划，这篇博客及这篇博客

reference

WL#5384 PERFORMANCE_SCHEMA, HISTOGRAMS
WL#8706 Persistent storage of Histogram data
WL#8707 Classes/structures for Histograms
WL#8943 Extend ANALYZE TABLE with histogram support
WL#9223 Using histogram statistics in the optimizer

其余

优化rec_per_key

MySQL经过rec_per_key 接口来估算记录的个数（暗示每一个索引Key对应的记录个数），但在早前版本中这个数字是整数，对于小数会取整，不能表示准确的rec_per_key，从而影响到索引的选择，所以在5.7版本中，将其记录的值改为了float类型

MySQL8.0 · 优化器新特性 · Cost Model, 直方图及优化器开销优化

Cost Model

Configurable cost constants

相关代码:

全局cache Cost_constant_cache

线程cost model初始化

Table Cost Model

Cost_estimate

将来

reference:

Histogram

使用

相关代码

reference

其余

优化rec_per_key

引入数据cache状态计算开销