如何解决索引过宽的问题
本文关键字:问题 索引 何解决 解决 | 更新日期: 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 的值作为查询参数存在的查询有用,当它是查询参数时,其余字段无关紧要。