SQL 逻辑优化 case when 转为 union all

通常数据库的优化从硬件层面去考虑可分为4个方面:

CPU:即降低计算复杂度,如减少sql各类聚合函数,窗口函数,case when等。

IO :(较少查询结果集过程中对数据的访问量。数据优化很大程度从这里入手

网络 : 较少查询结果集的大小,去除不必要的查询字段

数据库资源  : 这里讲的数据库资源主要是数据的一些参数设置,如索引、数据缓存。锁的争用,死锁,锁等。 锁问题大部分从业务逻辑上去优化。如拆分事务,降低事务复杂度及事务中的表关联。做到少量多次提交。即让事务尽快完成,释放资源。另一方面,根据业务情况,使用满足需求的低隔离级别的读锁。在业务中对库表的操作尽量使用相同顺序。如相近业务中事务先查询T1表再查询T2表。(mysql中尽量避免使用 replace into .. ,insert into ... on dumplicate ...。并发时容易出现死锁)

举例:

SQL逻辑改写,减少cpu及io的使用:

case when 某些情况转为 union all

简写

SELECT * FROM (
....
(CASE WHEN a.updatetime>b.updatetime THEN a.updatetime ELSE b.updatetime END) as updatetime,

FROM a
LEFT JOIN b on b.ClientID = a.ClientID
) t
WHERE t.updatetime>=‘xxxxx‘

改写:

SELECT ....
a.updatetime AS updatetime ,
FROM a

LEFT JOIN b on b.ClientID = a.ClientID

WHERE a.updatetime>=‘xxxx‘ AND a.updatetime>b.UpdateTime
UNION ALL
SELECT ....
b.UpdateTime as updatetime ,
FROM a
LEFT JOIN b on b.ClientID = a.ClientID
WHERE b.UpdateTime>=‘xxxx‘ AND a.updatetime<=b.UpdateTime

原文地址:https://www.cnblogs.com/vansky/p/8900628.html

时间: 2024-10-12 08:12:41

SQL 逻辑优化 case when 转为 union all的相关文章

SQL优化--逻辑优化--数据库的约束规则与语义优化

1)数据库完整性 ①实体完整性(Entity Integrity):自己 a)一个关系对应现实世界中一个实体集.--ER模型 b)现实世界中的实体具有某种惟一性标识.--主键 c)主关键字是多个属性的组合,则所有主属性均不得取空值.--隐含的索引 ②域完整性(Domain Integrity): 自己的局部 保证数据库字段取值的合理性.属性值应是域中的值,这是关系模式规定了的. 包括: a)检查(CHECK) b)默认值(DEFAULT) c)不为空(NOT NULL) d)可为空(NULL)等

转:sql语句优化

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

SQL语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

[转]sql语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜.  连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行

Sql server2005 优化查询速度50个方法小结

Sql server2005 优化查询速度50个方法小结 Sql server2005优化查询速度51法查询速度慢的原因很多,常见如下几种,大家可以参考下. I/O吞吐量小,形成了瓶颈效应.  没有创建计算列导致查询不优化.  内存不足.  网络速度慢.  查询出的数据量过大(可以采用多次查询,其他的方法降低数据量).  锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷).  sp_lock,sp_who,活动的用户查看,原因是读写竞争资源.  返回了不必要的行和列.  查询语句不好,没有

ORACLE性能优化之SQL语句优化

版权声明:本文为博主原创文章,未经博主允许不得转载. 目录(?)[+] 操作环境:AIX +11g+PLSQL 包含以下内容: 1.  SQL语句执行过程 2.  优化器及执行计划 3.  合理应用Hints 4.  索引及应用实例 5.   其他优化技术及应用 1.SQL语句执行过程 1.1 SQL语句的执行步骤 1)语法分析,分析语句的语法是否符合规范,衡量语句中各表达式的意义. 2)语义分析,检查语句中涉及的所有数据库对象是否存在,且用户有相应的权限. 3)视图转换,将涉及视图的查询语句转

深入浅出数据仓库中SQL性能优化之Hive篇

转自:http://www.csdn.net/article/2015-01-13/2823530 一个Hive查询生成多个Map Reduce Job,一个Map Reduce Job又有Map,Reduce,Spill,Shuffle,Sort等多个阶段,所以针对Hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会有细分),针对MR全局的优化,和针对整个查询(多MR Job)的优化,下文会分别阐述. 在开始之前,先把MR的流程图帖出来(摘自Hadoop权威指南),方便后面对照.另

数据仓库中的 SQL 性能优化(Hive篇)

一个Hive查询生成多个map reduce job,一个map reduce job又有map,reduce,spill,shuffle,sort等多个阶段,所以针对hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会有细分),针对MR全局的优化,和针对整个查询(多MR job)的优化,下文会分别阐述. 在开始之前,先把MR的流程图帖出来(摘自Hadoop权威指南),方便后面对照.另外要说明的是,这个优化只是针对Hive 0.9版本,而不是后来Hortonwork发起Stinger

Oracle SQL性能优化

转载自:http://www.cnblogs.com/rootq/archive/2008/11/17/1334727.html (1)      选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection ta