1

我还不是很精通 SQL。我正在学习,但这是一个缓慢的过程。我正在从事一个项目,该项目将大量信息存储在 SQL Server 的数据库中。在其中一个表 ContactInformation 中,当尝试修改条目时遇到错误,因为由所有地址信息组成的非聚集索引超过 900 字节。我曾经sys.dm_db_index_usage_stats验证修改表中的条目会导致 3user_seeks和 1 user_update

C# 代码似乎没有直接调用索引。它执行一个由具有 19 个参数DbCommand的各种存储过程命令组成的单个命令。Update我的想法是要么消除索引,要么尝试DbCommand使用较少的参数将其分解为多个更新,以期使用较小的索引。

由于缺乏经验,我有点不知所措。我欢迎任何关于下一步转向的建议。

该指数包括以下内容:

| Name                 | Data Type     | Size |
|----------------------|---------------|------|
| ContactInformationID | int           | 4    |
| CompanyID            | smallint      | 2    |
| Address1             | nvarchar(420) | 840  |
| Address2             | nvarchar(420) | 840  |
| City                 | nvarchar(420) | 840  |
| State                | nvarchar(220) | 440  |
| PostalCode           | nvarchar(120) | 240  |
| Country              | nvarchar(220) | 440  |

是的,大多数列都过大。我们显然是从另一个项目继承了这个数据库。我们的软件将大多数列限制为不超过 100 个字符,尽管存在一些异常值。

4

2 回答 2

1

索引大小限制仅适用于键列。它适用于所有基于 B-Tree 的存储模式(NCI 和 CI)。存在这个限制是为了确保树扇出一定程度,以限制树的高度。

如果您不需要在 Address1 和 Address2 之类的列上查找(考虑到它们也可能为空),请使这些列包含列。

索引键不应长于产生唯一索引的最短键前缀。与包含的那一列相比,之后的每一列都没有帮助。

于 2014-08-13T22:38:05.063 回答
0

如果 ContactInformationID 是唯一的,我感觉它很可能是唯一的,那么在索引中包含任何其他字段都是没有意义的。

这样的索引仅对 ContactInformationID 的值作为查询参数存在的查询有用,并且当它存在时,其余字段无关紧要。

于 2014-08-13T20:21:42.907 回答