• 开篇小测验

  下面这样一个小SQL 你该怎么样添加最优索引

  两个表上现在只有聚集索引

  bigproduct 表上已经有聚集索引 ProductID
  bigtransactionhistory 表上已经有聚集索引 TransactionID

  

select p.productnumber,p.reorderpoint,th.Quantity
from bigproduct as p
join bigtransactionhistory as th on th.productid=p.productid and th.TransactionDate > p.SellStartDate
where p.name in ('LL Crankarm1000','ML Crankarm1000') and th.TransactionDate > '2010-01-01'

  你是否一眼就能看出来呢?

  

  答案将在文章中逐步揭晓~~~

  • 简单粗暴的添加索引

  看过我前面文章的看官们一定会发现我很喜欢用“简单粗暴”这个词,一是因为词汇量小文笔也差,真心用不出高大上的词儿! 再一个,你们不喜欢简单粗暴么~~干货最重要,不是么?

  

  首先我们看一下没有优化前的执行计划

  

  

  

  clustered index scan 这其实就是表扫描,不是table scan 只是因为表上有聚集索引

  可以看出这个查询俩表都使用了表扫描!  

  

  where 条件添加索引

  首先大多数人都知道 where 条件中的字段需要添加索引! 我们添加一下看看效果创建

  在 bigproduct 表上创建 name 列索引 ,在bigtransactionhistory表上创建 TransactionDate 列索引。

  再次执行语句看一下效果!

  

  

  

  添加where索引以后可以看到以下几个现象

  1. bigproduct 从原来的clustered index scan 变成 index seek
  2. 另外多出来个KEY Lookup(clustered)
  3. bigproduct 上添加的索引起了作用,逻辑读bigproduct 由 601 变成 10。
  4. bigtransactionhistory 没啥变化啊 还是clustered index scan

  

  解释一下出现的现象 : 首先一点bigproduct 边添加的where 条件索引,起到了作用,执行的时候不是全表扫描了,逻辑读有明显的下降,出现的 KEY Lookup 是因为选择(select)的列,在索引中没有,而需要通过聚集索引再查找一次,再找一次也意味着多一部分开销!

  那么同样添加了where 条件索引的bigtransactionhistory 表为什么没起作用呢? 那是因为SQL优化器在选择计划的时候认为,不使用TransactionDate 列索引查找效率会更好!

  真的么? 我们来验证一下,通过指定选择索引,来让优化器选择索引查找!

  

  

   强制使用索引以后,可以看出逻辑读由 14W 变成1961W,语句时间也变得很长,这就是优化器为什么不选用你加的索引!优化器还是很智能的吧。

  高能预警:优化器可不是什么时候都这么智能的...由于缓存计划或优化器抽风等原因,也会出现优化器用了这种索引,导致你的语句奇慢,读飙升直接影响到你的内存、磁盘、CPU资源!另外如果这样一条语句是系统中一条很频繁运行的语句,你的系统就挂了!没错就挂了!这就是开篇抛出的问题就是因为一条语句!

  消灭Key Lookup 添加select 字段

   这就是传说中的覆盖索引!

   看到执行计划中存在Key Lookup 而且消耗占比很高,如上面强制索引的计划,那么我们就要想到的 在索引中包含那些SELECT 的列!如果消耗低,逻辑读少,如上面bigproduct 表中的Key Lookup 就可以忽略(如果你追求完美,也一样优化就可以了)。

   包含列的图形化创建 :

   

   

   语句创建就是 :

   

CREATE NONCLUSTERED INDEX TransactionDate
ON [dbo].[bigTransactionHistory] ([TransactionDate]) ------INCLUDE 就是包含列
INCLUDE ([ProductID],[Quantity])
GO

   下面我们添加一下看看效果 :

   

   

  添加select 索引字段后可以看出的现象:

  1. 优化器自己选择了index seek
  2. bigtransactionhistory占比最高的Key Lookup消失了
  3. 逻辑读由原来无索引的14W变成1W
  4. bigtransactionhistory表还提示缺少索引?

   

   通过优化索引添加select 字段,我们看出语句又一次得到了提升 bigtransactionhistory 从表扫描变成索引查找,逻辑读由14W变成 1W!这是一个质的飞跃啊!

  那为什么还提示缺少索引呢? 创建一下试试吧!

  索引再优化加入表关联列

  按照提示我们创建索引 : 和上一个索引的不同 ProductID 列由包含列变成了索引列!

USE [AdventureWorks2012]
GO
CREATE NONCLUSTERED INDEX ProductID_TransactionDate
ON [dbo].[bigTransactionHistory] ([ProductID],[TransactionDate])
INCLUDE ([Quantity])

  我们看一下效果:

  

  

  再次优化索引以后可以看到以下几个现象

  1. bigtransactionhistory表还是索引查找index seek
  2. bigtransactionhistory依然没有了Key Lookup
  3. 两表关联的hash join 变成了nested loops
  4. 并行计划变成了串行
  5. 逻辑读又从1W 变成18

  又一次质的飞跃!读从原来的14W 变成1W 又变成18,这样大大减少了内存和IO的消耗,另外并行计划也变成了串行,无疑又减少了大量CPU的消耗!语句时间,我想这里就不用多说了吧?

  

  高能预警:这里所说的hash join,并行变串行,不懂的朋友可以在百度自行学习,这里只是针对当前语句的情况,不能一概而论!

  精简你的索引

  大家都知道,索引会导致update、insert、delete操作变慢!那么尽量精简你的索引就是一个很重要的话题了!

   上面的优化过程中我们创建了几个索引,以bigTransactionHistory为例来看一下:

  

   脚本这里就不贴了,其实我们最后创建的索引 ProductID_TransactionDate包含Quantity 已经包含了前两个索引,而且可以说无论任何类似语句都使用ProductID_TransactionDate包含Quantity 就可以了!

   那么我们就可以清除前两个索引!

    

  

  至此语句的优化算是结束了,留下的就是bigproduct 依然有一个Key Lookup可以优化,可以仿照上面的继续优化,这里就不细说了。语句只是经过了简单的索引优化就从一辆2手QQ变成了法拉利,是不是很神奇?

  这就是索引的重要性!

SQL优化:索引的重要性的更多相关文章

  1. 160531、SQL优化-索引

    SQL优化有很多方法,今天来说一说数据库索引. 举例说明: 假设有一个图书Book表,里面有字段id,name, isbn等.如果图书数量巨大的话,我们通过isbn查询通常是比较慢的. 添加数据库索引 ...

  2. SQL优化-索引

    (一)深入浅出理解索引结构 实际上,您可以把索引理解为一种特殊的目录.微软的SQL SERVER提供了两种索引:聚集索引(clustered index,也称聚类索引.簇集索引)和非聚集索引(nonc ...

  3. mysql 开发进阶篇系列 3 SQL 优化(索引使用方法)

    一. 本章介绍mysql中的索引的分类,存储,使用方法的介绍 1.  索引的存储分类 MyISAM存储引擎的表的数据和索引是自动分开存储的,各自是独立的一个文件, innodb 存储引擎的表的数据和索 ...

  4. Oracle sql 优化の索引监控

    1.监视索引是否使用 除了主键是完整性约束而自动变为索引外,创建普通索引的目的就是为了提高查询速度,如果我们创建了索引而没有被使用,那么这些不被使用的索引将起到阻碍性能的作用. 语法: --检查某个索 ...

  5. sql优化,索引学习

  6. 数据库的规范和SQL优化技巧总结

    现总结工作与学习中关于数据库的规范设计与优化技巧 1.规范背景与目的 MySQL数据库与 Oracle. SQL Server 等数据库相比,有其内核上的优势与劣势.我们在使用MySQL数据库的时候需 ...

  7. SQL SERVER全面优化-------索引有多重要?

    想了好久索引的重要性应该怎么写?讲原理结构?我估计大部分人不愿意看,也不愿意花那么多时间仔细研究.光写应用?感觉不明白原理一样不会用.举例说明?情况太多也写不全....到底该怎么写呢? 随便写吧,想到 ...

  8. 《高性能SQL调优精要与案例解析》一书谈主流关系库SQL调优(SQL TUNING或SQL优化)核心机制之——索引(index)

    继<高性能SQL调优精要与案例解析>一书谈SQL调优(SQL TUNING或SQL优化),我们今天就谈谈各主流关系库中,占据SQL调优技术和工作半壁江山的.最重要的核心机制之一——索引(i ...

  9. SQL优化之索引分析

    索引的重要性 数据库性能优化中索引绝对是一个重量级的因素,可以说,索引使用不当,其它优化措施将毫无意义. 聚簇索引(Clustered Index)和非聚簇索引 (Non- Clustered Ind ...

随机推荐

  1. EZ 2018 04 21 NOIP2018 模拟赛(十) -LoliconAutomaton的退役赛

    难得的一次Unrated,避免了重回1500的尴尬 其实题目都还可以,但只不过所有人T1都炸了,可能是数据的锅(假的) 而且我因为T1SB的把T2弃了,没想到是千年水题 T3莫名爆炸,然后TM的40分 ...

  2. makefile怎么写?

    参考:https://blog.csdn.net/haoel/article/details/2886    https://blog.csdn.net/haoel/article/details/2 ...

  3. 洛咕 P2336 [SCOI2012]喵星球上的点名

    洛咕 P2336 [SCOI2012]喵星球上的点名 先求出SA和height,一个点名串对应的就是一段区间,还有很多个点,就转化成了 有很多个区间,很多个点集,对每个区间计算和多少个点集有交,对每个 ...

  4. Java Web应用中支持跨域请求

    转载:https://blog.csdn.net/lmy86263/article/details/51724221 由于工程合作开发的需要,后台的应用要能支持跨域访问,但是在这个跨域访问“时好时坏” ...

  5. jqGrid 列内容超过一定长度省略表示

    jqgrid初始化方法中的,对应列添加formatter方法 colNames : [ "描述" ], colModel : [ { name : 'description', i ...

  6. (转载)利用SIFT和RANSAC算法(openCV框架)实现物体的检测与定位,并求出变换矩阵(findFundamentalMat和findHomography的比较) 置顶

    原文链接:https://blog.csdn.net/qq_25352981/article/details/46914837#commentsedit 本文目标是通过使用SIFT和RANSAC算法, ...

  7. Json To CSharp

    This is a tools for generate json reader classes. In some case, when we get a json data, we hope to ...

  8. X32位 天堂2 二章/三章 服务端协议号修改方法

    [本方法适合于2004-2006年之间天堂2由初章服务端修改至二章.三章端时协议号匹配问题]服务端版本位32位初章服务端 目前大部分SF用的协议号情况: 服务端是419 客户端是 417 419 42 ...

  9. 1.AKATSUKI

    ## 1.AKATSUKI - “晓”,日本漫画<火影忍者>及其衍生作品中的一个秘密组织. - 成立之初是为了给自己的国家带来和平. ## 2.团队成员 - 邱东宝 - 211606325 ...

  10. 作业六:分析Linux内核创建一个新进程的过程

    分析Linux内核创建一个新进程的过程 进程描述符PCB----task_struct数据结构 操作系统:1.进程管理 2.内存管理 3 文件系统 一.新进程如何创建和修改task_struct数据结 ...