sql优化

一、使用union来取代where in： 使用where or语句操作： select * from city where id = 1 or id = 3 or id = 4 输出： 1 广州 3 深圳 4 惠州 explain 结果： id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE city ALL PRIMARY NULL NULL NULL 5 Using where 标准使用where in操作： select * from city where id in (1,3,4) 输出： 1 广州 3 深圳 4 惠州 explain 结果： id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE city ALL PRIMARY NULL NULL NULL 5 Using where 使用union all操作： SELECT * FROM city where id = 1 union all SELECT * FROM city where id = 3 union all SELECT * FROM city where id = 4 输出： 1 广州 3 深圳 4 惠州

select count(*) from t1; 这句话比较简单，但很有玄机！对这句话运行的理解，反映了你对数据库的理解深度！ 建立实验的大表他t1 SQL> conn scott/tiger 已连接。 SQL> drop table t1 purge; 表已删除。 SQL> create table t1 as select * from emp where 0=9; 表已创建。 SQL> insert into t1 select * from emp; 已创建14行。 SQL> insert into t1 select * from t1; 已创建14行。 SQL> / 已创建28行。 SQL> / 已创建56行。 SQL> / 已创建112行。 SQL> / 已创建224行。 SQL> / 已创建448行。 SQL> / 已创建896行。 SQL> / 已创建1792行。 SQL> / 已创建3584行。 SQL> / 已创建7168行。 SQL> / 已创建14336行。 SQL> / 已创建28672行。 SQL> / 已创建57344行。 SQL> commit; 提交完成。 收集统计信息 SQL> execute dbms_stats.gather_table_stats('SCOTT','T1'); PL/SQL 过程已成功完成。 SQL> SET AUTOT

1.6多个查询字段（常量条件） 多个查询字段的查询处理逻辑如下所示： JOIN:prepare阶段 setup_tables()：同1.1测试。 setup_fields()：同1.1测试。 setup_conds()：同1.4测试。 JOIN:optimize阶段 optimize_cond()：类似1.4测试，不同之处在于查询的where条件中有恒等常量，在优化过程中会调用remove_eq_conds将1=1条件删除。 make_join_statistics()：与1.4测试类似，由于where条件查询有两个，并且其中一个条件可以通过索引查询。因此首先通过调用update_ref_and_keys()（sql\sql_select.cc:3967）函数，查找可以使用索引的字段。 SQL_SELECT::test_quick_select()：同1.5索引测试 get_key_scans_params()：同1.5索引测试。 choose_plan()：同1.3测试。 greedy_search()：同1.3测试。 best_extension_by_limited_search()：同1.5索引测试。 JOIN:exec阶段 以下操作同1.3测试。 通过测试可以看出，对于常量等式对查询优化器来说没有任何意义，会在optimize_conds时将常量等式删除

开发中经常会使用这两个聚合函数，作用都是用来统计记录行，今天查找资料发现，其实这两个函数并没有区别， 实践才是检验的标准，首先看执行计划（表是我自己建立的）： 可以看到，两个执行计划完全一样，后来查找资料，有人用模拟百万的数据重新来模拟，发现两者的速度几乎没有，select count(1)稍微比select count(*)快不超过0.5秒，数据量越大的时候，反而有时候select count(*)更快，可见现在数据库的版本对select count(*)已经优化很好了，在实际开发中选择其中一种都可以。 来源： oschina 链接： https://my.oschina.net/u/3497902/blog/2208655

之前整理的一篇有关 CBO 和 RBO 文章： Oracle CBO 与 RBO http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5709784.aspx Oracle 数据库中优化器（ Optimizer ）是 SQL 分析和执行的优化工具，它负责指定 SQL 的执行计划，也就是它负责保证 SQL 执行的效率最高，比如优化器决定 Oracle 以什么样的方式来访问数据，是全表扫描（ Full Table Scan ），索引范围扫描（ Index Range Scan ）还是全索引快速扫描（ INDEX Fast Full Scan ： INDEX_FFS ） ; 对于表关联查询，它负责确定表之间以一种什么方式来关联，比如 HASH_JOHN 还是 NESTED LOOPS 或者 MERGE JOIN 。 这些因素直接决定 SQL 的执行效率，所以优化器是 SQL 执行的核心，它做出的执行计划好坏，直接决定着 SQL 的执行效率。 Oracle 的优化器有两种： RBO( Rule-Based Optimization ): 基于规则的优化器 CBO( Cost-Based Optimization ): 基于代价的优化器 从 Oracle 10g 开始， RBO 已经被弃用，但是我们依然可以通过 Hint 方式来使用它

之前整理的一篇有关 CBO 和 RBO 文章： Oracle CBO 与 RBO http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5709784.aspx Oracle 数据库中优化器（ Optimizer ）是 SQL 分析和执行的优化工具，它负责指定 SQL 的执行计划，也就是它负责保证 SQL 执行的效率最高，比如优化器决定 Oracle 以什么样的方式来访问数据，是全表扫描（ Full Table Scan ），索引范围扫描（ Index Range Scan ）还是全索引快速扫描（ INDEX Fast Full Scan ： INDEX_FFS ） ; 对于表关联查询，它负责确定表之间以一种什么方式来关联，比如 HASH_JOHN 还是 NESTED LOOPS 或者 MERGE JOIN 。 这些因素直接决定 SQL 的执行效率，所以优化器是 SQL 执行的核心，它做出的执行计划好坏，直接决定着 SQL 的执行效率。 Oracle 的优化器有两种： RBO( Rule-Based Optimization ): 基于规则的优化器 CBO( Cost-Based Optimization ): 基于代价的优化器 从 Oracle 10g 开始， RBO 已经被弃用，但是我们依然可以通过 Hint 方式来使用它

之前整理的一篇有关 CBO 和 RBO 文章： Oracle CBO 与 RBO http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5709784.aspx Oracle 数据库中优化器（ Optimizer ）是 SQL 分析和执行的优化工具，它负责指定 SQL 的执行计划，也就是它负责保证 SQL 执行的效率最高，比如优化器决定 Oracle 以什么样的方式来访问数据，是全表扫描（ Full Table Scan ），索引范围扫描（ Index Range Scan ）还是全索引快速扫描（ INDEX Fast Full Scan ： INDEX_FFS ） ; 对于表关联查询，它负责确定表之间以一种什么方式来关联，比如 HASH_JOHN 还是 NESTED LOOPS 或者 MERGE JOIN 。 这些因素直接决定 SQL 的执行效率，所以优化器是 SQL 执行的核心，它做出的执行计划好坏，直接决定着 SQL 的执行效率。 Oracle 的优化器有两种： RBO( Rule-Based Optimization ): 基于规则的优化器 CBO( Cost-Based Optimization ): 基于代价的优化器 从 Oracle 10g 开始， RBO 已经被弃用，但是我们依然可以通过 Hint 方式来使用它

之前整理的一篇有关 CBO 和 RBO 文章： Oracle CBO 与 RBO http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5709784.aspx Oracle 数据库中优化器（ Optimizer ）是 SQL 分析和执行的优化工具，它负责指定 SQL 的执行计划，也就是它负责保证 SQL 执行的效率最高，比如优化器决定 Oracle 以什么样的方式来访问数据，是全表扫描（ Full Table Scan ），索引范围扫描（ Index Range Scan ）还是全索引快速扫描（ INDEX Fast Full Scan ： INDEX_FFS ） ; 对于表关联查询，它负责确定表之间以一种什么方式来关联，比如 HASH_JOHN 还是 NESTED LOOPS 或者 MERGE JOIN 。 这些因素直接决定 SQL 的执行效率，所以优化器是 SQL 执行的核心，它做出的执行计划好坏，直接决定着 SQL 的执行效率。 Oracle 的优化器有两种： RBO( Rule-Based Optimization ): 基于规则的优化器 CBO( Cost-Based Optimization ): 基于代价的优化器 从 Oracle 10g 开始， RBO 已经被弃用，但是我们依然可以通过 Hint 方式来使用它

之前整理的一篇有关 CBO 和 RBO 文章： Oracle CBO 与 RBO http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5709784.aspx Oracle 数据库中优化器（ Optimizer ）是 SQL 分析和执行的优化工具，它负责指定 SQL 的执行计划，也就是它负责保证 SQL 执行的效率最高，比如优化器决定 Oracle 以什么样的方式来访问数据，是全表扫描（ Full Table Scan ），索引范围扫描（ Index Range Scan ）还是全索引快速扫描（ INDEX Fast Full Scan ： INDEX_FFS ） ; 对于表关联查询，它负责确定表之间以一种什么方式来关联，比如 HASH_JOHN 还是 NESTED LOOPS 或者 MERGE JOIN 。 这些因素直接决定 SQL 的执行效率，所以优化器是 SQL 执行的核心，它做出的执行计划好坏，直接决定着 SQL 的执行效率。 Oracle 的优化器有两种： RBO( Rule-Based Optimization ): 基于规则的优化器 CBO( Cost-Based Optimization ): 基于代价的优化器 从 Oracle 10g 开始， RBO 已经被弃用，但是我们依然可以通过 Hint 方式来使用它

前言 SQL优化是程序开发中经常遇到的问题，尤其是在程序规模不断扩大的时候。SQL的好坏不仅制约着程序的规模，影响着用户的体验，甚至威胁着信息的安全。 我们经常听到说哪家平台挂了，哪家网站被黑了，但我们不知道，其实这些平台挂了、被黑了的原因很多时候在于SQL不够健壮。SQL不够健壮易造成数据查询超时、SQL注入、信息泄漏等问题。 SQL优化归根到底是SQL语句的优化，索引的优化。由于很多数据库自带的分析工具不够强大便捷，很多时候要想写出好一点的SQL语句完全凭经验。这也是为什么有人说看一个程序员资历深不深就看他写的SQL好不好的原因。 凭经验做事不总是那么可靠的，况且也并不是人人都有那么多的经验。那如果不靠经验，那新手怎么办？答，使用SOAR！ 什么是SOAR SOAR是SQL Optimizer And Rewriter的简称。SOAR是一个对SQL进行优化和改写的自动化工具，由小米人工智能与云平台的数据库团队开发与维护。现在在GitHub上有4000多星。 功能特点 SOAR有如下功能特点： 跨平台支持（支持Linux,、Mac、Windows环境） 目前只支持 MySQL 语法族协议的SQL优化 支持基于启发式算法的语句优化 支持复杂查询的多列索引优化（UPDATE, INSERT, DELETE, SELECT） 支持EXPLAIN信息丰富解读 支持SQL指纹、压缩和美化