DM8达梦数据库SQL调优

       SQL调优的好坏直接影响了数据查询的效率，并且会直观的反映给用户。如果查询数据很慢的话会非常影响用户的体验。所以在数据库优化的最后，必要进行SQL的优化。尤其是经常使用的SQL和系统中非常重要的SQL必须要做到优化到最高的效率。本文从基本SQL编写习惯和阅读执行计划两部分来介绍SQL的优化

目录

1.基本SQL编写习惯

1.1 避免使用 "or"

1.2 避免在模糊匹配的时候两边都使用正则表达式

1.3 避免使用*进行查询

1.4 避免在同一个表上建太多的索引

1.5 exist语句与in语句的选择

1.6 避免在条件字段加函数运算

2.执行计划解读

2.1 执行计划操作符介绍

2.2 执行计划解读流程

2.3 执行计划实战

---

1.基本SQL编写习惯

1.1 避免使用 "or"

       在条件语句中使用or会严重的影响性能。此时在 修改sql的时候可以把or改成union语句，可以提升不小的效率。在逻辑允许的情况下使用union all的效果会更佳。因为当SQL 语句需要UNION两个查询结果集合时，这两个结果集合会以UNION-ALL的方式被合并， 然后在输出最终结果前进行排序。 如果用UNION ALL替代UNION， 这样排序就不是必要了，效率就会因此得到提高。

       如果是基本条件中使用了or语句，可以改成in语句，这样不仅看起来SQL语句更简洁更美观，而且会大大提升效率。

1.2 避免在模糊匹配的时候两边都使用正则表达式

        如果在条件中模糊匹配时有类似于A like '%XXX%'的形式，对于这种类型的语句，数据库会跳过索引直接走全表扫描，大大影响了效率。

1.3 避免使用*进行查询

       避免使用select *或者select count(*)来进行查询。这种写法会让执行器的压力非常大，很影响效率。在不是全表的列都需要查询的情况下应该使用select 列名替换。count的写法跟select一样，最优的选择就是使用count(列名)。

1.4 避免在同一个表上建太多的索引

       如果表上有大量的增删改操作，那么在索引非常多的表上是很慢的。所以建索引时需要优化所以的数量，只建必要的索引。

1.5 exist语句与in语句的选择

      因为in语句是先遍历子查询，而exist语句先遍历主查询，所以当子查询数据小于主查询时使用in，当子查询数据大于主查询时使用exist。

        当使用not in或者not exists时，在业务允许的情况下使用not exist是比not in效率高的。

1.6 避免在条件字段加函数运算

      避免出现

      select *from table_1 where to_char(data_date,'yyyymmdd')='20211020'

      这种情况下应该把SQL改成

      select *from table_1 where data_date=to_date('20211020','yyyymmdd')

2.执行计划解读

查看执行计划是SQL优化的基础。能正确的理解执行计划对SQL的优化有着非常大的帮助。

2.1 执行计划操作符介绍

NEST 收集结果集，用于结果集收集的操作符，一般是查询计划的顶层节点。

PRJT 投影，用于选择表达式项的计算；广泛用于查询，排序，函数索引创建等。

SLCT 选择，用于查询条件的过滤。

AAGR 简单聚集，用于没有group by的count sum age max min等聚集函数的计算。

FAGR 快速聚集，用于没有过滤条件时从表或索引快速获取MAX/MIN/COUNT值。

HAGR HASH分组聚集，用于分组列没有索引只能走全表扫描的分组聚集。

SAGR 流分组聚集，用于分组列是有序的情况下，可以使用流分组聚集.

BLKUP 二次扫描,先使用2级别索引定位，再根据表的主键、聚集索引、rowid等信息定位数据行。

CSCN 全表扫描。

SSEK 索引扫描，二级索引扫描即先扫描索引，再通过主键、聚集索引、ROWID等信息去扫描表。

CSEK 索引扫描，聚集索引扫描只需要扫描索引，不需要扫描表

SSCN 索引扫描，索引全扫描，不需要扫描表

2.2 执行计划解读流程

上图是一个普通SQL的执行计划，执行计划树类似于

 

       执行计划中缩进越多的越先执行，同样缩进的上面的先执行，下面的后执行，上下的优先级高于内外的。由此可知上图的执行顺序是S4---S3---S6---S5---S2---S1。

       看上图的执行计划后边还跟了代价，结果集，行数据处理，他们分别的意思是

代价：表示执行此操作需要的代价，单位是毫秒；

结果集：表示该计划节点扫描的行数；

行数据处理:输出的字节数。

2.3 执行计划实战

      CSCN2表示此查群走的是全表扫描代价是1ms，有一个选择查询代价是1ms，然后是一个用于查询的操作和收集结果集。

        由于选择条件EMPLOYEE_ID字段是表的主键，所以查询时先走了索引扫描，代价是1ms。然后 是二次扫描BLKUP2，最后是一个用于查询的操作和收集结果集。

        此查询执行计划中有一个 ACTRL 操作符，它说明优化器为这一条 SQL 语句生成了备用计划。ACTRL 是控制备用计划转换的操作符，其上面一层 NEST LOOP INDEX JOIN2 为默认的主计划，再上面一层 HASH2 INNER JOIN 则为备用计划。ACTRL 操作符会计算下层子节点的代价，来决定采用默认主计划还是备用计划。

更多资讯请上达梦技术社区了解：https://eco.dameng.com