這篇文章主要介紹“MySQL8.0優(yōu)化器新特性是什么”，在日常操作中，相信很多人在MySQL8.0優(yōu)化器新特性是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”MySQL8.0優(yōu)化器新特性是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

創(chuàng)新互聯(lián)公司從2013年開始，先為龍子湖等服務(wù)建站，龍子湖等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為龍子湖企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

為什么需要配置cost model常量 ? 我們知道MySQL已經(jīng)發(fā)展了好幾十年的歷史，但是在優(yōu)化器中依然使用了hardcode的權(quán)重值來衡量io, cpu等資源情況，而這些權(quán)重值實際上是基于多年前甚至十來年前的經(jīng)驗設(shè)定的。想想看，這么多年硬件的發(fā)展多么迅速。幾十上百個核心的服務(wù)器不在少數(shù)甚至在某些大型公司大規(guī)模使用，ssd早就成為主流，NVME也在崛起。高速RDMA網(wǎng)絡(luò)正在走入尋常百姓家。這一切甚至影響到數(shù)據(jù)庫系統(tǒng)的實現(xiàn)和變革。顯而易見，那些hardcode的權(quán)值已經(jīng)過時了，我們需要提供給用戶可定義的方式，甚至更進一步的，能夠智能的根據(jù)硬件環(huán)境自動設(shè)定。

MySQL5.7引入兩個新的系統(tǒng)表, 通過這兩個系統(tǒng)表暴露給用戶來進行更新，如下：

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，其表達式已經(jīng)固定死了默認值：

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: 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)

//更新后執(zhí)行一次flush optimizer_costs操作來更新內(nèi)存
//但老的session還是會用老的cost數(shù)據(jù)
root@(none) 10:10:12>flush optimizer_costs;
Query OK, 0 rows affected (0.00 sec)
可以看到用法也非常簡單，上面包含了兩張表：server_cost及engine_cost，分別對server層和引擎層進行配置

相關(guān)代碼:
全局cache Cost_constant_cache
全局cache維護了一個當前的cost model信息, 用戶線程在lex_start時會去判斷其有沒有初始化本地指針，如果沒有的話就去該cache中將指針拷貝到本地

初始化全局cache:

Cost_constant_cache::init
:

創(chuàng)建Cost_model_constants， 其中包含了兩類信息: server層cost model和引擎層cost model, 類結(jié)構(gòu)如下：

Cost_constant_cache ----> Cost_model_constants
---> Server_cost_constants
//server_cost
---> Cost_model_se_info 
--->SE_cost_constants
//engine_cost 如果存儲引擎提供了接口函數(shù)get_cost_constants的話,則從存儲引擎那取

從系統(tǒng)表讀取配置，適用于初始化和flush optimizer_costs并更新cache：

read_cost_constants()
|--> read_server_cost_constants
|--> read_engine_cost_constants
由于用戶可以動態(tài)的更新系統(tǒng)表，執(zhí)行完flush optimizer_costs后，有可能老的版本還在被某些session使用，因此需要引用計數(shù)，老的版本ref counter被降為0后才能被釋放

線程cost model初始化
Cost_model_server
在每個線程的thd上，掛了一個Cost_model_server的對象THD::m_cost_model, 在lex_start()時，如果發(fā)現(xiàn)線程的m_cost_model沒有初始化，就會去獲取全局的指針，存儲到本地：

Cost_model_server::init

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

const Server_cost_constants *m_server_cost_constants = m_cost_constants->get_server_cost_constants();
// 同樣獲取的是全局指針
可見thd不創(chuàng)建自己的cost model, 只引用cache中的指針

Table Cost Model
struct TABLE::m_cost_model, 類型：Cost_model_table

其值取自上述thd中存儲的cost model對象

Cost_estimate
統(tǒng)一的對象類型cost_estimate來存儲計算的cost結(jié)果，包含四個維度：

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)
未來
目前來看，除非根據(jù)工作負載，經(jīng)過充分的測試才能得出合理的配置值，但如何配置，什么是合理的值，個人認為應(yīng)該是可以自動調(diào)整配置的。關(guān)鍵是找出配置和硬件條件的對應(yīng)關(guān)系。 這也是我們未來可以努力的一個方向。

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

Related Worklog:
WL#7182: Optimizer Cost Model API 
WL#7209: Handler interface changes for new cost model
WL#7276: Configuration data base for Optimizer Cost Model
WL#7315 Optimizer cost model: main memory management of cost constants
WL#7316 Optimizer cost model: Command for online updating of cost model constants

Histogram
直方圖也是MySQL一個萬眾期待的功能了，這個功能實際上在其他數(shù)據(jù)庫產(chǎn)品中是很常見的，可以很好的指導(dǎo)優(yōu)化器選擇執(zhí)行路徑。利用直方圖存儲了指定列的數(shù)據(jù)分布。MariaDB從很早的10.0.2版本支持這個功能， 而MySQL在最新的8.0版本中也開始支持

使用
MySQL里使用直方圖是通過ANALYZE TABLE語法來執(zhí)行：

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)

創(chuàng)建直方圖并存儲到數(shù)據(jù)詞典中

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的數(shù)量是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)

直方圖統(tǒng)計信息存儲于InnoDB數(shù)據(jù)詞典中，可以通過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_statisticswhere 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系統(tǒng)表，但被隱藏了，沒有對外暴露

以下舉個簡單的例子：

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可以看到，在執(zhí)行了上述語句后產(chǎn)生的直方圖，有4個bucket，數(shù)據(jù)類型為Int, 類型為equi-height，即等高直方圖(另外一種是等寬直方圖，即SINGLETON)。每個Bucket中，描述的信息包括：數(shù)值的上界和下界, 頻率以及不同值的個數(shù)。通過這些信息可以獲得比較精確的數(shù)據(jù)分布情況，從而優(yōu)化器來根據(jù)這些統(tǒng)計信息決定更優(yōu)的執(zhí)行計劃。

如果列上存在大量的重復(fù)值，那么MySQL也可能選擇等寬直方圖，例如上例，我們將列k上的值更新為一半10一半為20， 那么出來的直方圖數(shù)據(jù)如下：

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只包含兩個值：列值，及對應(yīng)的累計頻率（即百分之多少的數(shù)據(jù)比當前Bucket里的值要小或相等）

注意這里的sampling-rate, 這里的值為1，表示讀取了表上所有的數(shù)據(jù)來進行統(tǒng)計，但通常對于大表而言，我們可能不希望讀太多的數(shù)據(jù)，因為可能產(chǎn)生過度的內(nèi)存消耗，因此MySQL還提供了一個參數(shù)histogram_generation_max_mem_size來限制內(nèi)存的使用上限。

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

優(yōu)化器通過histogram來計算列的過濾性，大多數(shù)的謂詞都可以使用到。具體參閱官方文檔

關(guān)于直方圖影響查詢計劃，這篇博客 及 這篇博客

相關(guān)代碼
代碼結(jié)構(gòu)：
以MySQL8.0.12為例，主要代碼在sql/histogram目錄下:

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

類結(jié)構(gòu)：

namespace histograms
|---> Histogram //基類
|--> Equi_height //等高直方圖，模板類，實例化參數(shù)為數(shù)據(jù)類型，需要針對類型顯示定義
// 見文件 "equi_height.cc"
|--> Singleton
//等寬直方圖，只有值和其出現(xiàn)的頻度被存儲下來
創(chuàng)建及存儲histogram:

處理histogram的相關(guān)函數(shù)和堆棧如下:

Sql_cmd_analyze_table::handle_histogram_command
|--> update_histogram //更新histogram
|-->histograms::update_histogram //調(diào)用namespace內(nèi)的接口函數(shù)
a. 判斷各個列：
//histograms::field_type_to_value_map_type: 檢查列類型是否支持
//covered_by_single_part_index: 如果列是Pk或者uk，不會為其創(chuàng)建histogram
//如果是generated column, 則找到其依賴的列加入到set中
b. 判斷取樣的半分比，這主要受參數(shù)histogram_generation_max_mem_size限制，如果設(shè)的足夠大，則會去讀取全表數(shù)據(jù)進行分析
|-> fill_value_maps //開始從表上讀取需要分析的列數(shù)據(jù)
|->ha_sample_init
|->ha_sample_next
|--> handler::sample_next //讀取下一條記錄，通過隨機數(shù)的方式來進行取樣
Value_map<T>::add_values // 將讀到的數(shù)據(jù)加入到map中
|->...
|->ha_sample_end

    |-> build_histogram //創(chuàng)建histogram對象
    a. 確定histogram類型：如果值的個數(shù)小于桶的個數(shù)，則使用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，其結(jié)構(gòu)為一個unordered map，key值為field index, value為相應(yīng)的histogram對象

獲取列值過濾性的相關(guān)堆棧如下：

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] ...)
通過直方圖，我們可以根據(jù)列上的條件判斷出列值的過濾性，來輔助選擇更優(yōu)的執(zhí)行計劃。在沒有直方圖之前我們需要通過在列上建立索引來獲得相對精確的列值分布。但我們知道索引是有很大的維護開銷的，而直方圖則可以靈活的按需創(chuàng)建。

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

其他
優(yōu)化rec_per_key
相關(guān)worklog:
WL#7338: Interface for improved records per key estimates
WL#7339 Use improved records per key estimate interface in optimizer

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

引入數(shù)據(jù)cache狀態(tài)計算開銷
相關(guān)worklog:

WL#7168 API for estimates for how much of table and index data that is in memory buffer
WL#7170: InnoDB buffer estimates for tables and indexes
WL#7340 IO aware cost estimate function for data access

在之前的版本中，優(yōu)化器是無法知道數(shù)據(jù)的狀態(tài)，是否是cache在內(nèi)存中，還是需要從磁盤讀出來的，缺乏這部分信息，導(dǎo)致優(yōu)化器統(tǒng)一認為數(shù)據(jù)屬于磁盤的來計算開銷。這可能導(dǎo)致低效的執(zhí)行計劃。

相關(guān)代碼：

server層新增api，用于獲取表或索引上有百分之多少的數(shù)據(jù)是存儲在cache中的

handler::table_in_memory_estimate
handler::index_in_memory_estimate
而在innodb層，增加了一個全局變量buf_stat_per_index (對應(yīng)類型為buf_stat_per_index_t) 來維護每個索引在內(nèi)存中的leaf page個數(shù), 其內(nèi)部實現(xiàn)了一個lock-free的hash結(jié)構(gòu)，Key值為(m_space_id) << 32 | m_index_id), 在讀入page時或者內(nèi)存中創(chuàng)建新page時， 如果對應(yīng)的page是leaf page，就遞增計數(shù)；當從page hash中移除時，則遞減計數(shù)。

為了減少性能的影響，計數(shù)器是通過lock-free hash的結(jié)構(gòu)存儲的，對應(yīng)的結(jié)構(gòu)為ut_lock_free_hash_t。
基本的實現(xiàn)思路是：hash是一個定長的數(shù)組，數(shù)組元素為(key, val), 根據(jù)Key計算一個hash值再模上array size, 找到對應(yīng)的槽位, 如果槽位被占用了，則向右查找一個空閑的slot。
當數(shù)組滿了的時候，會創(chuàng)建一個新的更大的數(shù)組，在數(shù)據(jù)還沒Move到這個新hash之前，所有的search都需要查詢兩個數(shù)組。當所有的記錄到遷移到新數(shù)組，并且沒有線程訪問老的數(shù)組時，就可以把老的hash刪除掉了。

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

這個Lock free hash并不是個通用場景的hash結(jié)構(gòu)：例如處理沖突的時候，可能占用其他key的槽位，hash不夠用時，需要遷移到新的array中。實際上mysql本身實現(xiàn)了一個lf_hash，在擴展Hash時無需遷移數(shù)據(jù)，有空單獨開篇博客講一下。

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

當定義好接口，并且Innodb提供相應(yīng)的統(tǒng)計數(shù)據(jù)后，優(yōu)化器就可以利用這些信息來計算開銷：

Cost_model_table::page_read_cost
Cost_model_table::page_read_cost_index

到此，關(guān)于“MySQL8.0優(yōu)化器新特性是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

文章標題：MySQL8.0優(yōu)化器新特性是什么
網(wǎng)頁URL：http://chinadenli.net/article0/pgpdoo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計公司、商城網(wǎng)站、企業(yè)建站、電子商務(wù)、服務(wù)器托管、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)