SQL Server2005物理设计 整理
一个数据库系统的性能依赖于组成这些系统的数据库中物理设计结构的有效配置。这些物理设计结构包括索引、聚集索引、索引视图和分区等，其目的在于提高数据库的性能和可管理性。SQL Server 2005提供了一套综合的工具，用于优化物理数据库的设计，其中数据库引擎优化顾问，是分析一个或多个数据库上工作负荷（对要做出化的数据库招待的一组T-SQL语名句）的性能效果的工具。
Ø 文件和文件组
SQL Server 2005 将数据库映射为一组操作系统文件。数据和日志信息绝不混合在同一个文件中，而且一个文件只由一个数据库使用。文件组是文件的命名集合，用于简化数据存放和管理任务（例如，备份和还原操作）。有关详细信息，请参阅物理数据库文件和文件组。
文件和文件组填充策略
文件组对组内的所有文件都使用按比例填充策略。当数据写入文件组时，SQL Server 数据库引擎按文件中的可用空间比例将数据写入文件组中的每个文件，而不是将所有数据都写入第一个文件直至其变满为止。然后再写入下一个文件。例如，如果文件 f1 有 100 MB 可用空间，文件 f2 有 200 MB 可用空间，则从文件 f1 中分配一个区，从文件 f2 中分配两个区，依此类推。这样，两个文件几乎同时填满，并且可获得简单的条带化。
假定将数据库设置为自动增长，则当文件组中的所有文件填满后，数据库引擎便会采用循环方式一次自动扩展一个文件以容纳更多数据。例如，某个文件组由三个文件组成，它们都设置为自动增长。当文件组中所有文件的空间都已用完时，只扩展第一个文件。当第一个文件已满，无法再向文件组中写入更多数据时，将扩展第二个文件。当第二个文件已满，无法再向文件组中写入更多数据时，将扩展第三个文件。当第三个文件已满，无法再向文件组中写入更多数据时，将再次扩展第一个文件，依此类推。
改善数据库性能
使用文件和文件组可以改善数据库的性能，因为这样允许跨多个磁盘、多个磁盘控制器或 RAID（独立磁盘冗余阵列）系统创建数据库。例如，如果计算机上有四个磁盘，那么可以创建一个由三个数据文件和一个日志文件组成的数据库，每个磁盘上放置一个文件。在对数据进行访问时，四个读/写磁头可以同时并行地访问数据。这样可以加快数据库操作的速度。有关硬件解决方案的详细信息，请参阅数据库性能。
另外，文件和文件组还允许数据布局，因为可以在特定的文件组中创建表。这样可以改善性能，因为可以将特定表的所有 I/O 都定向到一个特定的磁盘。例如，可以将最常用的表放在一个文件组的一个文件中，该文件组位于一个磁盘上；而将数据库中其他不常访问的表放在另一个文件组的其他文件中，该文件组位于第二个磁盘上。
实现备份和还原策略
在 SQL Server 2005 中，可以通过称为段落还原的进程分阶段还原由多个文件组组成的数据库。段落还原适用于所有恢复模式，但在完整恢复模式和大容量日志恢复模式下比在简单恢复模式下更灵活。段落还原方案包括还原的全部三个阶段：数据复制、重做或前滚以及撤消或后滚。有关详细信息，请参阅执行段落还原。
当使用多个文件组时，可以分别备份和还原数据库中的文件。在简单恢复模式下，只能对只读文件进行文件备份。使用文件备份使您能够只还原损坏的文件，而不用还原数据库的其余部分，从而加快了恢复速度。例如，如果一个数据库由几个分别位于不同的物理磁盘上的文件组成，当其中一个磁盘发生故障时，只需还原发生故障的磁盘上的文件。有关详细信息，请参阅BACKUP (Transact-SQL)。
文件和文件组的设计规则
下列规则适用于文件和文件组：
ü 一个文件或文件组不能由多个数据库使用。例如，任何其他数据库都不能使用包含 sales 数据库中的数据和对象的文件 sales.mdf 和 sales.ndf。
ü 一个文件只能是一个文件组的成员。
ü 事务日志文件不能属于任何文件组。
使用文件和文件组时的一些一般建议：
ü 大多数数据库在只有单个数据文件和单个事务日志文件的情况下性能良好。
ü 如果使用多个文件，请为附加文件创建第二个文件组，并将其设置为默认文件组。这样，主文件将只包含系统表和对象。
ü 若要使性能最大化，请在尽可能多的不同的可用本地物理磁盘上创建文件或文件组。将争夺空间最激烈的对象置于不同的文件组中。
ü 使用文件组将对象放置在特定的物理磁盘上。
ü 将在同一联接查询中使用的不同表置于不同的文件组中。由于采用并行磁盘 I/O 对联接数据进行搜索，所以性能将得以改善。
ü 将最常访问的表和属于这些表的非聚集索引置于不同的文件组中。如果文件位于不同的物理磁盘上，由于采用并行 I/O，所以性能将得以改善。
ü 请勿将事务日志文件置于其中已有其他文件和文件组的物理磁盘上。
Ø tempdb 数据库
tempdb 系统数据库是一个全局资源，可供连接到 SQL Server 实例的所有用户使用，并可用于保存下列各项：
ü 显式创建的临时用户对象，例如全局或局部临时表、临时存储过程、表变量或游标。
ü SQL Server 2005 数据库引擎创建的内部对象，例如，用于存储假脱机或排序的中间结果的工作表。
ü 由使用已提交读（使用行版本控制隔离或快照隔离事务）的数据库中数据修改事务生成的行版本。
ü 由数据修改事务为实现联机索引操作、多个活动的结果集 (MARS) 以及 AFTER 触发器等功能而生成的行版本。
tempdb 中的操作是最小日志记录操作。这将使事务产生回滚。每次启动 SQL Server 时都会重新创建 tempdb，从而在系统启动时总是保持一个干净的数据库副本。在断开联接时会自动删除临时表和存储过程，并且在系统关闭后没有活动连接。因此 tempdb 中不会有什么内容从一个 SQL Server 会话保存到另一个会话。不允许对 tempdb 进行备份和还原操作。
tempdb 性能
² tempdb 大小和位置建议
tempdb 数据库的大小和物理位置可能会影响系统的性能。例如，如果为 tempdb 定义的大小过小，则每次重新启动 SQL Server 实例时，都可能会占用部分系统处理负荷，以使 tempdb 自动增长到支持工作负荷所需的大小。您可以通过增加 tempdb 数据和日志文件的大小来避免此开销。有关确定 tempdb 所需的适当磁盘空间量的信息，请参阅 tempdb 容量规划。
若要获得最佳的 tempdb 性能，我们建议在生产环境中对 tempdb 进行如下配置：
² 将 tempdb 的恢复模式设置为 SIMPLE。此模式自动回收日志空间以保持较小的空间要求。
² 有关详细信息，请参阅 ALTER DATABASE (Transact-SQL) 或如何查看或更改数据库恢复模式 (SQL Server Management Studio)。
² 使 tempdb 文件的大小可以根据需要自动增大。这可以使文件的大小增大到磁盘变满为止。
注意：
如果生产环境不允许自动增长操作过程中可能出现的应用程序超时，则应为预期的工作负荷预分配空间。
² 将文件增量设置为合理的大小以避免 tempdb 数据库文件的增量过小。如果文件的增量与写入 tempdb 的数据量相比过小，则 tempdb 可能需要不断扩大。这将影响性能。建议为 tempdb 文件设置 FILEGROWTH 增量时遵循以下通用原则
| tempdb 文件大小 |
FILEGROWTH 增量 |
| 0 至 100 MB |
10 MB |
| 100 至 200 MB |
20 MB |
| 200 MB 或更多 |
10%* |
*您可能必须基于 tempdb 文件所在的 I/O 子系统的速度调整此百分比。为了避免潜在的闩锁超时，我们建议将自动增长操作限制在大约两分钟之内。例如，如果 I/O 子系统以每秒 50 MB 的速度初始化文件，则无论 tempdb 文件的大小如何，FILEGROWTH 增量都应设置为最大值 6 GB。如果可能，请使用实例数据库文件初始化来提高自动增长操作的性能。
² 通过将文件大小设置为足够容纳环境中典型工作负荷的值来预分配所有 tempdb 文件的空间。这可以避免 tempdb 因扩展得过于频繁而影响性能。tempdb 数据库应设置为自动增长，但是在出现意外情况时此设置将用于增加磁盘空间。
² 根据需要创建足够多的文件以使磁盘宽度最大化。使用多个文件可以减少 tempdb 存储争用并获得更大的可伸缩性。但是，请勿创建过多的文件，因为此操作可能降低性能并增加管理开销。作为通用原则，为服务器中的每一个 CPU 创建一个数据文件（用于解释任何关联掩码设置），然后根据需要上下调整文件的数量。请注意，双核心 CPU 将被视为两个 CPU。
² 使每个数据文件的大小相同，这样可以优化比例填充的性能。
² 将 tempdb 数据库放置在快速 I/O 子系统中。如果有许多直接连接的磁盘，则请使用磁盘条带化。
² 将 tempdb 数据库放置在用户数据库使用的磁盘以外的磁盘中。
修改 tempdb 大小和增长参数
您可以使用下列方法之一修改 tempdb 数据或日志文件的大小和文件增长参数。
ü ALTER DATABASE 语句
ü SQL Server Management Studio
每次创建 tempdb 时都要使用文件大小和文件增长参数的值。例如，如果您将 tempdb 数据文件的大小增加到 20 MB 并将文件增量增加到 15%，则新的值将立即生效。如果后续事务活动使 tempdb 的大小增大，则每次重新启动 SQL Server 实例时，数据文件的大小都将返回到 20 MB。
Ø 索引
索引类型
下表列出了 SQL Server 2005 中可用的索引类型，并提供了指向其他信息的链接。
| 索引类型 |
说明 |
其他信息 |
| 聚集 |
聚集索引基于聚集索引键按顺序排序和存储表或视图中的数据行。聚集索引按 B 树索引结构实现，B 树索引结构支持基于聚集索引键值对行进行快速检索。 |
|
| 非聚集 |
既可以使用聚集索引来为表或视图定义非聚集索引，也可以根据堆来定义非聚集索引。非聚集索引中的每个索引行都包含非聚集键值和行定位符。此定位符指向聚集索引或堆中包含该键值的数据行。索引中的行按索引键值的顺序存储，但是不保证数据行按任何特定顺序存储，除非对表创建聚集索引。 |
|
| 唯一 |
唯一索引确保索引键不包含重复的值，因此，表或视图中的每一行在某种程度上是唯一的。 聚集索引和非聚集索引都可以是唯一索引。 |
|
| 包含性列索引 |
一种非聚集索引，它扩展后不仅包含键列，还包含非键列。 |
|
| 索引视图 |
视图的索引将具体化（执行）视图，并将结果集永久存储在唯一的聚集索引中，而且其存储方法与带聚集索引的表的存储方法相同。创建聚集索引后，可以为视图添加非聚集索引。 |
|
| 全文 |
一种特殊类型的基于标记的功能性索引，由 Microsoft SQL Server 全文引擎 (MSFTESQL) 服务创建和维护。用于帮助在字符串数据中搜索复杂的词。 |
|
| XML |
xml 数据类型列中 XML 二进制大型对象 (BLOB) 的已拆分持久表示形式。 |
|
优化
² 重新组织和重新生成索引
无论何时对基础数据执行插入、更新或删除操作，SQL Server 2005 数据库引擎都会自动维护索引。随着时间的推移，这些修改可能会导致索引中的信息分散在数据库中（含有碎片）。当索引包含的页中的逻辑排序（基于键值）与数据文件中的物理排序不匹配时，就存在碎片。碎片非常多的索引可能会降低查询性能，导致应用程序响应缓慢。
² 填充因子
提供填充因子选项是为了优化索引数据存储和性能。当创建或重新生成索引时，填充因子值可确定每个叶级页上要填充数据的空间百分比，以便保留一定百分比的可用空间供以后扩展索引。例如，指定填充因子的值为 80 表示每个叶级页上将有 20% 的空间保留为空，以便随着在基础表中添加数据而为扩展索引提供空间。
填充因子值是 1 到 100 之间的一个百分比。在大多数情况下，服务器范围的默认值 0 是最佳选项。如果将填充因子设置为 0，则将完全填充叶级别。
页拆分和性能注意事项
如果向已满的索引页添加新行，数据库引擎将把大约一半的行移到新页中，以便为该新行腾出空间。这种重组称为页拆分。页拆分可为新记录腾出空间，但是执行页拆分可能需要花费一定的时间，此操作会消耗大量资源。此外，它还可能造成碎片，从而导致 I/O 操作增加。正确选择填充因子值可提供足够的空间以便随着向基础表中添加数据而扩展索引，从而减少页拆分可能性。
如果经常发生页拆分，可通过使用新的或现有的填充因子值来重新生成索引，从而重新分发数据。有关详细信息，请参阅重新组织和重新生成索引。
尽管采用较低的填充因子值（非 0）可减少随着索引增长而拆分页的需求，但是索引将需要更多的存储空间，并且会降低读取性能。即使对于面向许多插入和更新操作的应用程序，数据库读取次数一般也超过数据库写入次数的 5 到 10 倍。因此，指定一个不同于默认值的填充因子会降低数据库的读取性能，而降低量与填充因子设置的值成反比。例如，当填充因子的值为 50 时，数据库的读取性能会降低两倍。读取性能降低是因为索引包含较多的页，因此增加了检索数据所需的磁盘 I/O 操作。
² 配置并行索引操作
在运行 Microsoft SQL Server 2005 Enterprise Edition 的多处理器计算机上，索引语句可能像其他查询一样，使用多个处理器执行与其关联的扫描和排序操作。用于运行单个索引语句的处理器数量由配置选项 max degree of parallelism 和当前工作负荷决定。max degree of parallelism 选项可以限制在并行计划执行中使用的处理器数量。
² 索引统计信息
SQL Server 2005 允许创建有关列中值的分布情况的统计信息。查询优化器使用这些统计信息并通过估计使用索引评估查询的开销来确定最佳查询计划。
启动更新过期统计信息的查询必须等待那些统计信息更新，之后才能编译并返回结果集。这会导致不可预知的查询响应时间，并可能导致应用程序因过长超时而失败。
在 SQL Server 2005 中，数据库选项 AUTO_UPDATE_STATISTICS_ASYNC 提供了统计信息异步更新功能，如果您的应用程序出现以下情况，应考虑将 AUTO_UPDATE_STATISTICS_ASYNC 选项设置为 ON：
ü 遇到由一个或多个等待更新后的统计信息的查询导致的客户端请求超时。
ü 请求可预测查询响应时间，即使存在偶尔运行执行因过期统计信息导致的低效查询计划的查询的情况。
² 为索引操作选择恢复模式
某些完整日志记录、大规模索引操作可以生成大型数据负荷，不管是离线执行操作还是在线执行操作，这些数据负荷都可能导致快速填满事务日志。这可能影响性能。通过在索引操作的持续时间内将数据库的恢复模式设置为大容量日志模式或简单模式，可以使这些索引操作的日志记录最小。最小日志记录比完整日志记录更加有效，并可以降低索引操作填满日志空间的可能性。
Ø 视图
视图类型
在 SQL Server 2005 中，您可以创建标准视图、索引视图和分区视图。
² 标准视图
标准视图组合了一个或多个表中的数据，您可以获得使用视图的大多数好处，包括将重点放在特定数据上及简化数据操作。
² 索引视图
索引视图是被具体化了的视图，即它已经过计算并存储。可以为视图创建索引，即对视图创建一个唯一的聚集索引。索引视图可以显著提高某些类型查询的性能。索引视图尤其适于聚合许多行的查询。但它们不太适于经常更新的基本数据集。
² 分区视图
分区视图在一台或多台服务器间水平连接一组成员表中的分区数据。
ü 本地分区视图。
ü 分布式分区视图
Ø 分区
类型
将数据库分区可提高其性能并易于维护。通过将一个大表拆分成更小的单个的表，只访问小部分数据的查询可以执行得更快，因为需要扫描的数据少了。维护任务（例如，重新生成索引或备份表）也可以更快地运行。
可以通过不拆分表、而是将表放置在不同的磁盘驱动器上的方法来实现分区。例如，将表放在某个物理驱动器上并将相关的表放在不同的驱动器上可以提高查询性能，因为在运行涉及表间联接的查询时，多个磁头可以同时读取数据。可以使用 SQL Server 文件组来指定放置表的磁盘。
² 硬件分区
硬件分区将数据库设计为利用可用的硬件体系结构。以下是硬件分区示例：
可以执行多线程操作的多处理器，使得可以同时运行许多查询。换句话说，在多处理器上可以同时运行查询的各个组件，因此使单个查询的速度更快。例如，查询内引用的每个表可以同时由不同的线程扫描。
RAID（独立磁盘冗余阵列）设备使得数据在多个磁盘驱动器中条带化，使更多的读写磁头同时读取数据，因此可以更快地访问数据。在多个驱动器中条带化的表通常比存储在单个驱动器上的相同的表扫描速度要快。换句话说，将表与相关的表分开存储在不同的驱动器上可以显著提高联接那些表的查询的性能。有关详细信息，请参阅 RAID。
² 水平分区
水平分区将表分为多个表。这样，每个表包含的列数相同，但是行更少。例如，可以将一个包含十亿行的表水平分区成 12 个表，每个小表表示特定年份内一个月的数据。任何需要特定月份数据的查询只需引用相应月份的表。
具体如何将表进行水平分区取决于如何分析数据。您应将表进行分区，以便查询引用的表尽可能少。否则，查询时需要使用过多的 UNION 查询来逻辑合并表，这会影响查询性能。有关查询水平分区的表的详细信息，请参阅使用视图的情况。
常用的方法是根据时期和使用对数据进行水平分区。例如，一个表可能包含最近五年的数据，但是只定期访问本年度的数据。在这种情况下，可考虑将数据分区成五个表，每个表只包含一年的数据。
² 垂直分区
垂直分区将一个表分为多个表，每个表包含较少的列。垂直分区的两种类型是规范化和行拆分。
规范化是标准的数据库进程，该进程从表中删除冗余列并将其放到辅助表中，辅助表按主键与外键的关系链接到主表。
行拆分将原始表垂直分成多个只包含较少列的表。拆分的表内的每个逻辑行与其他表内的相同逻辑行匹配。例如，联接每个拆分的表内的第十行将重新创建原始行。
与水平分区一样，垂直分区使得查询需要扫描的数据变少了。这将提高查询性能。例如，某个表包含七列，通常只引用该表的前四列，那么将该表的后三列拆分到一个单独的表中将有利于提高性能。
应谨慎考虑垂直分区操作，因为分析多个分区内的数据需要查询联接这些表。如果分区过大的话，也会影响性能。
已分区表和已分区索引
已分区表和已分区索引的数据划分为分布于一个数据库中多个文件组的单元。数据是按水平方式分区的，因此多组行映射到单个的分区。对数据进行查询或更新时，表或索引将被视为单个逻辑实体。单个索引或表的所有分区都必须位于同一个数据库中。
已分区表和已分区索引支持与设计和查询标准表和索引相关的所有属性和功能，包括约束、默认值、标识和时间戳值以及触发器。因此，如果要实现位于服务器本地的已分区视图，则可能需要改为实现已分区表。
设计分区以提高查询性能
根据经常执行的查询类型和硬盘配置，对表或索引分区可能会提高查询性能。
² 对联接查询分区
如果经常执行的查询涉及两个或多个已分区表之间的同等联接，则这些查询的分区依据列应该与联接表所基于的列相同。另外，应当已配置了这些表或它们的索引。这意味着它们要么使用同一命名分区函数，要么使用在以下方面基本相同的不同函数：
ü 具有相同数量的用于进行分区的参数，对应的参数具有相同的数据类型。
ü 定义了相同数量的分区。
ü 定义了相同的分区边界值。
这样一来，SQL Server 查询优化器就可以更快地处理联接，因为分区可以自行联接。如果查询联接的是联接字段未配置或未分区的两个表，则分区的出现实际上会降低而不是提高查询处理速度。
² 利用多个磁盘驱动器
可以将分区映射到文件组，每个分区访问一个不同的物理磁盘驱动器，以便提高 I/O 性能。当 SQL Server 针对 I/O 操作执行数据排序时，它会首先按分区对数据进行排序。在此方案下，SQL Server 每次访问一个驱动器，这样可能会降低性能。为了提高性能，更好的解决方案是通过设置 RAID 将多个磁盘中的分区数据文件条带化。这样一来，尽管 SQL Server 仍按分区对数据进行排序，但它可以同时访问每个分区的所有驱动器。不管所有分区是在一个文件组中还是在多个文件组中，都可以设计此配置。有关 SQL Server 如何处理不同的 RAID 级别的详细信息，请参阅 RAID 级别和 SQL Server。
Ø 服务器群集提供了以下三种主要的群集技术优点：
ü 更高的可用性。允许服务器群集中的服务和应用在硬件或软件组件故障下或在计划维护期间仍能不间断地提供服务。
ü 更高的可扩展性。支持通过增加多个处理器（在 Windows Server 2003 Enterprise Edition 中最多可达 8 个，在 Windows Server 2003 Datacenter Edition 中最多可达 32 个）和额外内存（在企业版中，随机存取内存 [RAM] 最多可达 8 GB，在 Windows Server 2003 Datacenter Edition 中最多可达 64 GB）来扩展服务器。
ü 更高的可管理性。允许管理员如同管理单台计算机那样管理整个群集内的设备和资源。
Ø 故障转移群集
Microsoft SQL Server 2005 中的故障转移群集为整个 SQL Server 实例提供高可用性支持。例如，您可以将故障转移群集的一个节点上的 SQL Server 实例配置为在发生硬件错误、操作系统错误或计划升级时故障转移到此群集中的任何其他节点。
故障转移群集是一个或多个节点（服务器）与两个或多个共享磁盘的组合，即资源组。资源组（包括其网络名称）和一个 Internet 协议 (IP) 地址组合在一起，构成了称为“故障转移群集或故障转移群集实例”的群集应用程序或群集服务器。SQL Server 故障转移群集出现在网络中时就像是单台计算机一样，但是它具有一种功能，能够在当前节点不可用时从一个节点故障转移到另一个节点。故障转移群集出现在网络中时就像一个普通应用程序或单台计算机一样，但是它具有可提高可用性的其他功能。
Ø 数据库引擎优化顾问
概述
数据库引擎优化顾问是一种工具，用于分析在一个或多个数据库中运行的工作负荷的性能效果。工作负荷是对要优化的数据库执行的一组 Transact-SQL 语句。分析数据库的工作负荷效果后，数据库引擎优化顾问会提供在 Microsoft SQL Server 数据库中添加、删除或修改物理设计结构的建议。这些物理性能结构包括聚集索引、非聚集索引、索引视图和分区。实现这些结构之后，数据库引擎优化顾问使查询处理器能够用最短的时间执行工作负荷任务。
数据库引擎优化顾问的使用
数据库引擎优化顾问提供了两种使用方式：
ü 图形界面。用于优化数据库、查看优化建议和报告的工具。
ü 命令行实用工具程序dta.exe。用于实现数据库引擎优化顾问在软件程序和脚本方面的功能。
SQL Server的优化
SQL Server的优化主要指通过调整数据库的物理设计和逻辑设计来提高性能。
SQL Server的物理设计通常指调整SQL Server的存储架构，SQL Server上的数据分布。
SQL Server的逻辑设计通常指合理使用额外的数据库对象来提供应用性能，例如索引、存储过程和视图等等。
软件策略需要考虑的东西则相对会多一些，主要是数据库设计分为物理设计和逻辑设计。
物理设计考虑的主要是数据在物理存储介质上的
因为在做Web Casting的时候碰到了听众问起，所以就在这儿写一些软件调整方法：
ü 调整硬件配置，增加CPU数量、内存容量，使用RAID 5甚至是RAID 10，可以提高服务器的整体性能。
ü 使用原始分区，对于有独立储存设备的数据库服务器，可以考虑使用原始分区，将数据文件创建在原始分区上，可以提高SQL Server的数据读取性能。
ü 使用文件组，通过创建文件组，用户可以控制数据将被写入那些分区和磁盘中，这样我们就可以将数据和索引分开，还可以将读写策略不同的数据分开。
ü 数据分区，合理地将数据按用户访问策略的差异分布在不同的服务器上，然后通过联合视图来提高性能。
ü 增加索引，通过为经常出现在查询条件语句中的字段创建索引，用户可以加快数据被检索的速度。
ü 减少索引，通过在经常修改的表上减少索引数量，可以加快数据修改和添加的速度。
ü 使用视图，对于经常执行的数据检索任务，用户可以考虑创建视图，视图是预定义的数据检索对象，SELECT语句通常能被保存在程序缓存中，从而减少语句被编译的时间。
ü 为视图创建索引，为经常访问的视图合理创建索引，可以进一步提高视图的访问速度。
ü 使用存储过程，存储过程的定义同样会被缓存在数据库服务器的程序缓存中，从而反复执行语句时可以减少
ü 使用DBCC PINTABLE，这句语句可以强制某张表的数据不会从数据缓存中被换出，对于频繁访问的小表，可以极大程度提高数据访问效率。
ü 缩短事务中代码数量，缩短事务长度通常代表数据库对象锁定时间减少，减少锁对系统的负面影响。
ü 尽量避免在触发器中ROLL BACK，触发器中回滚事务会引起很大的系统开销，应该改用事前检查。