未使用的索引对性能的影响

在我的网站中，我不创建用户。用户被/创建在不同的系统中，我无法访问。未使用的索引对性能的影响

在那里，他们用一个用户ID = VARCHAR（50）

在我的身边，我保持一个非常简单的表格，像

UserId VARCHAR(50) 
Employer VARCHAR(4) 
UserSpecificField VARCHAR(8) 
DateWhenItWasAddedToOurSystem DATETIME

在登录到我的系统，我只是做一个简单的SYNC，所以我也有我的系统中的每个人。我在这张表中获得了2000条记录。

问题：

我知道索引是好的，应该使用它。我正在考虑在此表中添加一个索引列，但我不确定这是否有帮助。

即使您不将该列用于任何事情，是否正在添加可帮助提升性能的索引？因为我在任何地方都使用USER，所以我不得不使用用户的VARCHAR（50）ID来创建SQL JOIN。

谢谢

来源

2013-03-15 Ash

你对'UserId'或'UserId'是否有索引？有了2000个条目，索引不会显着提升您的应用程序。但是，加入或查询索引时索引将有所帮助。还有其他依赖项：用户表中使用了哪些其他列，更新用户表的频率等。顺便说一句，从未使用的列索引只是插入，更新和删除的性能负担。 – Claude 2013-03-15 09:12:22

在这一点上我没有任何索引在这张桌子上。但是有一个1mil记录的表，使用UserId Varchar（50）col – Ash 2013-03-15 09:14:44

与这个表结合在一起。在这些情况下，'UserId'上的索引（或者更好的主键约束）将有助于避免整个表扫描。在添加索引测试查询计划之前，添加索引并再次测试查询计划。 – Claude 2013-03-15 09:22:25

把旁边的小桌子大小，还有在此结构的表对用户ID添加索引是没有意义的。请注意，此列（由于varchar（50）字段平均填充50％），此单列将占表大小的70％。因此，数据库引擎必须首先扫描索引（它几乎与enitre表的大小相同），然后在表中查找记录。这个操作比只扫描一个表会更耗费资源。我很肯定，优化器根本不会使用索引。自己测试一下。在我看来，唯一的选择是添加一个聚集索引，它实际上是通过UserId对你的表进行“排序”，使得查询运行得更快，并且不会通过构建附加结构（即“普通”索引）产生任何开销。我认为更新操作不经常执行。

create unique clustered index idxCLU__userid on <your_table_name>(UserId)

来源

2013-03-15 09:28:21

未使用的索引对性能的影响

回答

相关问题