SQL 性能优化

当我看到sql执行很慢的时候就在想为什么这么慢?

不外乎数据大,sql语句复杂,没有索引。

如果要进行优化的话可以从对应的这三个问题出发:

看看表是否可以进行拆分成小表,拆分sql语句,建立适合的索引。

还有查看sql server官方API文档,了解sql的关键字执行顺序,了解执行顺序后才能更好的对sql进行拆分或者优化。

关于sql执行顺序

标准的SQL 的解析顺序为:参考文章

查询的逻辑执行顺序:

 (1) FROM < left_table> 

 (2) ON < join_condition> 

 (3) < join_type>  JOIN < right_table> 

 (4) WHERE < where_condition> 

 (5) GROUP BY < group_by_list> 

 (6) WITH {cube | rollup}

 (7) HAVING < having_condition> 

 (8) SELECT 

 (9) DISTINCT 

(10) ORDER BY < order_by_list> 

(11) < top_specification>  < select_list>

标准的SQL 的解析顺序为:

(1).FROM 子句 组装来自不同数据源的数据

(2).WHERE 子句 基于指定的条件对记录进行筛选

(3).GROUP BY 子句 将数据划分为多个分组

(4).使用聚合函数进行计算

(5).使用HAVING子句筛选分组

(6).计算所有的表达式

(7).使用ORDER BY对结果集进行排序

执行顺序:

1.FROM:对FROM子句中前两个表执行笛卡尔积生成虚拟表vt1

2.ON:对vt1表应用ON筛选器只有满足< join_condition> 为真的行才被插入vt2

3.OUTER(join):如果指定了 OUTER JOIN保留表(preserved table)中未找到的行将行作为外部行添加到vt2 生成t3如果from包含两个以上表则对上一个联结生成的结果表和下一个表重复执行步骤和步骤直接结束

4.WHERE:对vt3应用 WHERE 筛选器只有使< where_condition> 为true的行才被插入vt4

5.GROUP BY:按GROUP BY子句中的列列表对vt4中的行分组生成vt5

6.CUBE|ROLLUP:把超组(supergroups)插入vt6 生成vt6

7.HAVING:对vt6应用HAVING筛选器只有使< having_condition> 为true的组才插入vt7

8.SELECT:处理select列表产生vt8

9.DISTINCT:将重复的行从vt8中去除产生vt9

10.ORDER BY:将vt9的行按order by子句中的列列表排序生成一个游标vc10

11.TOP:从vc10的开始处选择指定数量或比例的行生成vt11 并返回调用者

参考文章:拆分表和拆分sql

时间: 2024-10-10 12:18:22

SQL 性能优化的相关文章

Oracle SQL性能优化

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

SQL性能优化案例分析

这段时间做一个SQL性能优化的案例分析, 整理了一下过往的案例,发现一个比较有意思的,拿出来给大家分享. 这个项目是我在项目开展2期的时候才加入的, 之前一期是个金融内部信息门户, 里面有个功能是收集各个上市公司的财报, 然后做各种分析, 数据图表展示, 使用的人数并不多, 仅百人左右. 2期打算面向行外用户, 刚开始预计同时在线人数不超过50, 就以50访问用户/秒的性能测试, 结果在把1期的图表类数据展示响应基本在5分钟左右, 属于严重不可用, 说说我们的服务器配置, 有2台网站前端承载用户

数据仓库中的 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

&lt;转&gt;Oracle SQL性能优化

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

SQL Select count(*)和Count(1)的区别和执行方式及SQL性能优化

SQL性能优化:http://www.cnblogs.com/CareySon/category/360333.html Select count(*)和Count(1)的区别和执行方式 在SQL Server中Count(*)或者Count(1)或者Count([列])或许是最常用的聚合函数.很多人其实对这三者之间是区分不清的.本文会阐述这三者的作用,关系以及背后的原理. 往常我经常会看到一些所谓的优化建议不使用Count(* )而是使用Count(1),从而可以提升性能,给出的理由是Coun

关于SQL性能优化的十条经验

1.查询的模糊匹配 尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用. 解决办法: 其实只需要对该脚本略做改进,查询速度便会提高近百倍.改进方法如下: a.修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了. b.直接修改后台——根据输入条件,先查出符合条件的供应商,并把相关记录保存在一个

1.SQL优化系列--&gt;高手详解SQL性能优化十条经验

1.查询的模糊匹配 尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用. 解决办法: 其实只需要对该脚本略做改进,查询速度便会提高近百倍.改进方法如下: a.修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了. b.直接修改后台——根据输入条件,先查出符合条件的供应商,并把相关记录保存在一个

Oracle SQL性能优化系列

1. 选用适合的ORACLE优化器 ORACLE的优化器共有3种: a. RULE (基于规则) b. COST (基于成本) c. CHOOSE (选择性) 设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你当然也在SQL句级或是会话(session)级对其进行覆盖. 为了使用基于成本的优化器(CBO, Cost-Based Optimizer) , 你必须经常运行an

SQL性能优化前期准备-清除缓存、开启IO统计

如果需要进行SQl Server下的SQL性能优化,需要准备以下内容: 一.SQL查询分析器设置: 1.开启实际执行计划跟踪. 2.每次执行需优化SQL前,带上清除缓存的设置SQL. 平常在进行SQL Server性能优化时,为了确保真实还原性能问题,我们需要关闭SQL Server自身的执行计划及缓存.可以通过以下设置清除缓存. 1 DBCC DROPCLEANBUFFERS --清除缓冲区 2 DBCC FREEPROCCACHE --删除计划高速缓存中的元素 3.开启查询IO读取统计.查询

使用EntityFrameWork 5.0面向存储过程(&amp;执行Sql,性能优化)

EntityFrameWork5.0简单使用 概要: 使用EntityFrameWork5.0执行存储过程,Sql语句(DDL/DML)以及一点关于优化性能的方面; 正文: 在myef.tt下会包含需要展示数据的存储过程(select) 模型浏览器如下, 1.EF如何调用存储过程: Note:数据库的表对应的实体,以类对象表示,在EF容器下可以直接操作,比如db.UserAccount直接拿到UserAccount实体对象,存储过程,视图也是同样道理,也是可以通过EF上下文容器得到; 2.EF执