SQL 执行进展优化

聚集索引扫描

SELECT *  FROM C_SY_Ownedstorm

聚集索引扫描比表扫描快

聚集索引扫描:发生于聚集表,也相当于全表扫描操作,但在针对聚集列的条件等操作时,效率会较好。

表扫描

SELECT *   FROM #temp

表扫描:发生于堆表,并且没有可用的索引时,会发生表扫描,表示整个表扫描一次。

测试SQL

CREATE TABLE t1(c1 INT, c2 VARCHAR (8000));

 GO

  DECLARE @a INT;

  SELECT @a = 1;

 WHILE (@a <= 5000)

 BEGIN             

     INSERT INTO t1 VALUES (@a, replicate(‘a‘, 5000))

     SELECT @a = @a + 1

 END

 GO
 SELECT count(1) FROM t1

 group by  c1

哈希匹配:

哈希匹配的作用就是把它右侧的两个表中行数比较少的那个经过哈希算法形成一个哈希表,然后再有另一个数据行数比较大的表来之前形成的哈希表中匹配查找数据,大体上就是这个么流程。但是哈希匹配操作的出现一定要提高我们的警惕,当哈希匹配右侧的两个表中的数据有一个比另一个明显的少的时候,哈希匹配的效率会比较高,反之就会影响效率。出现哈希匹配大概有这么几个情况:

有缺失或者不正确的索引

缺少where字句

在where子句中有对列的类型转换或者数据操作,这样就不能使用索引了

虽说哈希匹配在某些情况下效率会比较高,但是这并不意味着没有更好的来提高这个查询的效率,比如添加适当的索引或者通过where语句来减少数据量等方法。换句话说,当出现哈希匹配这个操作的时候,我们要引起注意,看看是否还有别的方法来提高查询效率,如果没有的话,或许哈希匹配就是最好的选择了。

聚集索引查找:

CREATE UNIQUE CLUSTERED INDEX _Id

ON t1(c1)

select  * from  t1

where c1=3

排序:

排序是消耗性能的,sql server中排序是在数据找出来以后在进行排序的。

 select  * from  t1
  order by desc

循环嵌套

对于使用简单内连接的小数据量表,嵌套循环是最佳策略。最适合两个表的记录数差别非常大,并且在连接的列上都有索引的情况。嵌套循环连接所需的I/O和比较都是最少的。

嵌套循环在外表(往往是小数据量的表)中每次循环一个记录,然后在内表中查找所匹配的记录并输出。有很多关于嵌套循环策略的名字。例如,对整个表或索引进行查询,称为Naive(无知的)嵌套循环连接。使用正常索引或临时索引时,被称为索引嵌套循环连接或临时索引嵌套循环连接。

合并连接

合并连接也是在读的同时对两个存储输入的一行进行比较。在每个步骤中,比较每个输入的下一行。如果两行是相同,输出一个连接后的行并继续。如果行是不同的,舍弃两个输入行中较少的那个并继续。因为输入是存储,连接舍弃的任何行必须比两个输入中任何剩下的行要小,因此可以永不连接。合并连接不需要对两个输入中的每一行扫描。只要到了两个输入中的某一个的末尾,合并连接就会停止扫描。

嵌套循环连接总的消耗和在输入表中行的乘积成比例,不同于嵌套循环连接,合并连接的表最多读一次,总的消耗和输入行数的总数成正比例,因此何必连接对于大量的输入是较好的选择。

时间: 2024-08-25 02:54:06

SQL 执行进展优化的相关文章

执行3小时超长SQL的分析优化过程:从索引遇见IS NULL,到最佳实践

月底高峰期,对一个典型项目抽查分析时,发现了一个超级慢.全表扫描的SQL,语句很简单,AWR中赫然在列,在我统计的截止时间内还没有结束... 使用v$active_session_history进一步确认:该SQL执行了接近3个小时! 获取SQL的完整信息,发现该语句并不复杂,但看到 IS NULL 似乎就明白了问题所在,索引失效.全表扫描... 虽然该表上已经创建有 period和year两列的索引,但选择性太低了,优化器还是决定使用 Table Access Full,即使在该索引的后面增加

SQL Server 并行操作优化,避免并行操作被抑制而影响SQL的执行效率

为什么我也要说SQL Server的并行: 这几天园子里写关于SQL Server并行的文章很多,不管怎么样,都让人对并行操作有了更深刻的认识. 我想说的是:尽管并行操作可能(并不是一定)存在这样或者那样的问题,但是我们不能否认并行,仍然要利用好并行. 但是,实际开发中,某些SQL语句的写法会导致用不到并行,从而影响到SQL的执行效率 所以,本文要表达的是:我们要利用好并行,不要让一些SQL的写法问题“抑制”了并行,让我们享受不了并行带来的快感 关于SQL Server的并行: 所谓的并行,指S

mysql优化之sql执行流程及表结构(schema)对性能的影响

part 1 sql执行流程(如下图所示) 1.客户端发送一条查询到服务器. 2.服务器通过权限检查后,先检查查询缓存,命中则直接返回结果.否则进入3. 3.服务器进行sql解析,预处理,再由优化器根据该sql涉及到的数据表的信息计算,生成执行计划. 4..MySQL根据优化器生成的执行计划,调用存储引擎的API来执行查询:5..将结果返回给客户端. 总结:SQL执行的最大瓶颈在于磁盘的IO,即数据的读取:不同SQL的写法,会造成不同的执行计划的执行,而不同的执行计划在IO的上面临完全不一样的数

SQL Server性能优化(1)使用SET函数

在一切开始之前,先看下微软的建议:在系统的整体性能优化里面, TSQL优化优先级并不是最高的. 本文包括四部分: SET STATISTICS TIME ON SET STATISTICS IO SET SHOWPLAN_ALL ON SET STATISTICS PROFILE ON SET 函数主要是为了显示sql执行时的查询计划,CPU.硬盘使用情况. 1. SET STATISTICS TIME ON:当 SET STATISTICS TIME 为 ON 时,会显示语句的时间统计信息.为

谈谈SQL 语句的优化技术

在SQL server 的性能优化过程中,TSQL的语句优化是很重要的一环.当您使用各种手段找出系统最需要优化的语句后,应该如何对该语句进行优化呢?下面列出一些TSQL 语句优化的常见技巧. 1.     语句的执行计划分析 首先要对该语句的执行计划(execution plan)进行分析,找出语句运行慢的原因.比如说, <>在检查执行计划是否包含table scan /index scan等昂贵的操作? <>对table, worktable是否进行了大量的逻辑读? <&g

SQL Server 数据库优化剖析

一.SQL Profiler 事件类 Stored Procedures\RPC:Completed TSQL\SQL:BatchCompleted 事件关键字段 EventSequence.EventClass.SPID.DatabaseName.Error.StartTime.TextData. HostName.ClientProcessID.ApplicationName. CPU.Reads.Writes.Duration.RowCounts 1.跟踪慢SQL 2.跟踪SQL执行错误

Sql Server性能优化辅助指标SET STATISTICS TIME ON和SET STATISTICS IO ON

1.前言 对于优化SQL语句或存储过程,以前主要是用如下语句来判断具体执行时间,但是SQL环境是复杂多变的,下面语句并不能精准判断性能是否提高:如果需要精确知道CPU.IO等信息,就无能为力了. PRINT convert(varchar(30),getdate(),121) select * from Sales.SalesOrderDetail where SalesOrderID > 64185 PRINT convert(varchar(30),getdate(),121) 这时候如果使

SQL SERVER 性能优化

1. 选择最有效率的表名顺序(只在基于规则的优化器中有效) SQLSERVER的解析器按照从右到左的顺序处理FROM子句中的表名,因此FROM子句中写在最后的表(基础表driving table)将被最先处理,在FROM子句中包含多个表的情况下,必须选择记录条数最少的表作为基础表,当SQLSERVER处理多个表时,会运用排序及合并的方式连接它们. 首先,扫描第一个表(FROM子句中最后的那个表)并对记录进行排序:然后扫描第二个表(FROM子句中最后第二个表):最后将所有从第二个表中检索出的记录与

oracle &nbsp; SQL执行过程

1.sql执行过程 1>解析(判断对象是否存在,是否有权限查询,语义解析,检查缓存中是否有相同的SQL等等) 2>优化(CBO确定优化模式,确定访问路径,联接顺序,过程中通过很多综合因素估算出各种方式的资源消耗,选择消耗最小为优) 3>生成QEP(Query Execution Plan:查询执行计划) 4>执行QEP,返回结果