摘要：
我们抛开参数嗅探的话题，回到了本系列的最初关注点中：为什么语句在应用程序中慢，但是在SSMS中快？到目前为止，都是在说存储过程的情况。而存储过程的问题通常是因为SET ARITHABORT的不同设置项的原因。如果你的应用不使用存储过程，而是通过中间层提交客户端的查询，那么也有几个原因可能让你的查询因 阅读全文
摘要：
首先我们需要明白，参数嗅探本身不是问题，而是一个特性，避免SQL Server做出盲目的假设，从而产生次优查询计划。但是有些情况下，参数嗅探却会带来负面影响。通常有下面三种典型的情况： 我们往往很难预先知道实际情况，所以才需要做仔细的分析。上一节已经讨论了需要获取一些什么信息，但是还有一个极其有帮助 阅读全文
摘要：
前面已经提到过关于存储过程在SSMS中运行很快，但在应用程序中运行很慢的可能原因：因为ARITHABORT的不同选项会导致不同的缓存词目，另外由于SQL Server使用了参数嗅探导致获得了不同的执行计划。 虽然已经说明了这个现象的原因，但是还没解释：如何定位和解决这个问题？到目前为止，大家都知道了 阅读全文
摘要：
在我们开始深入研究如何处理参数嗅探相关的性能问题之前，由于这个课题过于广泛，所以首先先介绍一些跟参数嗅探没有直接关系的内容，但是又会导致语句在SSMS和应用程序中存在性能差异的情况。 替换变量和参数： 前面已经接触过，但是在这里对其进行扩展。有时会看到论坛上有人说，某个存储过程很慢，但是把相同的语句 阅读全文
摘要：
本文介绍SQL Server如何编译存储过程并使用计划缓存。如果你的应用程序完全没有用到存储过程，而是直接使用SQL语句提交请求，那么本文大部分内容也是有效的。但是关于动态SQL的编译会在后面章节介绍，这里重点关注让人头痛的存储过程问题。 什么是存储过程？ 虽然这个问题有点愚蠢，但是实际的问题是：什 阅读全文
摘要：
前言： 本文为本系列最后一篇，介绍键值查找的相关知识。 键值查找是具有聚集索引的表上的一个书签查找，键值查找用于SQLServer查询一些非键值列的数据。使用非聚集索引的查询不会有键值查找，但是所有键值查找会伴随非聚集索引出现。这里特别提醒的是键值查找总是伴有嵌套循环关联。 准备工作： 下面将创建一 阅读全文
摘要：
本文属于《理解性能的奥秘——应用程序中慢，SSMS中快》系列 在工作中发现有不少类似的现象，有幸看到国外大牛写的一篇文章，由于已经完善得不能再添油加醋，所以决定直接翻译，原文出处：http://www.sommarskog.se/query-plan-mysteries.html#defaultse 阅读全文
摘要：
前言： 在绝大部分情况下，特别是从一个大表中返回少量数据时，表扫描或者索引扫描并不是一种高效的方式。这些必须找出来并解决它们从而提高性能，因为扫描将遍历每一行，查找符合条件的数据，然后返回结果。这种处理是相当耗时耗资源的。在性能优化过程中，一般集中于： 1、 CPU 2、 Network 3、 磁盘 阅读全文
摘要：
前言： 本系列文章包括： 1、 理解Hash、Merge、Nested Loop关联策略。 2、 在执行计划中发现并解决表/索引扫描。 3、 介绍并在执行计划中发现键查找并解决它们。 对于性能优化，需要集中处理以下的问题： 1、 为你的环境创建性能基线。 2、 监控现在的性能并发现瓶颈。 3、 解决 阅读全文
摘要：
前言： 前面两篇文章介绍了关于串联（Concatenation）和断言（Assert）操作符，本文介绍第三个常见的操作符计算标量(Compute Scalar)。这个操作符的名字比较直观——进行一个标量计算并返回计算值。官方说明：Compute Scalar 运算符通过对表达式求值来生成计算标量值。 阅读全文
摘要：
前言： 根据计划，本文开始讲述另外一个操作符串联（Concatenation），读者可以根据这个词（中英文均可）先幻想一下是干嘛的。其实还是挺直观，就是把东西连起来，那么下面我们来看看到底连什么？怎么连？什么时候连？ 简介： 串联操作符既是物理操作符，也是逻辑操作符，在中文版SQL Server的图 阅读全文
摘要：
前言： 很多很多地方对于语句的优化，一般比较靠谱的回复即使——把执行计划发出来看看。当然那些只看语句就说如何如何改代码，我一直都是拒绝的，因为这种算是纯蒙。根据本人经验，大量的性能问题单纯从语句来看很难发现瓶颈，同一个语句，由于环境的不同，差距非常大，所以比较合适的还是分析执行计划。 那么对于执行计 阅读全文