wangd1121的专栏

引言 描述揭示执行计划成本规则所必要的工具和测试脚本。查询成本和性能要达到我们的预期对表和索引有一些高水平的理解也是必要的。一些主题在其他地方有详细介绍，所以这里只做简短的讨论。SQLServer工具包括查询分析器和事件探查器。SET选项包括SET STATISTICS IO和SET SHOWPLAN_ALL。为揭示查询执行计划成本结构特别创建测试表。为测试表生成数据的脚本。  表组织和索引结构

循环、哈希与合并连接比较在分别讨论了循环、哈希与合并连接的执行计划成本规则之后，现在将3个连接类型放到适合各自条件的环境下一起比较。下面的图2-27显示了循环、哈希与合并连接在1P/2P系统上的启动成本。外部源和内部源启动成本描述了索引搜索的基本成本包括每行成本0.0000011。连接成本也除去第一行，这样似乎仅有个案是少量变化的。4P系统的启动成本仅在索引搜索基本成本（0.003283025）上

表扫描当没有合适的索引时就发生表扫描操作。这可能意味着没有索引存在或者预期有很多行且比扫描整个表开销更少。如果表是一个堆表，执行计划显示表扫描操作；如果表有聚集索引或者所有需要的值都在一个非聚集索引里如图2-6显示，那么执行计划显示一个索引扫描操作。  图2-6.表扫描的执行计划和聚集索引扫描操作 图2-7和2-8显示表扫描和索引扫描操作的成本细节。索引扫描和表扫描有相同的成本结构。 图2-7.

聚合查询里使用聚合函数（MIN、MAX、COUNT、AVG或SUM）时发生流聚合（Stream Aggregate）和标量计算（Compute Scalar）如下所示。 SELECT COUNT(*), AVG(Value) FROM M2C_10 MIN和MAX函数要求流聚合操作。在执行计划里其他的函数要求流聚合后跟一个或多个标量计算操作。 图2-12.流聚合和标量计算的执行计划 图2-13.

哈希连接 哈希和合并连接都是分开处理内部源和外部源的。连接条件不能用作搜索参数。当没有为表或存在的不合适的索引明确指定搜索参数时，就要对那个表进行扫描。有可能哈希和合并连接有书签查找操作，但也未必，除非强制指定连接类型。下面的查询明确声明一个哈希连接。连接操作里的每一个表指定了搜索条件，并且两个表都有聚集索引或覆盖索引。SELECT m.ID, n.ValueFROM M2C m INNER HA

Insert、Update和DeleteSQLServer里3个写操作是INSERT、UPDATE和DELETE（IUD）。如果加上约束、触发器和外键，写操作可以变得更复杂。这里仅关心基本的写操作。对于3个操作中的每一个，对于堆表和有聚集索引的表来说都有不同的图标，如图2-31、2-32和2-33所示。  图2-31.堆表和有聚集索引的表的Insert执行计划 图2-32.堆表和有聚集索引的

如果将 SQL Server 配置成仅包含几个千兆字节 (GB) 的数据，且不承担繁重的读或写活动，便没有太大的必要关注磁盘 I/O 主题，以及在硬盘之间平衡 SQL Server I/O 活动以获取最佳性能。但是要建立包含成百上千 GB 字节的数据且/或承担繁重的读和/或写活动的大型 SQL Server 数据库，就有必要在多个硬盘之间平衡负荷，以配置最佳的 SQL Server 磁盘 I/O

Performance tuning is not easy and there aren’t any silver bullets, but you can go a surprisingly long way with a few basic guidelines. In theory, performance tuning is done by a DBA. But in practic

普通的SQL Server应用程序要求支持一个或几个长字符串搜索。（本文中，我们称超过20个字符的字符串为长字符串。）假如前端应用程序希望允许用户提供两个字符串；你启动一个执行这两个字符串搜索任务的存储程序，然后应用两个相关列目录对搜索进行优化。在小型的表格中，你可能注意不到产生的效果。但是，如果表格包含5 000万行，它就会影响存储程序与搜索性能。　　应用称为hash关键字（引用单独一个ha