Oracle性能优化 对于分组排序的算法优化

Posted 2023-05-15

有两张表
物料表material
栏位 ID,料号.....
价格表Price
栏位 id,物料ID,价格生效日,价格...
一个物料可能有多个生效日都有价格

用户输入料号,要求显示相关物料及每个物料的最新价格

SQL :select 料号,生效日,价格 from
material m
inner join (
select a.物料ID,a.价格生效日 from material a
inner join (select 物料ID,max(价格生效日) as 价格生效日 from price ) b on
a.物料ID=b.物料ID and a.价格生效日=b.价格生效日) n on m.id=n.物料ID
where m.料号='AAA'

每次执行执行计划都是从内部开始,那么就挂不 .料号='AAA'的条件,会对价格表进行全表扫描,当价格表的数据量上千万的时候性能就很差

参考技术A select 料号,生效日,价格 from
material m
inner join (
select a.物料ID, max(a.价格生效日) 价格生效日 from material a, price b
where a.物料ID=b.物料ID and a.价格生效日=b.价格生效日
and a.料号='AAA'

) n on m.id=n.物料ID

下面这三个字段上分别建索引

material：料号
material：物料ID

price ：物料ID追问

可能是我举例子的时候描述简单了... 其实要是这样就好办了 .这个是在拼装语句中的一部分,而且其实里面那个join的条件中是没有料号这个栏位的,要是为了把料号拼装进去,就要多关联好几张表.而且用户输入不确定,不一定是用料号查询,所以里面那个join要拼接的表也就没法确定,除非根据用户的输入确定需要拼接什么表 .那个查询语句中这样的拼接有好多,现在代码就一个Select就几百行了.若全部根据用户输入去拼接..

我眼中的 Oracle 性能优化

 恒生技术之眼 作者 林景忠

大家对于一个业务系统的运行关心有如下几个方面:功能性、稳定性、效率、安全性。而一个系统的性能有包含了网络性能、应用性能、中间件性能、数据库性能等等。

今天从数据库性能的角度，浅谈Oracle性能优化的一些看法。

首先对于性能问题，大家先接触的一般都是某个业务功能慢，速度客户无法接受。那对于系统的性能无非如下图所示：

当一个性能问题出现时，很多人都会猜测问题各个方面的原因。
今天主要谈数据库的性能问题，就问题而言，我们针对问题经过数据库性能分析，发现数据库性能存在问题,那么就需要对数据库性能问题进行优化解决。

从性能优化角度看，每个人都希望经过优化数据库系统运行的速度越快越好。但是希望终归是希望，系统优化最终能到达什么程度和数据库系统的很多方面有关系。

从优化的角度看，数据库的性能问题基本可以分为几类问题：操作系统性能问题、IO性能问题、数据库系统性能问题、SQL性能问题、网络性能问题等等。

而根据实际结果统计，数据库性能问题80%以上都是SQL性能问题引起。下面谈SQL性能问题之前，介绍一个经常遇见的一个系统配置问题：接到客户电话说“今天做交易系统的历史数据归档，做完历史数据归档后，原来历史放了3年的历史数据，现在历史表只有1年不到的数据，但是查历史的菜单比原来慢了很多，看了SQL执行计划比较，原来是走索引的，现在走的是全表扫描，该怎么处理？”

针对该问题，根据经验：
▪ 首先确认历史表是分区表
▪ 然后让客户检查数据库参数optimizer_index_cost_adj，根据标准参数配置optimizer_index_cost_adj=10，建议客户把这个参数设置成5试一下，客户根据建议改了之后，这个问题解决了。

这个问题看似SQL问题，但是通过数据库参数得到解决，说明数据库的很多问题都是互相关联和影响的。

既然数据库性能问题80%以上都是SQL性能问题引起，接下来聊聊对SQL优化的个人一些看法。

说个人看法之前，网上或者面试的时候，大部分人对SQL优化的一致解决方法都是“先从awr报告找出有性能问题的SQL（awr中top sql中耗时长的、消耗逻辑读、物理读的sql）、看sql的执行计划，看sql的执行计划的时候，关注有没有全表扫描、有没有cost很大的操作，然后尝试新建索引、调整索引、调整表的访问顺序、再执行SQL试试看。”

这个步骤其实也没有太大的问题，80%到90%的SQL问题也基本能解决，个人存在的问题是优化的效果具有不确定性。

我的看法是对于SQL优化应该可以通过优化方法，让SQL优化的效果有比较好的确定性，因为有很多的环境是不能让我们这样调整下试试看的。

我的看法是这样的，在SQL优化的时候，首先我们要像解读程序一样先解读SQL，如这个SQL的主要作用是什么，有没有特殊的操作如group by、order by、sum、分页查询等，涉及了几张表、表的数据规模怎么样，表的条件有哪些，这些条件对于表的数据的选择性怎么样。了解这些信息之后，基本也可以确定这个SQL最优的执行计划该是什么样的，再查看执行计划的时候就很容易发现执行计划的问题并知道该如何修正。如果没有了解以上信息，查看执行计划的时候会相对比较盲目。

查看执行计划的时候关注那些方面，主要有如下几点：
▪ 访问了哪些表
▪ 表的访问方式（表的访问顺序、表是索引扫描还是全表扫描、）
▪ 表的连接方式 （nest loop join、hash join、sort merge join、连接是否存在笛卡尔积）
▪ 字段条件的选择性是否合理（相关字段索引情况、索引的选择性是否合理）
▪ 排序方法（根据什么样的字段排序）
▪ 数据获取方式（返回一个结果集的大小）

确认了以上几个方面之后，经过优化之后再确认上面的执行计划信息就基本可以确认优化的效果是怎么样的。SQL优化的目的是减少SQL的系统资源的消耗，在SQL执行计划中也要关注减少表的访问次数，如A表如果在SQL中访问一次即可，不要多次访问。

有人会说，有些SQL很长，可能一个SQL里面就有20张表的访问，如果遇到这样的SQL，就需要根据SQL的结构对SQL进行拆解，然后再逐步优化，就能比较准确地进行SQL优化。
对于SQL优化，希望大家要像看算法一样去解读SQL，总结出属于自己的SQL优化方法！