[官方] mysql 性能优化文档（中英文自译）
大家好，我是烤鴨：
根據(jù)官方文檔翻譯并精簡部分內(nèi)容。建議有時間的朋友下載原版查看，全文106頁pdf，快的話1-2天就能看完。自己翻譯的有些地方可能不完整，歡迎指正。[官方] mysql 性能優(yōu)化文檔（中英文自譯）
- How to Analyze and Tune MySQL Queries for Better Performance `如何分析和調(diào)整MySQL查詢以獲得更好的性能`
- Program Agenda `目錄`
- Cost-based query optimization in MySQL `MySQL中基于成本的查詢優(yōu)化`
- Tools for monitoring, analyzing, and tuning queries `用于監(jiān)視，分析和調(diào)整查詢的工具 `
- Data access and index selection `數(shù)據(jù)訪問和索引選擇`
- Join optimizer `連接優(yōu)化器`
- Subqueries `子查詢`
- Sorting `排序`
- Influencing the optimizer `影響優(yōu)化器`
How to Analyze and Tune MySQL Queries for Better Performance 如何分析和調(diào)整MySQL查詢以獲得更好的性能
Program Agenda 目錄
Cost-based query optimization in MySQL MySQL中基于成本的查詢優(yōu)化
MySQL Optimizer mysql優(yōu)化器
通常的想法：
mysql優(yōu)化的特點：
- Produce the query plan that uses least resources IO and CPU
盡量減少CPU和I/O操作 - Optimizes a single query No inter-query optimizations
使用簡單的查詢,盡量少用嵌套的查詢 - Produces left-deep linear query execution plan
生成以左連接為主的線性查詢執(zhí)行計劃
Optimizer Cost Model 優(yōu)化器成本模型
圖 Optimizer Cost Mode
Cost Estimates 成本估算
- Cost unit:
“read a random data page from disk” 隨機(jī)從硬盤獲取"一頁"的數(shù)據(jù)
Main cost factors: - IO cost:
pages read from table：默認(rèn) 1.0
pages read from index：默認(rèn) 1.0 - CPU cost:
Evaluating query conditions：默認(rèn) 0.2
Comparing keys/records ：默認(rèn) 0.1，mysql 5.7以后可配置
圖 Cost Estimates
Cost Model Example 成本模型實例
- Table scan:全表掃描
- IO-cost: #pages in table * IO_BLOCK_READ_COST
IO成本：表中的pages * IO阻塞讀取成本 - CPU cost: #rows * ROW_EVALUATE_COST
CPU成本： 行 * 行計算成本
- IO-cost: #pages in table * IO_BLOCK_READ_COST
- Range scan (on secondary index): 范圍掃描(第二索引)
- IO-cost: #rows_in_range * IO_BLOCK_READ_COST
IO成本：范圍中的行 * IO阻塞讀取成本 - CPU cost: #rows_in_range * ROW_EVALUATE_COST
IO成本：范圍中的行 * 行計算成本
- IO-cost: #rows_in_range * IO_BLOCK_READ_COST
圖 Cost Model Example
圖 Cost Model Example: Optimizer Trace
圖 Cost Model vs Real World
圖 Cost Model Performance Schema
Tools for monitoring, analyzing, and tuning queries 用于監(jiān)視，分析和調(diào)整查詢的工具
- Useful tools
- MySQL Enterprise Monitor (MEM), Query Analyzer Commercial
product 付費產(chǎn)品 - Performance schema, MySQL sys schema
執(zhí)行計劃，MySQL 系統(tǒng)計劃
- MySQL Enterprise Monitor (MEM), Query Analyzer Commercial
- EXPLAIN
- Tabular EXPLAIN 表格式EXPLAIN
- Structured EXPLAIN (FORMAT=JSON)結(jié)構(gòu)式EXPLAIN 圖*2
- Visual EXPLAIN (MySQL Workbench)可視化EXPLAIN
- Optimizer trace 優(yōu)化器跟蹤
- Slow log 日志
- Status variables (SHOW STATUS LIKE ‘Sort%’) 狀態(tài)變量
MEM 圖形化界面，收費的，暫時不考慮了，看下面的例圖
圖 Query Analyzer
圖 Query Analyzer Query Details
Performance schema 執(zhí)行計劃
一些有用的表：
-
events_statements_history,events_statements_history_long Most
大部分最近執(zhí)行的statement
recent statements executed -
events_statements_summary_by_digest Summary for similar statements
總結(jié)相似操作（相同的statement合并）
(same statement digest) -
file_summary_by_event_name
-
Interesting event: wait/io/file/innodb/innodb_data_file
-
table_io_waits_summary_by_table
-
table_io_waits_summary_by_index_usage
-
Statistics on storage engine access per table and index
統(tǒng)計存儲引擎的每個表和索引
Statement events
-
Tables:(Current statement for each thread)
每個線程當(dāng)前執(zhí)行的statement -
events_statements_history (10 most recent statements per thread)
每個線程最近執(zhí)行的最多10條statement -
events_statements_history_long (10000 most recent statements)
最近執(zhí)行的最多10000statement -
Statement digest statement合并
-
Normalization of queries to group statements that are similar to be
grouped and summarized:規(guī)范化的按statement分組的查詢，類似于分組和匯總、如下：
events_statements_summary_by_digest
MySQL sys Schema 系統(tǒng)計劃
- A collection of views, procedures and functions, designed to make
reading raw Performance Schema data easier
一組視圖，過程和函數(shù)，旨在簡化讀取原始性能模式數(shù)據(jù) - Implements many common DBA and Developer use cases
實現(xiàn)許多常見的DBA和Developer用例- File IO usage per user 每個用戶的文件IO使用
- Which indexes is never used? 哪個索引從未被使用
- Which queries use full table scans? 哪些查詢是全表掃描
- Examples of very useful functions: 非常有用的函數(shù)示例
- format_time() , format_bytes(), format_statement()
- Included with MySQL 5.7 包含mysql 5.7
- Bundled with MySQL Workbench 與MySQL Workbench捆綁在一起
MySQL sys Schema MySQL 系統(tǒng)計劃
- statement_analysis ：Lists a normalized statement view with aggregated
statistics, ordered by the total execution time per normalized
statement （SELECT * FROM sys.statement_analysis LIMIT 1\G）
列出帶聚合的規(guī)范化語句視圖統(tǒng)計信息，按每個規(guī)范化語句的總執(zhí)行時間排序
EXPLAIN Understand the query plan
圖 EXPLAIN
Structured EXPLAIN （EXPLAIN FORMAT=JSON SELECT …）
圖 Structured EXPLAIN
Contains more information:
- Used index parts
- Pushed index conditions 觸發(fā)索引的條件
- Cost Estimates 成本估算
- Data estimates 數(shù)據(jù)估算
圖 Structured EXPLAIN
圖 MySQL sys Schema Example
Visual EXPLAIN 可視化EXPLAIN
圖 Visual EXPLAIN
Optimizer Trace: Query Plan Debugging 優(yōu)化程序跟蹤：查詢計劃調(diào)試
- EXPLAIN shows the selected plan EXPLAIN 展示了選擇的計劃
- Optimizer trace shows WHY the plan was selected
優(yōu)化跟蹤展示了為什么選這個計劃 SELECT * FROM t1,t2 WHERE f1=1 AND f1=f2 AND f2>0;SELECT trace FROM information_schema.optimizer_trace INTO OUTFILE <filename> LINES TERMINATED BY '';```SET optimizer_trace="enabled=off";
圖 Optimizer Trace Debugging
Data access and index selection 數(shù)據(jù)訪問和索引選擇
- Finding the optimal method to read data from storage engine
找到最合適的方式從儲存引擎讀取數(shù)據(jù) - For each table, find the best access method: 對于每個表，找到最佳訪問方法
- Check if the access method is useful 檢查訪問方法是否有用
- Estimate cost of using access method 估算使用訪問方法的成本
- Select the cheapest to be used 選擇最便宜的使用
- Choice of access method is cost based 訪問方法的選擇是基于成本的
- Ref Access 參考訪問
- Single Table Queries 單表查詢
圖 Ref Access Single Table Queries
Join Queries 連接查詢
圖 Ref Access Single Join Queries
Join Queries, continued 未命中的索引的連接查詢
圖 Ref Access Join Queries continued
- Range Optimizer 范圍優(yōu)化器
- Goal: find the “minimal” ranges for each index that needs to be read
目的： 找到需要讀取索引的"最小"變化
Example:
- Goal: find the “minimal” ranges for each index that needs to be read
圖 Ref Access Range Optimizer
- Range Optimizer, cont 范圍優(yōu)化器，常量
- Range optimizer selects the “useful” parts of the WHERE condition:
范圍優(yōu)化器選擇WHERE條件"有用的"部分- Conditions comparing a column value with a constant: 條件是一列和常量比較的數(shù)據(jù)
- Nested AND/OR conditions are supported 嵌套的AND/OR 是支持的
- Result: list of disjoint ranges that need to be read from index:結(jié)果： 沒有交集的范圍從索引讀取
- Range optimizer selects the “useful” parts of the WHERE condition:
- Cost estimate based on number of records in each range: 成本估算基于每個范圍的記錄數(shù)量
- Record estimate is found by asking the Storage Engine (“index dives”)
記錄估算通過詢問存儲引擎（"指數(shù)潛水"）獲取
- Record estimate is found by asking the Storage Engine (“index dives”)
Optimizer Trace show ranges 優(yōu)化程序跟蹤顯示范圍
圖 Optimizer Trace show ranges
Range Optimizer: Case Study 范圍優(yōu)化：案例學(xué)習(xí)
圖 Range Optimizer Case Study1
possible keys NULL 未使用索引
-
ndexed column is used as argument to function 索引列使用函數(shù)計算
YEAR(o_orderdate) = 1997 -
Looking for a suffix 尋找前綴
name LIKE '%son' -
First column(s) of compound index NOT used 符合索引的前置列未被使用
b = 10 when index defined over (a, b) 當(dāng)復(fù)合索引(a,b)，但是查詢條件是b = 10
-
Type mismatch 類型不匹配
my_string = 10 -
Character set / collation mismatch 字符集/排序規(guī)則不匹配
t1 LEFT JOIN t2 ON t1.utf8_string = t2. latin1_string
案例學(xué)習(xí):
例如：SELECT * FROM orders WHERE o_orderdate BETWEEN '1997-05-01' AND '1997-05-31' AND o_clerk = 'Clerk#000001866'; i_o_orderdate 命中索引
圖 Case Optimizer Case Study2
圖 Range Optimizer Case Study3
-
Range Access for Multi-Column Indexes 多列索引的范圍訪問
-
Example table with multi-part index 具有多部分索引的示例表 有索引abc ,index(a,b,c)
-
Logical storage layout of index: 索引的邏輯存儲布局：
圖 Range Access for Multi-Column Indexes
Range Access for Multi-Column Indexes, cont 多列索引的范圍訪問，常量
-
Equality on 1st index column？第一個索引列上的平等？
-
Can add condition on 2nd index column to range
condition？可以在第二個索引列上添加條件到范圍條件？例如：
SELECT * from t1 WHERE a IN (10,11,13) AND (b=2 OR b=4)
Resulting range scan 結(jié)果范圍掃描：
圖 Range Access for Multi-Column Indexes, cont
-
Non-Equality on 1st index column？ 第一個索引列上不平等？
-
Can NOT add condition on 2nd index column to range
condition？可以不在第二個索引列上添加條件到范圍條件？例如：
SELECT * from t1 WHERE a > 10 AND a < 13 AND (b=2 OR b=4)
Resulting range scan 結(jié)果范圍掃描：
圖 Range Access for Multi-Column Indexes, cont+
案例學(xué)習(xí):
- Create multi-column index 創(chuàng)建多列索引CREATE INDEX i_o_clerk_date ON orders(o_clerk, o_orderdate);
圖 Range Optimizer Case Study4
Performance Schema: Query History 執(zhí)行計劃：查詢歷史
mysql5.7 默認(rèn)enabled的。
圖 Performance Schema: Query History
Index Merge 索引合并
- Uses multiple indexes on the same table 同一張表使用多重索引
- Implemented index merge strategies 實施索引合并策略
- Index Merge Union 索引合并并集
- OR-ed conditions between different indexes 不同的索引之間使用OR條件
- Index Merge Intersection 索引合并交集
- AND conditions between different indexes 不同的索引之間的情況
- Index Merge Union 索引合并并集
- Index Merge Sort-Union 索引合并排序并集
- OR-ed conditions where condition is a range WHERE范圍條件使用OR
Index Merge Union 索引合并并集
- Single index cannot handle ORed conditions on different columns 單一索引不能處理不同列使用OR的情況
例如：
圖 Index Merge Union
Index Merge Intersection 索引合并交集
- Combine several indexes to reduce number of (or avoid) accesses to base table for ANDed conditions
在AND條件下組合多個索引以減少（或避免）對基表訪問次數(shù)
例如：
圖 Index Merge Intersection
Example1:
圖 Index Merge Intersection Example 1
Example2:
Beware of low-selectivity indexes! 注意低選擇性索引！
圖 Index Merge Intersection Example 2
Example3:
Handler status variables 處理程序狀態(tài)變量
圖 Index Merge Intersection Example 2+
Join optimizer 連接優(yōu)化器
”Greedy search strategy” 貪婪的搜索策略
目的: Given a JOIN of N tables, find the best JOIN ordering N張表中找到最好的連接排序
- Strategy: 策略：
- Start with all 1-table plans (Sorted based on size and key dependency)
從所有1表計劃開始（根據(jù)大小和密鑰依賴性排序） - Expand each plan with remaining tables 用剩余的表擴(kuò)展每個計劃
- Depth-first 深度優(yōu)先
- If “cost of partial plan” > “cost of best plan”: 如果"部分計劃成本" > "最好的計劃成本"
- “prune” plan 精簡計劃
- Start with all 1-table plans (Sorted based on size and key dependency)
- Heuristic pruning: 探索式精簡
- Prune less promising partial plans 精簡沒什么用的部分計劃
- May in rare cases miss most optimal plan (turn off with set optimizer_prune_level = 0)
可能在極少數(shù)情況下錯過最佳計劃 (關(guān)閉并設(shè)置 optimizer_prune_level = 0)
JOIN Optimizer Illustrated 連接優(yōu)化器插圖
圖 Join Optimizer
Change join order with STRAIGHT_JOIN 使用STRAIGHT_JOIN更改連接順序
圖 Join Optimizer+
Join Order 連接順序
圖 Join Order
Join Order Hints 連接順序提示
MySQL 8.0 Optimizer Labs Release MySQL 8.0優(yōu)化工具實驗室發(fā)布
- Alternatives with same effect for this query: 對此查詢具有相同效果的替代方案
圖 Join Order Hints
National Market Share Query 全國市場份額查詢
SELECT o_year, SUM(CASE WHEN nation = 'FRANCE' THEN volume ELSE 0 END) / SUM(volume) AS mkt_shareFROM (SELECT EXTRACT(YEAR FROM o_orderdate) AS o_year, l_extendedprice * (1 - l_discount) AS volume, n2.n_name AS nationFROM partJOIN nation n2 ON s_nationkey = n2.n_nationkey JOIN region ON n1.n_regionkey = r_regionkey JOIN nation n1 ON c_nationkey = n1.n_nationkey JOIN customer ON o_custkey = c_custkey JOIN orders ON l_orderkey = o_orderkey JOIN supplier ON s_suppkey = l_suppkey JOIN lineitem ON p_partkey = l_partkey WHERE r_name = 'EUROPE' AND o_orderdate BETWEEN '1995-01-01' AND '1996-12-31' AND p_type = 'PROMO BRUSHED STEEL') AS all_nations GROUP BY o_year ORDER BY o_year;MySQL Workbench Visual EXPLAIN MySQL Workbench 可視化 EXPLAIN
圖 MySQL Workbench: Visual EXPLAIN
Force early processing of high selectivity conditions 強制早期處理高選擇性條件
圖 Force early processing of high selectivity conditions
Improved join order 優(yōu)化連接順序
圖 Improved join order
- Improvements to Query 8 in MySQL 5.7: mysql 5.7 對Query8的優(yōu)化
- Filtering on non-indexed columns are taken into account 考慮對非索引列進(jìn)行過濾
- No need for hint to force part table to be processed early 部分表強制提前處理無需提示
- Merge derived tables into outer query 將派生表合并到外部查詢中
- No temporary table 無臨時表
Subqueries 子查詢
Overview of Subquery Optimizations 子查詢優(yōu)化概述
| IN (SELECT …) | Semi-join 半連接Materialization 實體化 |
| NOT IN (SELECT …) | IN ? EXISTS |
| FROM (SELECT …) | Merged 合并 Materialized 實體化 |
| ALL/ANY (SELECT …) | MAX/MIN re-write 最大/最小化 重寫 |
| EXISTS/other | Execute subquery 執(zhí)行子查詢 |
圖 Subquery category
- Traditional Optimization of IN Subqueries IN子查詢的傳統(tǒng)優(yōu)化
- IN -> EXISTS transformation IN 轉(zhuǎn)化為 EXISTS
- Convert IN subquery to EXISTS subquery by “push-down” IN-equality to
subquery 從IN子查詢轉(zhuǎn)化為EXISTS子查詢通過"向下"的同等子查詢 SELECT title FROM film WHERE film_id IN (SELECT film_id FROM actor WHERE name=“Bullock”) 優(yōu)化為 =>SELECT title FROM filmWHERE EXISTS (SELECT 1 FROM actor WHERE name=“Bullock” AND film.film_id = actor.film_id) - Benefit: subquery will evaluate fewer records 優(yōu)點：子查詢將計算更少的記錄
- Note: Special handling if pushed down expressions can be NULL 注意：如果"向下"表達(dá)式為NULL，則可特殊處理
Semi-join 半連接
-
Convert subquery to inner join, BUT Need some way to remove duplicates
將子查詢轉(zhuǎn)換為內(nèi)連接 但需要一些方法去重 -
Different strategies for duplicate removal: 去重的不同策略
- FirstMatch (equivalent to IN→EXISTS execution) 匹配優(yōu)先（等價于IN—>EXISTS的方式）
- LooseScan (index scan, skip duplicates) 懶掃描（索引掃描，跳過重復(fù)）
- Materialization: MatLookup (like subquery materialization), MatScan
(materialized table is first in join order)
實體化：MatLookup(像子查詢實體化)，MatScan（實體化表在連接順序的第一位） - Duplicate WeedOut (insert result rows of semi-join query into
temporary table with unique index; duplicate rows will be rejected.
Any join order.) 去重（用唯一索引將半連接的行插入臨時表；重復(fù)列將會被拒絕。無論連接順序）
-
If duplicate removal is not necessary: 如果去重是非必須的話
- Table pull-out 表將刪掉
Main advantage ： 主要優(yōu)勢：
- Opens up for more optimal ”join orders” 有更多優(yōu)化"連接順序"的選擇
例如： SELECT o_orderdate, o_totalprice FROM orders WHERE o_orderkey IN (SELECT l_orderkey FROM lineitem WHERE l_shipDate='1996-09-30');- Will process less rows if starting with lineitem instead of orders 使用行代替排序會經(jīng)過較少的行
- Restriction: 限制：
- Cannot use semi-join if subquery contains union or aggregation
如果子查詢包含union（并集）或者aggregation（聚合）不能使用半連接
- Cannot use semi-join if subquery contains union or aggregation
MySQL 5.6: Semi-join: Example mysql5.6 半攔截的例子：
圖 MySQL 5.6: Semi-join: Example
MySQL 5.7: Hint Example: SEMIJOIN 提示示例: 半連接
- No hint, optimizer chooses semi-join algorithm LooseScan: 沒有提示，優(yōu)化器選擇半連接算法LooseScan
- Disable semi-join with hint: 使用提示禁用半連接：
圖 Hint Example: SEMIJOIN
- Subquery Materialization 子查詢實體化
- Execute subquery once and store result in a temporary table 執(zhí)行一次子查詢并在臨時表中存結(jié)果
- Table has unique index for quick look-up and duplicate removal 表有唯一索引可以快速查找并去重
- Execute outer query and check for matches in temporary table 執(zhí)行外部查詢并檢查臨時表中的匹配項
圖 Subquery Materialization
比較子查詢實現(xiàn)和IN?EXISTS 比較IN —> EXISTS的實現(xiàn)
圖 Comparing Subquery Materialization
圖 Subquery Materialization+
Derived Tables 派生表
- Subquery in FROM clause FROM子句中的子查詢SELECT AVG(o_totalprice) FROM ( SELECT * FROM orders ORDER BY o_totalprice DESC LIMIT 100000 ) td;
- MySQL 5.6 and earlier: Executed separately and result stored in a
temporary table (materialization) MySQL 5.6及更早版本：單獨執(zhí)行并將結(jié)果存儲在臨時表中（實現(xiàn)） - MySQL 5.7: Treat derived tables like views: May be merged with outer
query block MySQL 5.7：處理類似于視圖的派生表：可以與外部查詢塊合并
圖 Index on Materialized Derived Table
圖 Materialization of Derived Tables EXPLAIN
- Merge Derived Table with Outer Query 用外部連接合并派生表
- Derived tables based on GROUP BY, DISTINCT, LIMIT, or aggregate
functions will not be merged 基于GROUP BY，DISTINCT，LIMIT或聚合函數(shù)的派生表將不會合并
- Derived tables based on GROUP BY, DISTINCT, LIMIT, or aggregate
圖 Merge Derived Table with Outer Query
Hint: Merge/Materialize Derived Table or View 暗示：合并/實現(xiàn)派生表或視圖
- MySQL 8.0.0 optimizer labs release MySQL 8.0.0優(yōu)化器實驗室發(fā)布
-
Derived tables/views are, if possible, merged into outer query 如果可能，派生表/視圖將合并到外部查詢中
-
NO_MERGE hint can be used to override default behavior: NO_MERGE提示可用于覆蓋默認(rèn)行為：
- SELECT /*+ NO_MERGE(dt) */ * FROM t1 JOIN (SELECT x, y FROM t2) dt ON t1.x = dt.x;
-
MERGE hint will force a merge MERGE提示將強制合并
- SELECT /*+ MERGE(dt) */ * FROM t1 JOIN (SELECT x, y FROM t2) dt ON t1.x = dt.x;
-
Can also use MERGE/NO_MERGE hints for views 也可以使用MERGE / NO_MERGE提示查看視圖
- SELECT /*+ NO_MERGE(v) */ * FROM t1 JOIN v ON t1.x = v.x;
-
Sorting 排序
ORDER BY Optimizations 排序優(yōu)化
- General solution; “Filesort”: 通常的解決方案；"文件排序"
- Store query result in temporary table before sorting 在排序之前將查詢結(jié)果存儲在臨時表中
- If data volume is large, may need to sort in several passes with intermediate storage on disk.
如果數(shù)據(jù)量很大，可能需要在磁盤上使用中間存儲進(jìn)行多次傳遞排序
- Optimizations ： 優(yōu)化
- Take advantage of index to generate query result in sorted order 利用索引按排序順序生成查詢結(jié)果
- For ”LIMIT n” queries, maintain priority queue of n top items in
memory instead of filesort. (MySQL 5.6)
對于"LIMIT n查詢，保留內(nèi)存中n個頂級項的優(yōu)先級隊列而不是文件排序。 （MySQL 5.6）
Filesort 文件排序：
圖 Filesort
Status variables 狀態(tài)變量
圖 Filesort+
Performance Schema 執(zhí)行計劃
圖 Filesort Performance Schema
Sorting status per statement available from Performance Schema 可從執(zhí)行計劃中對每個語句進(jìn)行排序
案例1
圖 Filesort Case Study1
案例2
圖 Filesort Case Study2
案例3
圖 Filesort Case Study3
Increase sort buffer 增加排序緩沖區(qū)
SET sort_buffer_size = 1024*1024 默認(rèn)256 KB。
案例4
圖 Filesort Case Study4
Increase sort buffer even more (8MB) 進(jìn)一步增加排序緩沖區(qū) (8MB)
SET sort_buffer_size = 8*1024*1024;
圖 Using Index to Avoid Sorting
Using Index to Avoid Sorting 使用索引來避免排序
圖 Using Index to Avoid Sorting Case study
Case study revisited 重新研究案例
Influencing the optimizer 影響優(yōu)化器
- Add indexes 添加索引
- Force use of specific indexes: 強制使用特定的索引
- USE INDEX, FORCE INDEX, IGNORE INDEX 使用索引，強制索引，忽略索引
- Force specific join order: 強制特定的關(guān)聯(lián)順序
- STRAIGHT_JOIN
- Adjust session variables 調(diào)整會話變量
- optimizer_switch flags: set optimizer_switch=“index_merge=off”
- Buffer sizes: set sort_buffer=810241024;
- Other variables: set optimizer_search_depth = 10;
MySQL 5.7: New Optimizer Hints MySQL 5.7：新的優(yōu)化器暗示
-
Ny hint syntax:暗示語法：
SELECT /*+ HINT1(args) HINT2(args) */ … FROM … -
New hints: 新的暗示：
- BKA(tables)/NO_BKA(tables), BNL(tables)/NO_BNL(tables)
- Batched Key Access (BKA) 批量key訪問 Block Nested-Loop (BNL) 阻塞嵌套循環(huán)算法
- MRR(table indexes)/NO_MRR(table indexes) (表的索引)
- SEMIJOIN/NO_SEMIJOIN(strategies), SUBQUERY(strategy)
- NO_ICP(table indexes)
- Index Condition Pushdown (ICP) 索引命中情況下推
- NO_RANGE_OPTIMIZATION(table indexes) 索引情況下該范圍沒有可優(yōu)化的
- QB_NAME(name) Query Block 查詢阻塞
- BKA(tables)/NO_BKA(tables), BNL(tables)/NO_BNL(tables)
-
Finer granularilty than optimizer_switch session variable 比optimizer_switch會話變量更精細(xì)
Optimizer Hints
- Future ：
- New hints in 8.0.0 Optimizer Labs Release Optimizer Labs 8.0.0 版本中的新暗示
- Enable/disable merge of views and derived tables: 啟用/禁用視圖和派生表的合并
- MERGE() NO_MERGE()
- Join order 連接順序
- JOIN_ORDER(tables) JOIN_PREFIX(tables) JOIN_SUFFIX(tables) JOIN_FIXED_ORDER()
- Hints we consider to add 考慮添加的暗示：
- Force/ignore index_merge Alternatives 強制/忽略index_merge替代方案
- Reimplement index hints in new syntax 重新實現(xiàn)新語法中的索引暗示
- Temporarily set session variables for just one query 暫時為一個查詢設(shè)置會話變量
MySQL 5.7: Query Rewrite Plugin 查詢重寫插件
-
Rewrite problematic queries without the need to make application
changes 無需更改應(yīng)用程序即可重寫有問題的查詢 -
Add hints 添加暗示
- Modify join order 更新連接順序
- Much more … 更多
-
Add rewrite rules to table: 向表中添加重寫規(guī)則：
圖 Query Rewrite Plugin
- New pre- and post-parse query rewrite APIs 新的解析前和解析后查詢重寫API
MySQL 5.7: Adjustable Cost Constants 可調(diào)成本常量
Experimental! Use with caution! No guarantees 實驗！ 謹(jǐn)慎使用！ 不保證!！
圖 Adjustable Cost Constants
圖 Adjustable Cost Constants+
總結(jié)
以上是生活随笔為你收集整理的[官方] mysql 性能优化文档（中英文自译）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java 二进制文件修改_Java读写二
- 下一篇： elasticsearch解决同步删除数