- 综合排序
- 最热优先
- 最新优先
- 来自专栏叁金大数据
SQL优化器简介
我们在工作中经常会听到这样的声音：“SQL查询慢？你给数据库加个索引啊”。虽然加索引并不一定能解决问题，但是这初步的体现了SQL优化的思想。 而数据库主要由三部分组成，分别是解析器、优化器和执行引擎。 ? 其执行逻辑是我们输入的SQL语句通过解析器解析成关系表达式，通过优化器把关系表达式转换成执行计划，最终通过执行引擎进行执行。 所以优化器在很大程度上决定了一个系统的性能。优化器的作用就好比找到两点之间的最短路径。 上篇文章我们提到了Calcite，Calcite本身就支持两种优化方式分别是RBO和CBO。 它是一种经验式的优化方法，优化规则都是预先定义好的，只需要将SQL按照优化规则的顺序往上套就行，一旦满足某个规则则进行优化。 随着大数据技术的飞速发展，静态的CBO已经无法满足我们SQL优化的需要了，静态的统计信息无法提供准确的参考，在执行计划的生成过程中动态统计才会得到最优的执行计划。 那么优化器的执行过程是怎样的呢？
1K20发布于 2019-03-15 - 来自专栏SQL查询优化
SQL查询优化器
背景 一般的，数据库管理系统(DBMS)有通用的架构模型，可分为四个模块：传输通信、查询处理器、执行引擎、存储引擎。其中查询处理器包括查询解析器和查询优化器，而查询优化器是实现SQL计划树优化的核心。 优化规则通常是专家经验沉淀的，如等值连接，如果等值条件的字段有索引，则优先使用索引扫描。 该模型易于实现与调试，优化速度快，但决策完全依赖于预定义的规则，无法为复杂查询生成好的计划。 2. 每个规则都可以表示为一对属性：（1）Pattern模式，定义可以应用规则applyRule的计划树结构；(2) Substitute 替换，定义应用规则applyRule后产生的结果。 但优化规则较多时，搜索耗时较长或卡主。 总结 本文围绕SQL查询优化器进行展开说明，分别介绍优化器分类、优化器框架、优化器模型。 另，社区开源的SQL中间件Calcite具备完善的查询优化能力，基于Cascades统一搜索模型实现，更多可参考：《Calcite系列(九)：执行流程-优化器优化》 推荐阅读 《数据库查询优化器的艺术》
1.6K73编辑于 2024-06-30 - 来自专栏AustinDatabases
SQL SERVER SQL 优化指南 四句真言 （SQL 优化系列 2）
SQL 优化四字真言系列 PostgreSQL SQL 优化指南 四句真言（SQL 优化系列 1） 上期说完PostgreSQL 数据库，这期咱们说说MSSQL，也就是SQL SERVER的SQL优化指南 基于SQL SERVER在SQL执行中的智能化，AI化，之前文章也写过2025版本的厉害，相信更先进的SQL SERVER必定能让烂SQL优化更加不需要人工的介入。 置顶 PostgreSQL SQL 优化指南 四句真言（SQL 优化系列 1） 从 Universal 环球影城 到 国产数据库产品 营销 --驴唇对马嘴 3种方式 PG大版本升级 接锅，背锅，不甩锅 --TTL P-MySQL SQL优化案例，反观MySQL不死没有天理 MySQL 条件下推与排序优化实例--MySQL8.035 云数据库厂商除了卷技术，下一个阶段还可以卷什么？ （译） MySQL 8 SQL 优化两则 ---常见问题 MySQL SQL优化快速定位案例 与 优化思维导图 "DBA 是个der" 吵出MySQL主键问题多种解决方案 MySQL 怎么让自己更高级-
10210编辑于 2026-03-12 Spark SQL Catalyst 优化器详解
SparkSQLCatalyst优化器详解一、SparkSQLCatalyst导览宏观来看：SparkSQL语句，经过一个优化器（Catalyst），转化为RDD，交给集群执行。 称为未解析的逻辑计划（UnresolvedLogicalPlan，ULP）Analyzer模块：借助数据的元数据信息将ULP解析为逻辑计划（LogicalPlan，LP）Optimizer模块：根据各种RBO、CBO优化策略得到优化后的逻辑计划 （OptimizedLogicalPlan，OLP），主要是对LogicalPlan进行剪枝、合并等操作，进而删除掉一些无用计算，或对一些计算的多个步骤进行合并其中RBO是基于规则优化，CBO是基于代价优化 4.1RBO（基于规则的优化）RBO的优化策略就是对语法树再次进行一次遍历，模式匹配能够满足特定规则的节点，再进行相应的等价转换，即将一棵树等价地转换为另一棵树。 4.2CBO（基于代价的优化）CBO通过综合考虑数据的统计信息、操作算子的代价等因素，计算不同执行计划的代价，从而选择最优的物理执行计划，以提升查询性能。
19710编辑于 2026-02-08- 来自专栏Oracle数据库技术
【Oracle优化器】SQL计划指令（SQL Plan Directives）
概述 我们知道统计反馈（SFB）收集的SQL运行时的统计信息会保存在相应的共享游标中，但却不能够持久化，当数据库重启或者被优化的SQL文从内存中Age-out后，保存的信息就会丢失。 下一次执行时还要重新进行一遍自动重新优化。 虽然到目前为止，只有一种SQL计划指令就是动态采样指令（DYNAMIC_SAMPLING），用于指示优化器使用动态统计信息，但相信以后该功能会进一步得到强化。 另外，SQL计划指令（SQL Plan Directives）是基于查询表达式，而不是SQL语句，所以同一个SQL计划指令（SQL Plan Directives），可以被优化器应用多个SQL文中。 ※注意： 12c中SQL计划指令（SQL Plan Directives）只能通过12c自动重新优化（Automatic Reoptimization）功能 由优化器自己判断自动生成，无法通过手动生成。
97720发布于 2020-03-26 - 来自专栏罗西的思考
PyTorch分布式优化器(2)----数据并行优化器
[源码解析] PyTorch分布式优化器(2)----数据并行优化器 目录 [源码解析] PyTorch分布式优化器(2)----数据并行优化器 0x00 摘要 0x01 前文回顾 0x02 DP 之中的优化器 2.1 流程 2.2 使用 0x03 DDP 之中的优化器 3.1 流程 3.2 优化器状态 3.3 使用 0x04 Horovod 的优化器 4.1 hook 同步梯度 4.1.1 注册 hooks 数据并行之中的优化器就是另外一种情况，因为每个worker自己计算梯度，所以优化器主要技术难点是： 每个worker有自己的优化器？还是只有一个worker才有优化器，由他统一做优化？ 每个进程拥有自己独立的优化器，优化器也是常规优化器。 这里有两个特点： 每个进程维护自己的优化器，并在每次迭代中执行一个完整的优化步骤。 DDP 与优化器实际上没有关联，DDP不对此负责，所以需要用户协同操作来保证各进程之间的优化器状态相同。这就围绕着两个环节： 优化器参数初始值相同。
1.3K30编辑于 2021-12-09 - 来自专栏Java 汇总
2.Mysql 查询优化器
优化器是JOIN:optimize()及其所有下级例程。 优化器执行一些转换是因为常量传播，我们前面已经描述过了。顺便说一下，我们首先描述常量传播，因为它发生在MySQL发现常量表是什么之前。优化器步骤的顺序有时会有所不同。 源码位置：/sql/sql_select.cc, make_join_statistics(). ---- # 优化 JOIN JOIN type 1.system : 常量的系统表 2.const 优化器倾向于：向部分计划中添加的表越多，其成本就越高。 查询计划代码在： sql/sql_select.cc, find_best(). Group By 1.如果 是索引列，则使用索引 2.如果没有索引，groupby将使用排序,优化器选择使用哈希表。
1.2K21发布于 2020-10-29 - 来自专栏数据和云
【SQL执行计划】优化器相关Hint
嘉宾介绍： 在SQL优化中，除了可以通过修改参数的方式干预优化器工作外，还可以使用提示的方式进行干预，而且这种方式更加精准、不影响其他SQL，故使用场景更加广泛。 1. ALL_ROWS 说明： ALL_ROWS是针对整个目标SQL的Hint，它的含义是让优化器启用CBO，而且在得到目标SQL的执行计划时会选择那些吞吐量最佳的执行路径。 ALL_ROWS Hint其实就相当于对目标SQL启用CBO，其优化器为ALL_ROWS。从Oracle 10g开始，ALL_ROWS就是默认的优化器模式。 如果在目标SQL中除了ALL_ROWS之外还使用了其他与执行路径、表连接相关的Hint，则优化器会优先考虑ALL_ROWS。 ，也就是说在FIRST_ROWS(n) Hint生效的情况下，优化器会启用CBO，而且会依据返回头n条记录的响应时间来决定目标SQL的执行计划。
1.2K40发布于 2018-03-06 - 来自专栏知无不言 - 畅所欲言
MySQL 查询优化器与 SQL 调试 （一）
1、MySQL 查询优化器与 SQL 调试 （一）要想写出更好的 SQL，一些基础概念和 SQL 调试是必不可少的。下面我们来看下查询优化器给我们做了哪些优化，执行器真正执行的 SQL 语句是什么。 system user 的值是指服务器生成的非客户端线程，用于处理内部的任务。比如：延迟行处理程序线程或副本主机上使用的 I/O 或 SQL 线程。 1.4、查询优化器MySQL 使用基于成本的优化器，它将尝试预测一个查询使用某种执行计划时的成本，并选择其中成本最小的一个。如何查询 SQL 的执行成本呢？ 1.4.1、查询优化器做了哪些优化有以下部分优化内容：重新定义关联表顺序MySQL 会根据相关的嵌套循环算法找到扫描行数更少的表去重新定义关联顺序。 但是有时候优化器给出的不是最佳的关联顺序，如果有超过 n 个表的关联，优化器需要检查 n 的阶乘种关联顺序，当这个变得非常大的时候，优化器不可能去检查每一种的关联成本，这时候优化器会选择 “贪婪” 搜索的方式查找
45730编辑于 2023-11-20 - 来自专栏java一日一条
SQL Server优化之SQL语句优化
FROM：对FROM子句中前两个表执行笛卡尔积生成虚拟表vt1 2. ON: 对vt1表应用ON筛选器只有满足 join_condition 为真的行才被插入vt2 3. (2) 当在SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每个Column上。这样一来,就可以减少解析的时间并减少那些由Column歧义引起的语法错误。 from table1 A inner join table2 B on A.ID=B.ID Where … B、纵向来看 (1) 合理写WHERE子句，不要写没有WHERE的SQL语句。 只要我们在查询语句中没有强制指定索引，索引的选择和使用方法是SQLSERVER的优化器自动作的选择，而它选择的根据是查询语句的条件以及相关表的统计信息，这就要求我们在写SQL语句的时候尽量使得优化器可以使用索引 为了使得优化器能高效使用索引，写语句的时候应该注意： （1）不要对索引字段进行运算，而要想办法做变换，比如： SELECT ID FROM T WHERE NUM/2=100 应改为: SELECT ID
4.1K34发布于 2018-09-19 - 来自专栏万能的小草
这些SQL优化技巧，你知道吗？（2）
优化点： 对于数据量比较大的表，如行为埋点日志、观看日志明细表，尽量避免多次扫描相同分区数据。 案例讲解 优化前，成本500+多 --存在的问题：多次扫描大表不同的区间，存在子查询。 ') ) and event_id = 1 GROUP by did ) a; 优化后
22110编辑于 2024-07-23 - 来自专栏MySQL系列
SQL优化——order by优化
1.1.order by优化1.1.1.知识点回顾在讲解order by优化前，先回顾一下order by的语法知识。 其语法规则为：SELECT 字段列表 FROM 表名 ORDER BY 字段1 排序方式1 , 字段2 排序方式2 ;其中，排序方式有升序（asc，默认值），降序（desc）如果未指定排序方式，表示默认升序 asc , age desc;1.1.2.两种排序方式MySQL有两种排序方式Using filesort和Using index，Using index的性能高于Using filesort，我们在优化排序操作时 1.1.3.order by优化案例演示1.1.3.1.案例A在上面我们创建了字段age和phone的联合索引，而且没有指定索引的排序顺序，此时索引在表中默认是按照升序排列的。 :MySQL有两种排序方式Using filesort和Using index，在优化排序操作时，尽量要优化为 Using index根据排序字段建立合适的索引，多字段排序时，索引需要遵循最左前缀法则。
1.7K20编辑于 2024-03-29 - 来自专栏用户8851017的专栏
SQL优化
MySQL常见的优化手段分为下面几个方面： SQL优化、设计优化，硬件优化等，其中每个大的方向中又包含多个小的优化点 SQL优化 此优化方案指的是通过优化 SQL 语句以及索引来提高 MySQL 数据库的运行效率 ，具体内容如下： 分页优化 例如： select * from table where type = 2 and level = 9 order by id asc limit 190289,10; 复制代码 ，如果在一个 SQL 中关联的表越多，所占用的内存也就越大 如果程序中大量的使用了多表关联的操作，同时join_buffer_size设置的也不合理的情况下，就容易造成服务器内存溢出的情况，就会影响到服务器数据库性能的稳定性 的各个子查询中，以便优化器可以充分利用这些条件进行优化 此外，除非确实需要服务器去重，一定要使用union all，如果不加all关键字，MySQL会给临时表加上distinct选项，这会导致对整个临时表做唯一性检查 ，代价很高 慢查询日志 出现慢查询通常的排查手段是先使用慢查询日志功能，查询出比较慢的 SQL 语句，然后再通过 Explain 来查询 SQL 语句的执行计划，最后分析并定位出问题的根源，再进行处理
1.2K30发布于 2021-07-22 - 来自专栏爱明依
SQL 优化
SQL 优化 负向查询不能使用索引 select name from user where id not in (1,3,4); 应该修改为: select name from user where id in (2,5,6); 前导模糊查询不能使用索引 如: select name from user where name like '%zhangsan' 非前导则可以: select name from user where create_time < FROM_UNIXTIME(CURDATE()); 最左前缀问题 如果给 user 表中的 username pwd 字段创建了复合索引那么使用以下SQL
73340编辑于 2022-04-01 - 来自专栏JAVA人生/面试技巧
SQL优化
优化手段： ① SQL优化 避免 SELECT *，只查询需要的字段。 小表驱动大表，即小的数据集驱动大的数据集： 当B表的数据集比A表小时，用in优化 exist两表执行顺序是先查B表再查A表查询语句：SELECT * FROM tb_dept WHERE id in ( SELECT id FROM tb_dept) ; 当A表的数据集比B表小时，用exist优化in ，两表执行顺序是先查A表，再查B表，查询语句：SELECT * FROM A WHERE EXISTS ② 优化索引的使用 尽量使用主键查询，而非其他索引，因为主键查询不会触发回表查询。 不做列运算，把计算都放入各个业务系统实现 查询语句尽可能简单，大语句拆小语句，减少锁时间 or 查询改写成 union 查询 不用函数和触发器 避免 %xx 查询，可以使用：select * from
87920发布于 2020-06-08 - 来自专栏老虎刘谈oracle性能优化
106-跟专家学习SQL优化-2
待优化SQL: SQL执行计划: (图1) SQL历史执行情况: (图2) 作者将SQL的select 部分拿出来测试执行,执行时间0.55秒: (图3) 根据上面信息, 专家给出了优化方法 根据SQL实际执行时间60多秒这个事实, 图1执行计划中,驱动表E过滤后得到的真实结果集应该远大于估算的结果集1, 只有这样,才能对得上平均每次buffer gets 2605万(图2红框)这个数字. 所以这个SQL就不能按照图1执行计划显示的数据去优化. 分析到了这里,原来专家给的优化建议才是更符合实际生产数据分布的.专家用的两个优化手段, 最起作用的是那个/*+ hash_aj */的hint,就是让优化器在驱动表估值为1的情况下,仍然使用hash join 如果能够采集到60多秒执行情况下的sql monitor信息,就能够更清晰的看到执行计划中真实的结果集大小, 这种简单SQL的优化其实在1~2分钟内就能得出结论.
40620编辑于 2023-09-01 - 来自专栏FREE SOLO
SQL优化
1.有哪些数据库优化方面的经验? 用PreparedStatement， 一般来说比Statement性能高：一个sql 发给服务器去执行，涉及步骤：语法检查、语义分析， 编译，缓存。 2.请简述常用的索引有哪些种类? 基于语句的复制： 在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。 一旦发现没法精确复制时，会自动选着基于行的复制。 基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. InnoDB：所有的表都保存在同一个数据文件中（也可能是多个文件，或者是独立的表空间文件），InnoDB表的大小只受限于操作系统文件的大小，一般为2GB。
1K20发布于 2019-04-19 - 来自专栏Java技术详解
SQL优化
SQL的编写尽量使用索引库查询。索引库查询是小表查询操作，耗费的查询数据性能时间较少。索引失效是由like模糊匹配所产生的查询性能问题。 SQL的编写过程涉及到的子查询不能嵌套太多，子查询会在运行内存中给数据输出对象分配内存空间。嵌套分配内存不利于内存空间的释放。表与表之间的关联关系建立通过外键和主表的主键进行关联。 SQL的数据输出数据区尽量使用简单的数据。聚集函数在SQL的输出数据区存在会生成数据输出集合，类似复杂数据对象不利于数据的检索。聚集函数输出数据会产生索引失效，需要重新对输出数据建立索引。 SQL的条件过滤is null 是不会扫描索引表。节省数据索引表的内存空间。条件or关键字尽量少用，也是不会和数据索引表产生关联。数据表的小表类似索引表，大表类似数据库记录表。
40410编辑于 2023-11-02 - 来自专栏P轴
SQL优化
= 用 > or < 替换 between代替in exist 代替in 例如：优化前10s，优化后5s SELECT * from product WHERE title IN (SELECT title 这个复制的过程实质上是从服务器复制主服务器上MySQL的二进制日志（bin-log），并在从服务器上还原主服务器上的操作。 2. 配置主服务器 停止MySQL服务，修改主的my.ini，找到mysqId [mysqld] server-id=1 #是1~2^23-1内的唯一值且不能与B或其它slave服务中的配置相同 log-bin 修改从服务器 修改/etc/my.cnf server-id=2 #唯一并与主服务器上的server-id不同。
68210编辑于 2022-11-28 - 来自专栏基础知识文章
SQL优化
一、插入数据 批量插入 Insert into tb_test values(1,'Tom'),(2,'Cat'),(3,Jerry'); 手动提交事务 start transaction; insert into tb test values(1,'Tom'),(2,'Cat'),(3,Jerry'); insert into tb test values(4,'Tom'),(5,'Cat'),(6, 开启从本地加载文件导入数据的开关 set global local_infile =1; #执行load指令将准备好的数据，加载到表结构中 load data local infile '/root/sql1 优化思路：一般分页查询时，通过创建覆盖索引能够比较好地提高性能，可以通过覆盖索引加子查询形式进行优化。 count() InoDB引擎并不会把全部字段取出来，而是专门做了优化，不取值，服务层直接按行进行累加。
69650编辑于 2023-10-11
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号