sql优化改写

举一反三思路思考形如（列=参数 or decode函数）最近又遇到新鲜的语句写法计划：首先语句主要的问题在于or条件首先理解decode函数那么可以得出 DECODE(c1, 1, 6, NULL, 6, c1) =6 C1=1结果赋值为6，null结果赋值为6，其他还是c1，最终满足等于6的条件。还记得之前分享过形如（列 is null or 列等值）改写成nvl，此时利用举一反三思维，最终其实就是求c1=5,1,null,然后null可以用nvl，最终 (c1=5 or DECODE(c1, 1, 6, NULL, 6, c1) =6 ); 改成nv

关于非相关子查询改写经验最近又又又再项目中遇到这样奇奇怪怪的写法计划：从计划上看只能做非相关子查询，即每次获取主查询一条记录去子查询根据条件判断过滤获取结果。为什么会这样？原因是因为exists中select存在主查询条件作为查询项得出结果后还要通过where去过滤，因此只能主查询一条一条去判断，主查询数据量增加，效率急剧下降。这种写法需要转换成相关子查询，即做成相关关联，将子查询做成结果集与主查询关联。思路拆解获取子查询结果集，子查询查询项 sum(sum(t3.ll*0.5)+nvl(max(t2.ll),0)) o

Like关联优化最近遇到这样有趣的写法计划：语句为了排除不在板块的单位，做法是先把单位code合并成一行进行模糊匹配排除。计划做成nest loop semi join2（嵌套循环），相当于一条一条去模糊匹配筛选排除，由此性能消耗高。关联列一旦先合并处理之后，和其他表做关联时做成like关联匹配，这样的效率会低，因此不宜合并处理。根据对语句的逻辑上理解，排除t2不在t1中的单位，且code的长度为4，“不在”可以转换成not exists，like关联转换成substr方式。

关于层次关系的数据统计最近在项目中遇到这样的一个场景，根据文件类型分类统计本级及其下级的文件总数量，即本级的统计的总数包含下级的数据， T1表是文件数据表，t2表是关系表一开始的语句写法如下：

‘||’拼接条件写法的优化最近遇到一个有趣写法的语句，如下：计划：计划是全表扫，‘||‘拼接条件的写法无法使用索引，‘||’是拼接符，合并，相当于and,我们可以把条件做一下转换。

时间条件高效用法项目上接到业务是这样的，一个分区表5千万，然后要根据时间条件去分批更新数据。看了一眼已经写好的脚本，简化成下面的查询语句，我们来看看问题：

消除无关列项目中做报表统计时，经常使用union al合并放到一个视图里，然而为了方便总是喜欢使用select * ，导致消耗不必要的性能。 2、问题数据准备

先过滤后关联的优化经验分享最近遇到一个问题，发现开发人员比较喜欢单一的将表放一块一起做关联。如果有了先过滤后关联的思维，大部分语句的性能会获得提升。以下是真实项目简化而来的例子

union 和 union all的区别UNION对两个结果集进行并集操作，不包括重复行，相当于使用distinct关键字。而UNION ALL则对两个结果集进行并集操作，包括重复行，即所有结果全部显示，不管是否重复。 UNION操作会去除重复的记录，只返回唯一的记录。而UNION ALL操作则不会去除重复记录，会直接连接所有的值。 UNION操作会按照字段的顺序进行排序，而UNION ALL操作则不会对结果进行排序。因此我们在项目中能用union all的就使用union all，避免union排序去重增加性能。

like关联改写instr：字符串查找函数substr: 字符串截取函数LIKE:模糊匹配其三者之间的转换这里问题在于驱动表为t2，index join次数100万次，前面说过与substr和instr可以等价转换，这里想要转换驱动表，那么就需要用substr。

OR关联改写经验or是一种逻辑运算，or条件成立的情况如下：条件1 条件2 or运算真真真真假真假真真假假假 or运算相当于只要满足一个条件为真，它就返回真。在运算中与union all计算有相似之处集合1 集合2 union all结果有数据有数据有数据有数据无数据有数据无数据有数据有数据无数据无数据无数据只要一个集合中有数据，union all就有数据。因此在优化中经常用此作为改写替换的方法。

标量子查询优化（二）Left join：返回包括左表的所有记录和右表满足关联关系的记录，不满足的记录置为空。标量子查询：子查询返回的是单一值的标量。 Left join和标量子查询关联：left join中右表的关联列如果是唯一值，那么在实际的语句中可以改写成标量子查询。

我是有底线的