Optimizer_switch变量是支持对优化器行为的控制。是一组值标志，每个标志都有一个on或off的值，以指示是否启用或禁用相应的行为。
MySQL8.0里除了熟悉的hash join重大变化之外，其他方面也有优化。
mysql> SHOW VARIABLES LIKE 'OPTIMIZER_SWITCH'\G;
*************************** 1. row ***************************
Variable_name: optimizer_switch
Value: index_merge=on,index_merge_union=on,index_merge_sort_union=on,
index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,
mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,
materialization=on,semijoin=on,loosescan=on,firstmatch=on,
duplicateweedout=on,subquery_materialization_cost_based=on,
use_index_extensions=on,condition_fanout_filter=on,derived_merge=on,
##下面是目前5.7 Vs 8.0差异内容##
use_invisible_indexes=off,skip_scan=on,hash_join=on,
subquery_to_derived=off,prefer_ordering_index=on,
hypergraph_optimizer=off,derived_condition_pushdown=onuse_invisible_indexes
MySQL8.0 开始支持隐藏索引，有时往往因为索引不合理，执行计划太差，需要大动干戈，现在不需要进行破坏性的更改，优化器方面配合是否使用不可见索引来构建查询执行计划.默认是关闭。当然这里主键以外。
#索引age隐藏
mysql> ALTER TABLE members ALTER INDEX idx_age INVISIBLE;
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0
#执行计划全表扫描
mysql> EXPLAIN select *from members where age > 10;
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------------+
| 1 | SIMPLE | members | NULL | ALL | NULL | NULL | NULL | NULL | 3 | 33.33 | Using where |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)
#优化器可用隐藏索引打开。
mysql> SET SESSION optimizer_switch='use_invisible_indexes=on';
Query OK, 0 rows affected (0.00 sec)
#执行计划使用age 隐藏索引
mysql> EXPLAIN select *from members where age > 10;
+----+-------------+---------+------------+-------+---------------+---------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+-------+---------------+---------+---------+------+------+----------+-----------------------+
| 1 | SIMPLE | members | NULL | range | idx_age | idx_age | 5 | NULL | 3 | 100.00 | Using index condition |
+----+-------------+---------+------------+-------+---------------+---------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.00 sec)备注： 在一些业务无法及时改变SQL语句的时，可以通过更改索引隐藏属性，有效控制手段。
特别是生产不确定索引性能影响的时候，可以在线操作，算是应急对策。
prefer_ordering_index
MySQL里对任何有LIMIT子句的ORDER BY或GROUP BY查询使用有序索引，覆盖优化器所做的任何其他选择，只要它确定这会导致更快的执行。因此做出这种判断的算法对数据分布和其他条件做出了某些假设，所以它可能并不总是完全正确，而且在某些情况下，此类查询选择不同的优化可能会提供更好的性能。
8.0.21版本中optimizer_switch变量的prefer_ordering_index设置来禁用这种优化算法。
optimizer_switch参数中的prefer_ordering_index进行控制对于order by limit的优化。prefer_ordering_index默认打开，表示MySQL会优先考虑通过order by列索引进行排序优化。
目前验证发现只在范围查询中，有算法干扰。所以使用范围查询，可要小心了。
#模拟表结构和数据
mysql>CREATE table `members`
(
id int unsigned NOT NULL AUTO_INCREMENT ,
first_name varchar(100) DEFAULT NULL ,
last_name varchar(100) DEFAULT NULL ,
age INT DEFAULT '0' ,
create_time timestamp DEFAULT CURRENT_TIMESTAMP,
update_time timestamp DEFAULT current_timestamp() ON UPDATE current_timestamp(),
primary KEY (id) ,
KEY idx_first_last(first_name(3),last_name(3)),
KEY idx_age(age)
);
mysql>INSERT INTO `members`(id,first_name,last_name,age)
VALUES(1,'AAAAA','BBBBB',12),(2,'AAAAA','CCCCC',20),(3,'DDDDD','EEEEE',30);
#排序优先开启
mysql>SET optimizer_switch = "prefer_ordering_index=on";
#优先ORDER BY 和 LIMIT 选择主键
mysql> EXPLAIN SELECT * FROM members WHERE age> 15 order by `id` DESC LIMIT 1;
+----+-------------+---------+------------+-------+---------------+---------+---------+------+------+----------+----------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+-------+---------------+---------+---------+------+------+----------+----------------------------------+
| 1 | SIMPLE | members | NULL | index | idx_age | PRIMARY | 4 | NULL | 1 | 66.67 | Using where; Backward index scan |
+----+-------------+---------+------------+-------+---------------+---------+---------+------+------+----------+----------------------------------+
1 row in set, 1 warning (0.00 sec)
#排序优先关闭
mysql> SET optimizer_switch = "prefer_ordering_index=off";
Query OK, 0 rows affected (0.00 sec)
#选择合理执行计划
mysql> EXPLAIN SELECT * FROM members WHERE age> 15 order by `id` DESC LIMIT 1;
+----+-------------+---------+------------+-------+---------------+---------+---------+------+------+----------+---------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+-------+---------------+---------+---------+------+------+----------+---------------------------------------+
| 1 | SIMPLE | members | NULL | range | idx_age | idx_age | 5 | NULL | 2 | 100.00 | Using index condition; Using filesort |
+----+-------------+---------+------------+-------+---------------+---------+---------+------+------+----------+---------------------------------------+
1 row in set, 1 warning (0.00 sec)
subquery_to_derived
MySQL 8.0.21开始，优化器增加了subquery_to_derived（默认关闭）选项。优化器在许多情况下能够将SELECT、WHERE、JOIN或HAVING子句中的标量子查询转换为派生表上的左&外部连接（在某些情况下是内连接）。
所为的：
- subquery: 包含在 SELECT 中的子查询(不在 FROM子句中)。
- derived : 包含在 from 子句中的子查询。MySQL会将结果存放在一个临时表中，
也称为派生表(derived).
在大多数情况下，启用此优化不会产生任何明显的性能改进(在许多情况下甚至会使查询运行得更慢)，视情况而定，所以选择默认值即可。
SHOW WARNINGS信息下，可以看到语句改写情况：
mysql> SET SESSION optimizer_switch='subquery_to_derived=OFF';
Query OK, 0 rows affected (0.00 sec)
mysql> EXPLAIN SELECT * FROM t1 WHERE t1.a > (SELECT COUNT(a) FROM t2);
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| 1 | PRIMARY | t1 | NULL | ALL | NULL | NULL | NULL | NULL | 4 | 33.33 | Using where |
| 2 | SUBQUERY | t2 | NULL | ALL | NULL | NULL | NULL | NULL | 2 | 100.00 | NULL |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
2 rows in set, 1 warning (0.00 sec)
mysql> SHOW WARNINGS;
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1003 | /* select#1 */ select `test`.`t1`.`a` AS `a`
from `test`.`t1`
where (`test`.`t1`.`a` > (/* select#2 */ select count(`test`.`t2`.`a`) from `test`.`t2`)) |
+-------+------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> SET SESSION optimizer_switch='subquery_to_derived=ON';
Query OK, 0 rows affected (0.00 sec)
mysql> EXPLAIN SELECT * FROM t1 WHERE t1.a > (SELECT COUNT(a) FROM t2);
+----+-------------+------------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
| 1 | PRIMARY | <derived2> | NULL | ALL | NULL | NULL | NULL | NULL | 1 | 100.00 | NULL |
| 1 | PRIMARY | t1 | NULL | ALL | NULL | NULL | NULL | NULL | 4 | 33.33 | Using where; Using join buffer (hash join) |
| 2 | DERIVED | t2 | NULL | ALL | NULL | NULL | NULL | NULL | 2 | 100.00 | NULL |
+----+-------------+------------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
3 rows in set, 1 warning (0.00 sec)
mysql> SHOW WARNINGS;;
+-------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1003 | /* select#1 */ select `test`.`t1`.`a` AS `a`
from `test`.`t1` join (
/* select#2 */ select count(`test`.`t2`.`a`) AS `COUNT(a)`
from `test`.`t2`) `derived_1_2`
where (`test`.`t1`.`a` > `derived_1_2`.`COUNT(a)`) |
+-------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)derived_condition_pushdown
Mysql 8.0.22之后的版本支持派生条件回移(Derived Condition Pushdown)优化。该优化可以减少derived派生表处理的行数从而提高查询执行的效率。
比方如下查询：
SELECT * FROM
(SELECT i, j FROM t1) AS dt
WHERE i > constant
# ↓ ↓ ↓ 通过派生条件回移优化后类似如下形式（WHERE条件拿到派生表的里面）
SELECT * FROM (SELECT i, j FROM t1 WHERE i > constant)就是说 将外部WHERE条件下推到派生表中应该会减少需要处理的行数，从而加快查询的执行速度。
MySQL 8.0.29及以后版本中，派生表条件下推优化可以用于UNION查询。
不能下推情况：内部表，包含子查询的条件，公共表表达式，LIMIT子句，变量的赋值 等场景。
skip_scan
MySQL从8.0.13版本开始支持一种新的range scan方式。就是说 组合索引(f1,f2)的时候，查询条件里 只有f2的时候 也可以实现索引扫描的功能.范围扫描比全索引扫描更有效，优化器可以执行多个范围扫描，每个值对应一个f1，使用一种称为Skip Scan的方法，类似于松散索引扫描。
从上述描述可以看到使用skip-scan的方式避免了全索引扫描，从而提升了性能，尤其是在索引前缀列区分度比较低的时候。可以说 避开了索引前缀原则。
mysql> ALTER TABLE t1 ADD PRIMARY KEY(f1, f2);
Query OK, 0 rows affected (0.11 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> EXPLAIN SELECT f1, f2 FROM t1 WHERE f2 > 40;;
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+----------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+----------------------------------------+
| 1 | SIMPLE | t1 | NULL | range | PRIMARY | PRIMARY | 8 | NULL | 53 | 100.00
| Using where; Using index for skip scan |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+----------------------------------------+
1 row in set, 1 warning (0.00 sec)hypergraph_optimizer
MySQL 8.0.23提供了优化器支持hypergraph（超图）的模型。目前实际还不支持，需要在debug下进行验证测试，是不成熟的优化方案。
hypergraph是数学中用的概念。在数据算法中，描述对象之间建立联系而用的。个人理解，就是通过边界算法，把对应的数据关联点，范围等圈出来。
由此多表关联下，从5.7的nest loop 进化到8.0的hash join，在hash join进一步提升效率的的算法。这个算法非常切合B+Tree配合使用。
mysql> SET SESSION optimizer_switch='hypergraph_optimizer=ON';
ERROR 3999 (42000): The hypergraph optimizer does not yet support 'use in non-debug builds'总结
优化器行为变更，可能会导致不同版本SQL语句性能体现不一样。当然变化是往好的方面延伸的，但对于复杂的情况，可能也会出现退化效果。所以版本升级的时候，需要特别关注下。
在这里特别感兴趣hypergraph（超图）优化方案。因为MySQL对于多表关联是一个致命的问题，关联表数量越多性能越差。对于hypergraph的算法本质上的理解，可以说结合B+Tree性能提升空间很大。