是否向SQL Server添加索引是一个坏主意？

我们有一个没有定义索引的中型SQL Server应用程序。甚至不在身份栏上。我建议我们这个价格适中的应用顾问，或许我们可以通过在适当的领域创建一些索引来获得更好的性能（特别是在我们的数据库增长时），他说：是否向SQL Server添加索引是一个坏主意？

“索引将显着影响应用程序和客户的其他领域不应该在任何情况下创造它们。“

有人听说过这样的事吗？在任何情况下，不会产生任何索引？我可以看到这个应用程序没什么特别的 - 它有int标识列，然后是很多字符串列，一堆关系表，但没有什么特别的或奇怪的，我可以看到。

谢谢！

[编辑：标识列没有使用“身份规范”，他们似乎由程序设定，寻找与Management Studio中的数据库，我可以找到NO指数...]

跟进：在一次会议上，我问了生产这款产品的公司的首席执行官（首席架构师），他的回应是，他们觉得中小型部署，与维护索引相关的开销会对整体用户造成更多负面影响经验（应用程序做了很多写操作）比索引的好处会抵消，但对于大型数据库，它们确实创建索引。技术支持人员过分热心，对他的回答非常无益。谜团已揭开。

来源

2010-05-21 Aerik

雇用我，我会为你创建索引。 14年的Sybase/SQL Server经验告诉我创建这些！darn！索引。除非您的表格每个记录少于500条记录。

我的想法是，一个索引散列节点大致尺寸为1000

你需要看出来的是你的顾问是否已归一化的表中的其他事情。也许，这个表格有500个字段/列，其中包含多个概念实体或者全部概念实体。这就是为什么他对创建索引感到紧张的原因，因为如果表中有12个概念实体，那么至少有12组索引 - 在这种情况下，他绝对是真实的 - 在任何情况下都不会......等等等等。但是，如果他确实每列有500列或可检测到多个概念实体 - 他是一个非常糟糕的数据设计工程师。在我所有的时间里，我与更有经验的数据工程师一起工作，我们的桌子很少超过20列偏低5人，平均10人。有时候为了提高性能，我们允许在一个表中混合两个实体，或者将行的出现水平化到一个表的列中。

当你看着桌子的设计，你可以用未经训练的眼睛看到Product，Project，BuildSheet，FloorPlan，Equipment等记录全部卷成一长排。您不能将所有这些实体混合在一个表中。

这是我知道他为什么可以建议你不要有索引的唯一原因。如果他这样做了，那么你应该知道他是在欺骗性地向你的公司展示他的数据设计技能，你应该立即将他从你的每周合同费用中扣除。好吧，在阅读larry的帖子之后 - 我也同意他的看法。

来源

2010-05-21 06:27:48

有一些表格有很多列，但它们似乎并不包含多个概念实体。较大的表格（按列显示）具有许多属性数据，这些数据似乎在该表格的合理组中。 – Aerik 2010-05-22 14:59:06

我见过我认为是30列的好桌子。但是，桌子遵循泊松分布，集中在5左右。 – Joshua 2010-05-23 16:23:15

的ID列不使索引听起来确实不寻常，我会找个不包括他们闻到腥很正当的理由。

你应该知道，如果你正在做一个大批量提交到数据库中，增加更多的指标会影响插入的速度，但在id的指数？哇。

这将是很好得到的究竟是如何增加额外的索引可能导致虽然问题的更好的理由。

来源

2010-05-21 01:14:29 spender

您有磁盘空间可用吗？我见过索引比表格更重要的情况。

但是，没有任何索引存在！除了所有读取操作需要整个表格之外，不能有这种情况。

来源

2010-05-21 01:16:22 Joshua

我们有足够的磁盘空间。我们的情况非常典型：大表，读操作通常寻求一个特定的行，或者执行SELECT TOP ... ORDER BY查询。所以它不是读整个表。 – Aerik 2010-05-21 01:37:16

其实它是 - 没有索引。没有任何索引，它只能读取整个表的任何内容。 – TomTom 2010-05-21 06:52:46

SELECT TOP ... ORDER BY ORDER BY列上的索引大大受益。 – Joshua 2010-05-21 15:03:40

无论如何，具有关键约束的列将具有隐式索引。所以如果你总是用主键选择，那么添加更多索引就没有意义了。如果您按照其他标准进行选择，那么在您查询的列上添加索引是有意义的。

这也取决于你的数据如何插入重的。如果插入次数多于查询次数，那么保持索引更新的开销会使插入速度变慢。

但是说你“不应该创建[索引]在任何情况下”是有点多。

我建议是，你运行SQL Server Profiler工具，你的一些疑问。该工具将推荐添加哪些索引对性能产生最大影响。

来源

2010-05-21 01:16:53

该应用程序肯定偏向于读取而不是写入 - 它似乎做了很多单独的SELECTs而不是利用连接 – Aerik 2010-05-21 01:32:59

我已经添加了一些关于SQL Server Profiler工具的信息。比价格昂贵的“顾问”要便宜得多，而且实际上也很有效;） – 2010-05-21 01:42:57

感谢分析器工具的建议 - 我之前只做过“手动”优化。我认为我们真正的问题在于我们是否愿意违背顾问的建议。真正的愤怒在这里是他从公司写的应用程序。 – Aerik 2010-05-22 14:56:10

更慢的数据插入和修改的索引越多。确保在适当的时候添加索引并编写可以利用这些索引的查询，而且如果索引的选择性水平较低，则不会有效使用

来源

2010-05-21 01:19:25 SQLMenace

在大多数普通应用程序，索引对插入性能的影响有点不成问题。创建索引通常会更好，如果插入性能急剧下降（可能不会），您可以尝试其他方法。显然有一些例外，你应该更加小心，比如用于记录实例的表。

如前所述，磁盘空间可能是一个问题。

创建不相关的索引（例如重复项）也会浪费微秒并偶尔会导致错误的查询执行计划。

我看到的另一个问题是奇怪的代码第三方应用程序在运行时生成数据库的一部分，并且可以删除或阻塞他们不知道的索引。

尽管绝大多数情况下，精心挑选的指标只会带来好处。

来源

2010-05-21 01:23:35 cbp

有这样的事情，过度索引，特别是在非常大的表的INSERT和UPDATE重度应用程序。因此，标题中对问题的回答是肯定的，添加索引有时候是一个糟糕的主意。

这与您在问题主体中提出的问题完全不同，即“在SQL Server数据库中没有索引是否正常？”。答案是，除非您将数据库用作“只写”系统，其中添加了数据，但只有在批量提取并转换为另一个数据存储库后才能读取数据库，这非常不寻常，不会在数据库。

您的顾问陈述很奇怪，让我相信您可能在描述中留下了一些重要信息。如果没有，我会说他是疯了。

来源

2010-05-21 01:44:30

我真的怀疑他正在掩盖这样一个明显的疏忽 - 他的公司宁愿给我们不好的建议，也不愿意让我们知道他们错过了他们设计中的数据库索引。 – Aerik 2010-05-21 01:59:15

要么，要么他是个白痴。在很多项目中，也看到了这一点 - 包括一些总Bunkhead数据库专家将所有字段的TEXT字段设置为长度不是对象模型的一部分（ergo：不可转位 - 即使是产品编号）。人们喜欢那个AREA，有时甚至是顾问。可悲的是， – TomTom 2010-05-21 06:55:08

如果我必须没有长度，我会使用postgresql，其中varchar（2000000000）是有效和可索引的，并且如果结果为varchar（100）是您所需要的，那么花费不会超过varchar（100）。 – Joshua 2010-06-15 19:53:57

是否向SQL Server添加索引是一个坏主意？

回答

相关问题