大家好，我是烤鴨：

根據官方文檔翻譯并精簡部分內容。建議有時間的朋友下載原版查看，全文106頁pdf，快的話1-2天就能看完。自己翻譯的有些地方可能不完整，歡迎指正。

官方pdf下載，需登錄：

https://www.mysql.com/cn/why-mysql/presentations/tune-mysql-queries-performance/

csdn下載地址：

https://download.csdn.net/download/angry_mills/10953302

簡化版地址：

https://blog.csdn.net/Angry_Mills/article/details/88081834

[官方] mysql 性能優化文檔（中英文自譯）

• How to Analyze and Tune MySQL Queries for Better Performance `如何分析和調整MySQL查詢以獲得更好的性能`
• Program Agenda `目錄`
• • Cost-based query optimization in MySQL `MySQL中基于成本的查詢優化`
  • Tools for monitoring, analyzing, and tuning queries `用于監視，分析和調整查詢的工具 `
  • Data access and index selection `數據訪問和索引選擇`
  • Join optimizer `連接優化器`
  • Subqueries `子查詢`
  • Sorting `排序`
  • Influencing the optimizer `影響優化器`

How to Analyze and Tune MySQL Queries for Better Performance 如何分析和調整MySQL查詢以獲得更好的性能

Program Agenda 目錄

Cost-based query optimization in MySQL MySQL中基于成本的查詢優化

MySQL Optimizer mysql優化器

通常的想法：

Assign cost to operations 將成本分配到操作

Assign cost to partial or alternative plans 將成本分配到部分或替代計劃

Search for plan with lowest cost 搜索成本最低的計劃

Cost-based optimizations 基于成本的優化

Access method 訪問方式Subquery strategy 子查詢策略Join order 連接順序

mysql優化的特點：

• 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
  生成以左連接為主的線性查詢執行計劃

Optimizer Cost Model 優化器成本模型

圖 Optimizer Cost Mode

Cost Estimates 成本估算

• Cost unit:
  “read a random data page from disk” 隨機從硬盤獲取"一頁"的數據
  Main cost factors:
• IO cost:
  pages read from table：默認 1.0
  pages read from index：默認 1.0
• CPU cost:
  Evaluating query conditions：默認 0.2
  Comparing keys/records ：默認 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成本： 行 * 行計算成本
• 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成本：范圍中的行 * 行計算成本

圖 Cost Model Example

圖 Cost Model Example: Optimizer Trace

圖 Cost Model vs Real World

圖 Cost Model Performance Schema

Tools for monitoring, analyzing, and tuning queries 用于監視，分析和調整查詢的工具

• Useful tools
  • MySQL Enterprise Monitor (MEM), Query Analyzer Commercial
    product 付費產品
  • Performance schema, MySQL sys schema
    執行計劃，MySQL 系統計劃
• EXPLAIN
  • Tabular EXPLAIN 表格式EXPLAIN
  • Structured EXPLAIN (FORMAT=JSON)結構式EXPLAIN 圖*2
    
  • Visual EXPLAIN (MySQL Workbench)可視化EXPLAIN
    
  • Optimizer trace 優化器跟蹤
  • Slow log 日志
  • Status variables (SHOW STATUS LIKE ‘Sort%’) 狀態變量

MEM 圖形化界面，收費的，暫時不考慮了，看下面的例圖

圖 Query Analyzer

圖 Query Analyzer Query Details

Performance schema 執行計劃
一些有用的表：

• events_statements_history,events_statements_history_long Most
  recent statements executed

  大部分最近執行的statement

• events_statements_summary_by_digest Summary for similar statements
  (same statement digest)

  總結相似操作（相同的statement合并）

• 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

  統計存儲引擎的每個表和索引

Statement events

• Tables:(Current statement for each thread)
  每個線程當前執行的statement

• events_statements_history (10 most recent statements per thread)
  每個線程最近執行的最多10條statement

• events_statements_history_long (10000 most recent statements)
  最近執行的最多10000statement

• Statement digest statement合并

• Normalization of queries to group statements that are similar to be
  grouped and summarized:

  規范化的按statement分組的查詢，類似于分組和匯總、如下：

SELECT * FROM orders WHERE o_custkey=10 AND o_totalprice>20 SELECT * FROM orders WHERE o_custkey = 20 AND o_totalprice > 100 SELECT * FROM orders WHERE o_custkey = ? AND o_totalprice > ?

events_statements_summary_by_digest
MySQL sys Schema 系統計劃

• A collection of views, procedures and functions, designed to make
  reading raw Performance Schema data easier
  一組視圖，過程和函數，旨在簡化讀取原始性能模式數據
• Implements many common DBA and Developer use cases
  實現許多常見的DBA和Developer用例
  • File IO usage per user 每個用戶的文件IO使用
  • Which indexes is never used? 哪個索引從未被使用
  • Which queries use full table scans? 哪些查詢是全表掃描
• Examples of very useful functions: 非常有用的函數示例
  • format_time() , format_bytes(), format_statement()
• Included with MySQL 5.7 包含mysql 5.7
• Bundled with MySQL Workbench 與MySQL Workbench捆綁在一起

MySQL sys Schema MySQL 系統計劃

• 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）
  列出帶聚合的規范化語句視圖統計信息，按每個規范化語句的總執行時間排序

EXPLAIN Understand the query plan

圖 EXPLAIN

Structured EXPLAIN （EXPLAIN FORMAT=JSON SELECT …）

圖 Structured EXPLAIN

Contains more information:

• Used index parts
  • Pushed index conditions 觸發索引的條件
  • Cost Estimates 成本估算
  • Data estimates 數據估算

圖 Structured EXPLAIN

圖 MySQL sys Schema Example

Visual EXPLAIN 可視化EXPLAIN

圖 Visual EXPLAIN

Optimizer Trace: Query Plan Debugging 優化程序跟蹤：查詢計劃調試

• EXPLAIN shows the selected plan EXPLAIN 展示了選擇的計劃
• Optimizer trace shows WHY the plan was selected
  優化跟蹤展示了為什么選這個計劃 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 數據訪問和索引選擇

• Finding the optimal method to read data from storage engine
  找到最合適的方式從儲存引擎讀取數據
• 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 范圍優化器
  • Goal: find the “minimal” ranges for each index that needs to be read
    目的： 找到需要讀取索引的"最小"變化
    Example:
  SELECT * FROM t1 WHERE (key1 > 10 AND key1 < 20) AND key2 > 30

圖 Ref Access Range Optimizer

• Range Optimizer, cont 范圍優化器，常量
  • Range optimizer selects the “useful” parts of the WHERE condition:
    范圍優化器選擇WHERE條件"有用的"部分
    • Conditions comparing a column value with a constant: 條件是一列和常量比較的數據
    • Nested AND/OR conditions are supported 嵌套的AND/OR 是支持的
  • Result: list of disjoint ranges that need to be read from index:結果： 沒有交集的范圍從索引讀取
• Cost estimate based on number of records in each range: 成本估算基于每個范圍的記錄數量
  • Record estimate is found by asking the Storage Engine (“index dives”)
    記錄估算通過詢問存儲引擎（"指數潛水"）獲取

Optimizer Trace show ranges 優化程序跟蹤顯示范圍

圖 Optimizer Trace show ranges

Range Optimizer: Case Study 范圍優化：案例學習

Why table scan? 為什么全表掃描？

SELECT * FROM orders WHERE YEAR(o_orderdate) = 1997 AND MONTH(o_orderdate) = 5 AND o_clerk = 'Clerk#000001866';

圖 Range Optimizer Case Study1
possible keys NULL 未使用索引

Some Reasons Why Index can not be Used 一些未使用索引的原因

• ndexed column is used as argument to function 索引列使用函數計算

  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) 當復合索引(a,b)，但是查詢條件是b = 10

• Type mismatch 類型不匹配

  my_string = 10

• Character set / collation mismatch 字符集/排序規則不匹配

  t1 LEFT JOIN t2 ON t1.utf8_string = t2. latin1_string

案例學習:

Rewrite query to avoid functions on indexed columns 重寫查詢以避免索引列上的函數
例如：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

Adding another index 添加另一個索引mysql> CREATE INDEX i_o_clerk ON orders(o_clerk); 就上面的例子，添加 o_clerk 索引

圖 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 結果范圍掃描：

圖 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 結果范圍掃描：

圖 Range Access for Multi-Column Indexes, cont+

案例學習:

• Create multi-column index 創建多列索引CREATE INDEX i_o_clerk_date ON orders(o_clerk, o_orderdate);

圖 Range Optimizer Case Study4

Performance Schema: Query History 執行計劃：查詢歷史
mysql5.7 默認enabled的。

UPDATE performance_schema.setup_consumers SET enabled='YES' WHERE name = 'events_statements_history'; SELECT sql_text, (timer_wait)/1000000000.0 "t (ms)", rows_examined rowsFROM performance_schema.events_statements_history ORDER BY timer_start;

圖 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 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的情況
  例如：

SELECT * FROM t1 WHERE a=10 OR b=10 INDEX(a) a = 10 INDEX(b) b = 10 Result: a= 10 OR b = 10

圖 Index Merge Union

Index Merge Intersection 索引合并交集

• Combine several indexes to reduce number of (or avoid) accesses to base table for ANDed conditions
  在AND條件下組合多個索引以減少（或避免）對基表訪問次數
  例如：

SELECT * FROM t1 WHERE a=10 AND b=10 INDEX(a) a = 10 INDEX(b) b = 10 Result: a= 10 AND b = 10

圖 Index Merge Intersection

Example1:

圖 Index Merge Intersection Example 1

Example2:
Beware of low-selectivity indexes! 注意低選擇性索引！

圖 Index Merge Intersection Example 2

Example3:
Handler status variables 處理程序狀態變量

圖 Index Merge Intersection Example 2+

Join optimizer 連接優化器

”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表計劃開始（根據大小和密鑰依賴性排序）
  • Expand each plan with remaining tables 用剩余的表擴展每個計劃
    • Depth-first 深度優先
  • If “cost of partial plan” > “cost of best plan”: 如果"部分計劃成本" > "最好的計劃成本"
    • “prune” plan 精簡計劃
• Heuristic pruning: 探索式精簡
  • Prune less promising partial plans 精簡沒什么用的部分計劃
  • May in rare cases miss most optimal plan (turn off with set optimizer_prune_level = 0)
    可能在極少數情況下錯過最佳計劃 (關閉并設置 optimizer_prune_level = 0)

JOIN Optimizer Illustrated 連接優化器插圖

圖 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優化工具實驗室發布

• Alternatives with same effect for this query: 對此查詢具有相同效果的替代方案

JOIN_PREFIX(customer) JOIN_SUFFIX(orders) JOIN_FIXED_ORDER()

圖 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 優化連接順序

圖 Improved join order

• Improvements to Query 8 in MySQL 5.7: mysql 5.7 對Query8的優化
• Filtering on non-indexed columns are taken into account 考慮對非索引列進行過濾
• 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 子查詢優化概述

Subquery category: 子查詢分類Strategy：策略

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 執行子查詢

圖 Subquery category

• Traditional Optimization of IN Subqueries IN子查詢的傳統優化
  • IN -> EXISTS transformation IN 轉化為 EXISTS
• Convert IN subquery to EXISTS subquery by “push-down” IN-equality to
  subquery 從IN子查詢轉化為EXISTS子查詢通過"向下"的同等子查詢 SELECT title FROM film WHERE film_id IN (SELECT film_id FROM actor WHERE name=“Bullock”) 優化為 =>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 優點：子查詢將計算更少的記錄
• Note: Special handling if pushed down expressions can be NULL 注意：如果"向下"表達式為NULL，則可特殊處理

Semi-join 半連接

• Convert subquery to inner join, BUT Need some way to remove duplicates
  將子查詢轉換為內連接 但需要一些方法去重

• Different strategies for duplicate removal: 去重的不同策略

  • FirstMatch (equivalent to IN→EXISTS execution) 匹配優先（等價于IN—>EXISTS的方式）
  • LooseScan (index scan, skip duplicates) 懶掃描（索引掃描，跳過重復）
  • 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.) 去重（用唯一索引將半連接的行插入臨時表；重復列將會被拒絕。無論連接順序）

• If duplicate removal is not necessary: 如果去重是非必須的話

  • Table pull-out 表將刪掉

Main advantage ： 主要優勢：

• Opens up for more optimal ”join orders” 有更多優化"連接順序"的選擇
  例如： 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 使用行代替排序會經過較少的行
• Restriction: 限制：
  • Cannot use semi-join if subquery contains union or aggregation
    如果子查詢包含union（并集）或者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: 沒有提示，優化器選擇半連接算法LooseScan
• Disable semi-join with hint: 使用提示禁用半連接：

圖 Hint Example: SEMIJOIN

• Subquery Materialization 子查詢實體化
  • Execute subquery once and store result in a temporary table 執行一次子查詢并在臨時表中存結果
  • Table has unique index for quick look-up and duplicate removal 表有唯一索引可以快速查找并去重
• Execute outer query and check for matches in temporary table 執行外部查詢并檢查臨時表中的匹配項

圖 Subquery Materialization
比較子查詢實現和IN?EXISTS 比較IN —> EXISTS的實現

圖 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及更早版本：單獨執行并將結果存儲在臨時表中（實現）
• 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或聚合函數的派生表將不會合并

圖 Merge Derived Table with Outer Query

Hint: Merge/Materialize Derived Table or View 暗示：合并/實現派生表或視圖

• MySQL 8.0.0 optimizer labs release MySQL 8.0.0優化器實驗室發布

  • Derived tables/views are, if possible, merged into outer query 如果可能，派生表/視圖將合并到外部查詢中

  • NO_MERGE hint can be used to override default behavior: NO_MERGE提示可用于覆蓋默認行為：

    • 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 排序優化

• General solution; “Filesort”: 通常的解決方案；"文件排序"
  • Store query result in temporary table before sorting 在排序之前將查詢結果存儲在臨時表中
  • If data volume is large, may need to sort in several passes with intermediate storage on disk.
    如果數據量很大，可能需要在磁盤上使用中間存儲進行多次傳遞排序
• Optimizations ： 優化
  • Take advantage of index to generate query result in sorted order 利用索引按排序順序生成查詢結果
  • For ”LIMIT n” queries, maintain priority queue of n top items in
    memory instead of filesort. (MySQL 5.6)
    對于"LIMIT n查詢，保留內存中n個頂級項的優先級隊列而不是文件排序。 （MySQL 5.6）

Filesort 文件排序：

圖 Filesort

Status variables 狀態變量

圖 Filesort+

Performance Schema 執行計劃

圖 Filesort Performance Schema
Sorting status per statement available from Performance Schema 可從執行計劃中對每個語句進行排序

案例1

圖 Filesort Case Study1

案例2

圖 Filesort Case Study2

案例3

圖 Filesort Case Study3
Increase sort buffer 增加排序緩沖區
SET sort_buffer_size = 1024*1024 默認256 KB。

案例4

圖 Filesort Case Study4
Increase sort buffer even more (8MB) 進一步增加排序緩沖區 (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 影響優化器

• Add indexes 添加索引
• Force use of specific indexes: 強制使用特定的索引
  • USE INDEX, FORCE INDEX, IGNORE INDEX 使用索引，強制索引，忽略索引
• Force specific join order: 強制特定的關聯順序
  • STRAIGHT_JOIN
• Adjust session variables 調整會話變量
  • 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：新的優化器暗示

• 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) 阻塞嵌套循環算法
  • 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) 索引情況下該范圍沒有可優化的
  • QB_NAME(name) Query Block 查詢阻塞

• Finer granularilty than optimizer_switch session variable 比optimizer_switch會話變量更精細

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 重新實現新語法中的索引暗示
  • Temporarily set session variables for just one query 暫時為一個查詢設置會話變量

MySQL 5.7: Query Rewrite Plugin 查詢重寫插件

• Rewrite problematic queries without the need to make application
  changes 無需更改應用程序即可重寫有問題的查詢

• Add hints 添加暗示

  • Modify join order 更新連接順序
  • Much more … 更多

• Add rewrite rules to table: 向表中添加重寫規則：

圖 Query Rewrite Plugin

• New pre- and post-parse query rewrite APIs 新的解析前和解析后查詢重寫API

MySQL 5.7: Adjustable Cost Constants 可調成本常量
Experimental! Use with caution! No guarantees 實驗！ 謹慎使用！ 不保證!！

圖 Adjustable Cost Constants

圖 Adjustable Cost Constants+

More information 更多信息：

MySQL Server Team blog 官方博客

http://mysqlserverteam.com/

My blog: 作者博客

http://oysteing.blogspot.com/

Optimizer team blog: 優化團隊博客

http://mysqloptimizerteam.blogspot.com/

MySQL forums: 論壇

Optimizer & Parser: http://forums.mysql.com/list.php?115/

Performance: http://forums.mysql.com/list.php?24/

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的[官方] mysql 性能优化文档（中英文自译）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。