数据库设计与性能 (SQL Server Compact Edition)

项目
05/21/2007

通过正确设计 SQL Server 数据库和发布，可以显著提高 SQL Server 2005 Compact Edition (SQL Server Compact Edition) 应用程序性能。下列各节概述了可以用来增强性能的方法。

使用非规范化数据库

规范化的数据库可防止数据存在功能相关性，以便轻松、高效地更新数据库。但是，查询数据库时可能需要联接许多表来组合信息。随着联接表数目的增多，查询运行时间会大大增加。因此，规范化的数据库并不一定是最佳的选择。如果数据库适当程度地不合规范，则可以减少必须联接在一起的表的数目，而不会使更新过程过于复杂。这通常是一个很好的折衷办法。

注意：
通常，如果有相当多的查询需要联接五个或六个以上的表，则应考虑使用非规范化数据库。

此外，数据库还有一些其他非规范化类型。例如，假设某数据库有以下两个表：Orders 和 Order Details。Orders 表包含客户订单的相关信息。Order Details 表包含每个订单中的具体产品。假设您希望查询每个订单的总美元金额。首先，您需要确定每个产品的美元金额（数量 * 单价 – 适用的折扣）。随后，您还需要按订单汇总这些金额。查询如下所示：

SELECT "Order ID", SUM("Unit Price" * Quantity * (1.0 - Discount))

AS Total FROM "Order Details"

GROUP BY "Order ID"

Order ID Total

----------------------------------------

10000 108

10001 1363.15000915527

10002 731.800003051758

10003 498.180023193359

10004 3194.19999694824

10005 173.400009155273

10006 87.2000007629395

10007 1405

10008 1171

10009 1530

10010 470

... ...

(1078 rows affected)

此查询的计算量不小。如果订单较多，运行查询将会花费很长时间。另一种方法是在下订单时计算订单的美元金额，然后将该金额存储在 Orders 表内的某个列中。使用此方法，只需查询该预先计算列即可返回所需的信息：

SELECT "Order ID", "Order Total" AS Total FROM Orders

通过创建预先计算的列，您可以节省大量查询时间，但是使用此方法时需要在表中多维护一列。

采用可变长度列还是固定长度列

在设计表时，了解使用可变长度列和使用固定长度列各有哪些利弊是非常有用的。由于可变长度列仅占用存储实际值所需的空间，所以可减小数据库大小。而固定长度列始终会占用架构定义的最大空间，即使在实际值为空时也是如此。与固定长度列相比，可变长度列的缺点是一些操作的效率不高。例如，如果可变长度列开始时很小，而某 UPDATE 子句使其显著增大，则可能就要重新定位记录。此外，频繁的更新会导致数据页随着时间推移变得比较零碎。因此，在数据长度变化不大并且需要频繁进行更新时，建议使用固定长度列。

创建长度较小的行

页中可容纳的行数取决于各行的紧凑程度。如果行较小，则页中可以容纳更多的行。因此，对行较为紧凑的表执行的单磁盘操作可以检索更多的行，从而使操作更为有效。此外，存储引擎缓存中也可以包含更多的行，而这可能会提高命中率。使用紧凑的行还可以防止浪费数据页上的空间。使用较大的行时，通常就会有这种浪费情况。

试考虑下面的极端示例：如果记录大小稍大于数据页的一半，每个数据页就会浪费几乎一半的空间。一些数据库设计人员会选用宽表设计方案并将主机数据库架构移植到设备上。这并不是一种高效的设计方案。一种可能的方法是拆分那些最关键的表。假设您有一个表，其中某些列具有非常稳定的值，而其他列的值更改非常频繁。那么，将这个表拆分为两个表（一个表包含频繁引用的列，另一个表包含稳定的列）是很有意义的。通过创建两个表，即可拥有长度较小的行的所有优点。但缺点是需要使用联接来组合信息。

使用长度较小的键

索引是创建索引所基于的表的有序子集。使用索引，可以快速地在一定范围内进行查找并指定排序顺序。与较大的键相比，较小的索引键占用的空间更小，并且更为有效。因为主键经常作为其他表的外键引用，所以使用紧凑的主键十分有用。如果没有现成的紧凑主键，则可以改用实现形式为整数的标识列。

具有一个或少数几个键列的索引称为窄索引。具有许多键列的索引称为宽索引。宽索引的键长度通常较大。一个极端的索引示例是包括表中的所有列。通过创建这样的索引，可以有效地制作原始表的副本。不过，在数据库大小和查询性能方面，这种做法的效率都十分低下。

发布项目的类型和选项

在 SQL Server 2000 中创建发布时，创建的发布将包含标准的项目。对这些项目进行筛选时，将使用常规筛选。但是，如果您是在 SQL Server 2005 中创建发布，则可以为发布中的项目选择两个附加选项。这两个选项可以控制筛选以及发布服务器和订阅服务器之间的数据流，分别是：

仅限下载(只读)
有时，希望在智能设备上使用的数据可能只存储在查找表中。例如，您的用户可能需要在智能设备上浏览公司通讯簿，但是不得编辑和更改此类信息。“仅限下载”项目类型正适合这种情况。由于不在设备上存储元数据，因此使用此类型时占用的空间更小，可以降低同步过程中的网络通信流量。
明确分区
虽然您可以使用 SQL Server 2000 创建分区组，但是这在上载数据过程中会对性能造成负面影响，因为在每次上载时都必须计算分区 ID 映射。对于 SQL Server 2005 中明确分区的项目，所上载的更改仅映射到单个分区 ID。这样速度更快，但有以下几点限制：
- 项目中的每一行必须仅属于一个分区 ID。
- 每个项目只能发布到单个发布中。
- 订阅服务器不能插入不属于其分区 ID 的行。
- 使用明确分区的项目还会影响筛选。筛选时有以下限制：
- 订阅服务器不能更新筛选所涉及的列。
- 在联接筛选器层次结构中，常规项目不能是明确分区项目的父级。
- 对于子级是明确分区项目的联接筛选器，join_unique_key 的值必须设置为 1。
- 每个项目只能有一个子集或联接筛选器。具有子集筛选器时，项目可以是联接筛选器的父级，但不能是联接筛选器的子级。

请参阅

通过