关系型数据库发展至今,在寻求自身突破发展的过程中,内存与分布式数据库是当下最流行的主题,这与性能及扩展性在大数据时代的需求交相辉映.SQL Server作为传统的数据库也在最新发布版本SQL Server 2014中提供了新利器 SQL Server In-Memory OLTP,使得其在OLTP系统中的性能有了几十倍甚至上百倍的性能提升.

谈完并行执行的原理,咱们再来谈谈优化,到底并行执行能给我们带来哪些好处,我们又应该注意什么呢,下面展开.

在成熟领先的企业级数据库系统中,并行查询可以说是一大利器,在某些场景下他可以显著的提升查询的相应时间,提升用户体验.如SQL Server, Oracle等, Mysql目前还未实现,而PostgreSQL在2015实现了并行扫描,相信他们也在朝着更健壮的企业级数据库迈进.

现在很多用户被数据库的慢的问题所困扰，又苦于花钱请一个专业的DBA成本太高。软件维护人员对数据库的了解又不是那么深入，所以导致问题迟迟不能解决，或只能暂时解决不能得到根治。开发人员解决数据问题基本又是搜遍百度各种方法尝试个遍，可能错过诊断问题的最佳时机，又可能尝试一堆方法最后无奈放弃。

好的语句就像这炫酷的跑车，跑的又快又帅气！今天这里介绍一些技巧让你可以改装一下自己的车！网上确实有好多好多好多好多SQL 语句优化的文章，什么 优化大全 ，100个优化注意 ，确实整理了好多好多。

在SQL Server中，每一个查询都会找到最短路径实现自己的目标。如果数据库只接受一个连接一次只执行一个查询。那么查询当然是要多快好省的完成工作。但对于大多数数据库来说是需要同时处理多个查询的。

当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的完整性和一致性。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。

Sql server聚合函数在实际工作中应对各种需求使用的还是很广泛的，对于聚合函数的优化自然也就成为了一个重点，一个程序优化的好不好直接决定了这个程序的声明周期。

一切都是为了性能，一切都是为了业务

我们都听说过RAID，也经常作为SQL DBA、开发人员或构架师在工作中讨论RAID。但是，其实我们很多人都对RAID的原理，等级，以及RAID是如何影响SQL Server性能并不甚了解。本篇文章就是为了补上这一课。

在SQL Server中，数据是按页进行存放的。而为表加上聚集索引后，SQL Server对于数据的查找就是按照聚集索引的列作为关键字进行了。因此对于聚集索引的选择对性能的影响就变得十分重要了。本文从旨在从性能的角度来谈聚集索引的选择，但这仅仅是从性能方面考虑。对于有特殊业务要求的表，则需要按实际情况进行选择。

当查询优化器(Query Optimizer)将T-SQL语句解析后并从执行计划中选择最低消耗的执行计划后，具体的执行就会交由执行引擎(Execution Engine)来进行执行。本文旨在分类讲述执行计划中每一种操作的相关信息。

SQL Server查询分析器是基于开销的。通常来讲，查询分析器会根据谓词来确定该如何选择高效的查询路线,比如该选择哪个索引。而每次查询分析器寻找路径时，并不会每一次都去统计索引中包含的行数，值的范围等，而是根据一定条件创建和更新这些信息后保存到数据库中，这也就是所谓的统计信息。

在SQL Server中，我们所常见的表与表之间的Inner Join,Outer Join都会被执行引擎根据所选的列，数据上是否有索引，所选数据的选择性转化为Loop Join,Merge Join,Hash Join这三种物理连接中的一种。理解这三种物理连接是理解在表连接时解决性能问题的基础，下面我来对这三种连接的原理，适用场景进行描述。

在上篇文章中我们谈到了查询优化器和执行计划缓存的关系，以及其二者之间的冲突。本篇文章中，我们会主要阐述执行计划缓存常见的问题以及一些解决办法。

当我们写的SQL语句传到SQL Server的时候，查询分析器会将语句依次进行解析（Parse）、绑定（Bind）、查询优化（Optimization，有时候也被称为简化）、执行（Execution）。除去执行步骤外，前三个步骤之后就生成了执行计划，也就是SQL Server按照该计划获取物理数据方式，最后执行步骤按照执行计划执行查询从而获得结果。

Microsoft SQL Server在大多数情况下都能够创建非常高效的执行计划。但是在某些特定的查询类型会给查询优化器带来麻烦。本篇文章阐述了其中4种情况，这些情况通常包含了需要SQL Server传递多个数据集、产生没有统计信息的中间结果集，抑或是中间结果集的统计信息无法被正确计算。

本文讲述了一个强制SQL Server执行计划使用并行提升在复杂查询语句下的性能的案例

最近帮助客户调优的过程中，发现客户的TempDB存在非常大的压力，经过排查是发现某些语句对TempDB的巨量使用所导致。针对类似问题，本文介绍了通过SQL语句观察某个查询对TempDB造成了多少读写。

对于T-SQL领域来说，在网上经常可以看到所谓的优化守则，其中一条则是“对出现在where子句中的字段加索引”，然而SQL语句Where 1=1 and在SQL Server中并不影响性能。本文按照查询分析器的规则去考虑并解释了为什么Where 1=1 and在SQL Server中不影响性能。