MVP黄钊吉（發糞塗牆）

前言：        本文为本系列最后一篇，介绍键值查找的相关知识。        键值查找是具有聚集索引的表上的一个书签查找，键值查找用于SQLServer查询一些非键值列的数据。使用非聚集索引的查询不会有键值查找，但是所有键值查找会伴随非聚集索引出现。这里特别提醒的是键值查找总是伴有嵌套循环关联。 准备工作： 下面将创建一个表，通过执行计划看看键值查找的不同效果。为了产

为什么要写这个内容？ 随着工作经历的积累，越来越感觉到，大量的关系型数据库的性能问题，其根源在于统计信息。这里说的是根源，其实很多时候大家觉得的那些什么索引失效等都只是表象。当然，不能一概而论，还有很多问题如配置问题、设计问题等等，甚至电源也会影响性能。 之所以得出这个结论，因为在常规的开发和部署过程中，一般企业级系统已经大量使用较为高级的磁盘阵列甚至企业级SSD，IO方面的问题已经很少，而且关系

本文属于《理解性能的奥秘——应用程序中慢，SSMS中快》系列接上文：理解性能的奥秘——应用程序中慢，SSMS中快（5）——案例：如何应对参数嗅探

在工作中发现有不少类似的现象，有幸看到国外大牛写的一篇文章，由于已经完善得不能再添油加醋，所以决定直接翻译，原文出处：http://www.sommarskog.se/query-plan-mysteries.html#defaultsettings  本人水平有限，如果读者觉得自己英语过得去，建议阅读原文。在翻译过程中，不排除会对某些部分进行修改，但不会影响最终效果。 由于内容较多，所以把文章拆

本文属于《理解性能的奥秘——应用程序中慢，SSMS中快》系列 接上文：理解性能的奥秘——应用程序中慢，SSMS中快（1）——简介 本文介绍SQL Server如何编译存储过程并使用计划缓存。如果你的应用程序完全没有用到存储过程，而是直接使用SQL语句提交请求，那么本文大部分内容也是有效的。但是关于动态SQL的编译会在后面章节介绍，这里重点关注让人头痛的存储过程问题。什么是存储过程？ 虽然这个问题有...

本文属于《理解性能的奥秘——应用程序中慢，SSMS中快》系列 接上文：理解性能的奥秘——应用程序中慢，SSMS中快（2）——SQL Server如何编译存储过程 在我们开始深入研究如何处理参数嗅探相关的性能问题之前，由于这个课题过于广泛，所以首先先介绍一些跟参数嗅探没有直接关系的内容，但是又会导致语句在SSMS和应用程序中存在性能差异的情况。替换变量和参数： 前面已经接触过，但是在这里对其进行扩...

本文属于《理解性能的奥秘——应用程序中慢，SSMS中快》系列 接上文：理解性能的奥秘——应用程序中慢，SSMS中快（4）——收集解决参数嗅探问题的信息

本文属于《理解性能的奥秘——应用程序中慢，SSMS中快》系列 接上文：理解性能的奥秘——应用程序中慢，SSMS中快（3）——不总是参数嗅探的错

    原文出处：What caused that plan to go horribly wrong – should you update statistics?    由于本人确实遇到过这类问题，但是基于水平和经历，不打算重复造轮子，所以把大牛的文章翻译一下以供大家参考。以下是译文：过去几年里，我（作者）遇到这类情景：    有一个存储过程在大部分时间里面都运行得很好，但是突然就不行了。其性...

本系列属于 SQL Server性能优化案例分享 专题    在执行计划中出现的Spool操作符，往往都具有明显的性能问题，也意味着数据库的设计、编码等可能存在问题，所以本文专门介绍一下这个操作符。   Spool介绍    Spool是内存或者磁盘上的缓存（cache）或临时表。SQL Server用这个结构来提升在执行过程中需要多次执行的复杂的子表达式的性能。注意几个次：一次运行中多次执行、复...

我想在大地上画满窗子，让所有习惯黑暗的眼睛习惯光明——顾城《我是一个任性的孩子》 这一节主要介绍一些理论层面的东西，主要针对SQL Server，为后面的做铺垫，如果从实操层面考虑可以跳过，但是我强烈建议还是要找时间看一下这节。本节的内容如下：SQL Server统计信息列级统计信息统计信息与执行计划统计信息与内存分配开销预估模型SQL Server统计信息 说到统计信息，就一定要提到查询优化器，

接上文：T-SQL动态查询（3）——静态SQL 前言： 前面说了很多关于动态查询的内容，本文将介绍使用动态SQL解决动态查询的一些方法。 为什么使用动态SQL： 在很多项目中，动态SQL被广泛使用甚至滥用，很多时候，动态SQL又确实是解决很多需求的首选方法。但是如果不合理地使用，会导致性能问题及无法维护。动态SQL尤其自己的优缺点，是否使用需要进行评估分析：动态SQL优点：动态SQL提供了强大的扩

前言： 很多很多地方对于语句的优化，一般比较靠谱的回复即使——把执行计划发出来看看。当然那些只看语句就说如何如何改代码，我一直都是拒绝的，因为这种算是纯蒙。根据本人经验，大量的性能问题单纯从语句来看很难发现瓶颈，同一个语句，由于环境的不同，差距非常大，所以比较合适的还是分析执行计划。 那么对于执行计划，一般使用图形化执行计划就差不多了，但是用过的人也有一些疑惑，里面的图标（称为操作符）并不非常

前言：      在绝大部分情况下，特别是从一个大表中返回少量数据时，表扫描或者索引扫描并不是一种高效的方式。这些必须找出来并解决它们从而提高性能，因为扫描将遍历每一行，查找符合条件的数据，然后返回结果。这种处理是相当耗时耗资源的。在性能优化过程中，一般集中于：1、  CPU2、  Network3、  磁盘IO而扫描操作会增加这三种资源的开销。 准备工作：

前言：本系列文章包括：1、 理解Hash、Merge、Nested Loop关联策略。2、 在执行计划中发现并解决表/索引扫描。3、 介绍并在执行计划中发现键查找并解决它们。 对于性能优化，需要集中处理以下的问题：1、 为你的环境创建性能基线。2、 监控现在的性能并发现瓶颈。3、 解决瓶颈以便得到更好的性能。 一个预估执行计划是描述查询将会如何执行的一个

前言：        在第一次执行查询或者存储过程时，会创建执行计划并存储在SQLServer的过程缓存内存中。在很多时候，我们会执行一些简单的程序，仅仅执行一次，而为这些查询创建存储过程是非常浪费内存资源的。由于内存不足，可能会导致你的缓存溢出，从而影响性能。在2005之前，这是一个大问题，为了纠正这个问题。微软在SQLServer 2008中引入了对即时查询负载的优化功能。这个功能在2012也

转载请注明出处        由于工作及学习需要，最近看了一下《Dissecting SQL Server Execution Plans》，这是少有的专门描述执行计划的优秀书籍，为了快速查找并供入门同行学习，粗略翻译了本书，并进行连载，由于专业及英语水平严重不足，所以建议有兴趣有能力的读者看原书，同时期待各位指出翻译不足。下载地址：点击打开链接        本文是一个总入口，方便阅读，共8章，

前言： 在前面一文中，已经提到了三类常见的索引问题，那么问题来了，当系统出现这些问题时，该如何应对？ 简单而言，需要分析现有系统的行为，然后针对性地对索引进行处理：对于索引不足的情况：检查缺少索引的情况，也需要检查现有索引定义是否有问题。对于索引过多的情况：分析每一个索引的使用情况，判断是否有存在的必要或者可合并、可修改的可能。对于索引不合理的情况：也要分析每个索引的定义，及其使用情况，确定索引是

接上文：T-SQL动态查询（2）——关键字查询   本文讲述关于静态SQL的一些知识和基础技巧。简介： 什么是静态SQL？静态SQL是和动态SQL相对而言的，其实我们没必要过于纠结精确定义，只要大概知道什么算静态SQL即可。当一个语句特别是存储过程，语句不需要动态生成或拼接，除了参数之外我们都知道语句的最终形态时，就可以认为这是静态SQL，简单来说，我们大部分的处理动态查询条件的语句都属于静态SQ

接上文：T-SQL动态查询（1）——简介 前言： 在开发功能的过程中，我们常常会遇到类似以下情景：应用程序有一个查询功能，允许用户在很多查询条件中选择所需条件。这个也是本系列的关注点。 但是有时候你也许会发现，有些条件或多或少是互相排斥的。比如用户通过下面其中一个条件查找信息：1．  客户名2．  客户ID3．  客户身份标识号（如国内身份证、美国社保号等）。 并且这三列上都有适当的索引。本系列主

起因： 由于最近工作需要及过去一直的疑问，所以决定着手研究一下动态SQL。由于离开一线开发有点年头了，很多技巧性的东西没有过多研究，作为DBA和《SQL Server性能优化与管理的艺术》一书的独立作者，更多的是关注在满足功能要求前提下的性能问题。但是我认为本文不仅对DBA有用，对数据库开发人员甚至设计师、架构师等都有一定的参考价值。 前言： 读者是否遇到过类似功能：一个应用程序（不管是B/S还是

接上文：SQL Server 执行计划操作符详解（2）——串联(Concatenation )

本系列属于 SQL Server性能优化案例分享 专题    最近遇到服务器CPU持续居高问题，通过计数器的检查，初步断定存在语句性能问题，然后有针对性地抓取问题语句（来龙去脉将会在另外一篇文章解释，本文关注Hash Warning），其执行计划如下：    因为这是生产环境，所以下面例子把表名替换成A/B/C/D等表。代码很简单，大概样子如下：SELECT bo.Scode ,d.PCode ,...