如何解决索引过宽的问题

本文关键字:问题 索引 何解决 解决 | 更新日期: 2023-09-27 18:18:04

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

C# 代码似乎没有直接调用索引。它执行单个DbCommand,该命令由具有 19 个参数的 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 个字符,尽管存在一些异常值。

如何解决索引过宽的问题

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

如果不需要查找 Address1 和 Address2 等列(考虑到它们也可能为 null(,请将这些列设置为包含列。

索引键

不应长于导致唯一索引的最短键前缀。与包含的该列相比,之后的每一列都无济于事。

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

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