我有一个包含数百万行的表。我需要找到具有特定列值的所有行。该列不在索引中，因此将进行表扫描。

但是，将索引添加到最前面的列(紧跟主键)，执行查询，然后删除索引会更快吗？

当用户指定他们要查找的列时，我无法永久添加索引。

解决方案

回答

添加索引需要进行表扫描，因此，如果我们不能添加永久索引，则听起来单次扫描会(略)快一些。

回答

不，那不会更快。更快的方法是仅添加索引并将其保留在其中！

当然，为每一列建立索引可能不切实际，但随后可能会再次索引。如何将数据添加到表中？

回答

不会的。即使计算复杂度相同，创建索引也比简单地扫描列更复杂。

那就是说你有几列？如果单个查找的查询时间过长，我们确定不能仅为每个索引创建索引吗？

回答

我不是DBA，但是我想建立索引无论如何都需要扫描表。

除非在该列上有多个查询，否则我建议不要创建索引。

不过，最好同时检查两种方法的解释计划/执行时间！

回答

这取决于查询的复杂性。如果我们一次检索数据，那么进行表扫描会更快。但是，如果我们要多次返回该表以获取同一查询中的相关信息，则索引会更快。

另一个相关策略是进行表扫描，并将所有数据放入临时表中。然后对THAT进行索引，然后就可以对索引数据的子集进行所有的后续选择，分组和其他许多查询。好处是使用temp表在相关表中查找相关信息的速度大大加快了。

但是，这些天空间很便宜，因此最好通过检查用户实际使用系统的方式并在那些频繁访问的列上添加索引来为我们提供最好的服务。我还没有看到用户一直在使用所有搜索参数。

回答

就像其他人都说过的那样，最肯定的是添加索引不会比对该列进行全面扫描要快。

但是，我建议跟踪查询模式并找出搜索最多的列，并至少为其添加索引。我们可能会发现3-4个索引可以加快90％的查询速度。

回答

要考虑的两个问题：

• 可以为查询指定多少列？
• 数据是否经常更改？很多吗？

如果候选列数量很少，并且数据变化不大，那么我们可能要考虑在任何甚至所有候选列上添加永久索引。

我听到"亵渎！"。大多数资料都告诉我们"永远"不要索引表的每一列，但是建议的依据是表经常被修改的一般假设。

我们将为额外的存储空间付出一定的代价，并在数据发生变化时降低性能。

小小多大是多，值得进行权衡吗？
由于"太慢"通常是一种主观测量，因此无法确定先验。

我们将必须尝试一下，测量索引的大小，然后测量它们在搜索中产生的效果。我们将不得不在成本与增加客户满意度之间取得平衡。

[添加]哦，还有一件事：临时索引不仅在物理上比表扫描慢，而且会破坏并发性。重新索引表通常(总是吗？)需要完整的表锁定，因此实际上一次只能进行一次用户搜索。

祝你好运。

回答

除非我们向每列添加一个永久索引，并且查询中返回的所有列都在包含列的列表(覆盖索引)中，否则解决方案将无法扩展。这些索引将非常大，并且对该表的插入和更新会慢一些，但是如果允许用户随意选择搜索列，则没有太多选择。

有几列？数据多久更新一次？插入和更新需要运行多快？根据这些问题的答案，需要进行权衡。做大量的实验和测试，以便我们确定如何执行。

但是对于原始问题，仅在查询期间执行多个选择(例如，选择位于子查询中，针对返回的每一行运行)时，为单个查询目的添加和删除索引才有好处。 )。