mysql optimizer_switch : 查询优化器优化策略深入解析

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: mysql optimizer_switch : 查询优化器优化策略深入解析

optimizer_switch 的概念

optimizer_switch 是一个由多个标志组成的字符串,每个标志控制一个特定的优化器行为。这些标志可以被设置为 on 或 off,以启用或禁用相应的优化策略。通过调整这些标志,数据库管理员可以精细地控制查询优化器的行为,以达到最佳的性能表现。


ptimizer_switch系统变量可以控制优化器行为。它的值是一组标志,每个标志都有一个on或off值,用于指示相应的优化器行为是启用还是禁用。此变量具有全局值和会话值,可以在运行时更改。全局默认值可以在服务器启动时设置。

查看当前的优化器标志集
mysql> SELECT @@optimizer_switch\G
*************************** 1. row ***************************
@@optimizer_switch: 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,use_invisible_indexes=off,skip_scan=on,
                    hash_join=on,subquery_to_derived=off,
                    prefer_ordering_index=on,hypergraph_optimizer=off,
                    derived_condition_pushdown=on
1 row in set (0.00 sec)
修改optimizer_switch的值

要修改optimizer_switch的值,指定一个由一个或多个命令组成的逗号分隔的值:

SET [GLOBAL|SESSION] optimizer_switch='command[,command]...';

每个命令值应该具有下表所示的形式之一:

该值中命令的顺序并不重要,但如果存在,默认命令将首先执行。将opt_name标志设置为default将其设置为on或off中的任意一个为其默认值。不允许在值中多次指定任何给定的opt_name,这会导致错误。该值中的任何错误都会导致赋值失败,并导致optimizer_switch的值保持不变。

主要优化标志介绍

  1. index_merge
    index_merge 控制是否允许索引合并优化。当查询条件可以通过多个索引来满足时,MySQL 可以合并这些索引以更有效地检索数据。在复杂查询中,这可以显著提高性能。
  2. index_condition_pushdown (ICP)
    ICP 允许将 WHERE 子句中的条件推送到存储引擎层进行处理。这减少了存储引擎需要返回给优化器的数据量,因为它可以在检索数据时就过滤掉不符合条件的行。
  3. materialization
    当查询包含子查询时,materialization 标志控制是否将子查询的结果物化(即临时存储)。物化子查询可以减少重复计算,但也可能增加内存使用。
  4. semijoinloosescan
    这两个标志与半连接优化相关。半连接是一种在处理包含 EXISTS 或 IN 子句的查询时特别有效的优化策略。semijoin 控制是否使用这种优化,而 loosescan 则允许在某些情况下进行更高效的扫描。
  5. derived_merge
    当查询中包含派生表(由子查询生成的临时表)时,derived_merge 标志控制是否尝试将这些派生表合并到外部查询中。这可以减少查询的复杂性并提高性能。
  6. exists_to_in
    在某些情况下,将 EXISTS 子句转换为 IN 子句可能会改变查询的执行计划并提高性能。exists_to_in 标志控制是否进行这种转换。
  7. mrr (Multi-Range Read)
    MRR 是一种优化技术,用于改善范围查询和JOIN操作的性能。当设置为on时,MySQL 会尝试使用 MRR 来更有效地从磁盘读取数据。这通常可以减少磁盘I/O,并提高查询速度。
  8. mrr_cost_based
    当此标志设置为on时,MySQL 将基于成本决定是否使用 MRR。如果查询优化器认为使用 MRR 会更有效,那么它就会使用这种技术。否则,它将回退到传统的读取方法。
  9. block_nested_loop
    这个标志控制是否使用块嵌套循环连接(Block Nested Loop Join, BNLJ)。BNLJ 是一种在处理连接操作时减少I/O次数的方法。当设置为on时,MySQL 将考虑使用 BNLJ 来优化连接操作。
  1. batched_key_access

当此标志启用时,MySQL 会尝试使用批处理键访问(Batched Key Access, BKA)来优化某些类型的 JOIN 操作。BKA 可以减少在 JOIN 操作中访问索引的次数,从而提高性能。

  1. use_index_extensions

这个标志允许优化器使用索引扩展来优化某些类型的查询。索引扩展是一种技术,其中优化器可以使用索引中的额外信息来过滤结果集,而无需回表查找数据行。

  1. condition_fanout_filter

当此标志设置为on时,优化器将尝试使用条件扇出过滤器(Condition Fanout Filter, CFF)来优化查询。CFF 是一种在处理具有多个可能值的列时减少不必要行扫描的技术。

  1. use_invisible_indexes

这个标志控制优化器是否考虑使用标记为“不可见”的索引。在某些情况下,数据库管理员可能希望将索引标记为不可见以进行测试或维护,而不影响现有查询的性能。当此标志设置为on时,即使索引被标记为不可见,优化器也会考虑使用它们。

  1. skip_scan

skip_scan 允许优化器在某些情况下使用跳跃扫描来优化范围查询。跳跃扫描是一种技术,其中优化器可以跳过某些索引条目以更快地找到满足查询条件的条目。

  1. duplicateweedout

在执行某些类型的 JOIN 操作时,可能会出现重复的行。当 duplicateweedout 设置为on时,优化器将尝试在结果集中删除这些重复的行,从而提高查询结果的准确性。

  1. subquery_materialization_cost_based
    当此标志设置为on时,优化器将基于成本决定是否物化子查询。物化子查询是将子查询的结果集存储在临时表中,以便在外部查询中重复使用。这可以提高某些类型查询的性能,但也可能增加内存使用。

如何使用 optimizer_switch

要使用 optimizer_switch,你首先需要查看其当前设置:

SHOW VARIABLES LIKE 'optimizer_switch';

这将返回一个包含所有当前设置的标志及其状态的列表。

要更改设置,你可以使用 SET 语句。例如,要启用 ICP,你可以执行:

SET optimizer_switch='index_condition_pushdown=on';

注意,上述命令只会更改当前会话的设置。如果你想全局更改设置,需要使用 GLOBAL 关键字:

SET GLOBAL optimizer_switch='index_condition_pushdown=on';

注意事项和最佳实践

  • 在更改 optimizer_switch 设置之前,最好先在测试环境中验证更改的效果。
  • 不是所有的优化标志都适用于所有版本的 MySQL。在更改设置之前,请查阅相关文档以确保你了解每个标志的具体行为和限制。
  • 避免在生产环境中盲目更改设置。应该基于实际的性能分析和测试来做出决策。
  • 监控数据库的性能指标,以便及时发现并解决潜在问题。

结论

optimizer_switch 是一个强大的工具,允许数据库管理员和开发者精细地控制 MySQL 查询优化器的行为。合理地调整这些设置,可以提高数据库的性能并优化查询效率。使用时也要谨慎并基于充分的测试和分析。

相关文章
|
17天前
|
SQL 关系型数据库 MySQL
深入解析MySQL的EXPLAIN:指标详解与索引优化
MySQL 中的 `EXPLAIN` 语句用于分析和优化 SQL 查询,帮助你了解查询优化器的执行计划。本文详细介绍了 `EXPLAIN` 输出的各项指标,如 `id`、`select_type`、`table`、`type`、`key` 等,并提供了如何利用这些指标优化索引结构和 SQL 语句的具体方法。通过实战案例,展示了如何通过创建合适索引和调整查询语句来提升查询性能。
118 9
|
21天前
|
缓存 关系型数据库 MySQL
MySQL 索引优化以及慢查询优化
通过本文的介绍,希望您能够深入理解MySQL索引优化和慢查询优化的方法,并在实际应用中灵活运用这些技术,提升数据库的整体性能。
61 18
|
20天前
|
缓存 关系型数据库 MySQL
MySQL 索引优化以及慢查询优化
通过本文的介绍,希望您能够深入理解MySQL索引优化和慢查询优化的方法,并在实际应用中灵活运用这些技术,提升数据库的整体性能。
22 7
|
19天前
|
存储 关系型数据库 MySQL
double ,FLOAT还是double(m,n)--深入解析MySQL数据库中双精度浮点数的使用
本文探讨了在MySQL中使用`float`和`double`时指定精度和刻度的影响。对于`float`,指定精度会影响存储大小:0-23位使用4字节单精度存储,24-53位使用8字节双精度存储。而对于`double`,指定精度和刻度对存储空间没有影响,但可以限制数值的输入范围,提高数据的规范性和业务意义。从性能角度看,`float`和`double`的区别不大,但在存储空间和数据输入方面,指定精度和刻度有助于优化和约束。
|
19天前
|
缓存 关系型数据库 MySQL
MySQL 索引优化与慢查询优化:原理与实践
通过本文的介绍,希望您能够深入理解MySQL索引优化与慢查询优化的原理和实践方法,并在实际项目中灵活运用这些技术,提升数据库的整体性能。
51 5
|
22天前
|
缓存 NoSQL 关系型数据库
MySQL战记:Count( *)实现之谜与计数策略的选择
本文深入探讨了MySQL中`count(*)`的不同实现方式,特别是MyISAM和InnoDB引擎的区别,以及各种计数方法的性能比较。同时,文章分析了使用缓存系统(如Redis)与数据库保存计数的优劣,并强调了在高并发场景下保持数据一致性的挑战。
MySQL战记:Count( *)实现之谜与计数策略的选择
|
2月前
|
SQL 关系型数据库 MySQL
PHP与MySQL的高效协同开发策略####
本文深入探讨了PHP与MySQL在Web开发中的协同工作机制,通过优化配置、最佳实践和高级技巧,展示了如何提升数据库交互性能,确保数据安全,并促进代码可维护性。我们将从环境搭建讲起,逐步深入到查询优化、事务管理、安全防护及性能调优等核心环节,为开发者提供一套实战驱动的解决方案框架。 ####
|
11天前
|
存储 Oracle 关系型数据库
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
39 3
|
11天前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
41 3
|
11天前
|
SQL 关系型数据库 MySQL
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE 'log_%';`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
53 2