【发布时间】：2014-07-10 14:22:24
【问题描述】：
启动项目时，是否应该一开始就创建SQL索引？
我有一个项目，我还没有在生产环境中创建任何索引。增长最多的表有 30000 行，我测量了针对该表创建索引并随后删除它的查询时间。时代非常相似。
我决定推迟在生产环境中创建索引，直到我注意到创建索引时查询的响应时间有所减少。
我的方法正确吗？还是我现在应该创建它们？
【问题讨论】：
【发布时间】：2014-07-10 14:22:24
【问题描述】：
我对数据库索引这个话题非常深入（这实际上是我的全职工作，还写了一本关于它的书（SQL Performance Explained），可免费获得here）。
在我看来，索引应该在您编写查询时创建，因为此时您拥有决定在头脑中创建哪些索引所需的所有必要信息。换句话说，如果你在那个时候去做，它不会花费你任何额外的努力。另一个原因是索引有时会影响您编写查询的方式，因此它实际上可以利用该索引。
但是，上面的语句假设您知道索引是如何工作的，因此您可以决定要创建哪些索引。如果您不知道，我真的建议您先了解正确的索引。同样，我写的这本书可以在网上免费获得 (Table of Contents)。根据最近的一项调查，阅读它大约需要 4-5 个小时。我会说，度过了美好的时光。
但是，由于现代硬件的ludicrous speed 和大量内存（即使是廉价的商品硬件），您绝对有可能无法测量这些小表的任何差异（30k 在 DB 世界中很小）。然而，因为您无法用可能 10 毫秒的计时器分辨率来测量这种差异，这并不意味着差异不存在。进一步：您是否验证了该索引是否被实际使用？您确定您创建的索引是给定查询的良好索引吗？
无论如何，如果目前整个系统对您来说足够快，请确保您可以在没有索引的情况下继续操作。但是，风险仍然存在，即在主要新闻媒体报道您的应用程序的那一天，它还不够快。应该是你最好的一天可能会变成你最糟糕的一天:(
你没有告诉我们很多关于你的应用的信息，所以我必须做一些猜测。我想它更像是一个在线网站（而不是 BI/OLAP）之类的 OLTP 应用程序。尽管索引增加了一些写入操作的开销（insert、update、delete 和merge），但与它们给select 带来的好处相比，这通常很小（仍然假设 OLTP）。当然，您可以滥用索引（例如，在单个表上创建数百个），因此开销也成为一个主要问题。但是由于维护开销，在 OLTP 表上添加“一些”索引肯定不会导致任何问题。
即将结束：如果您已经知道哪些索引适合您的查询（使用explain 进行验证），请立即添加它们，以免为时已晚。如果您不确定，我仍然建议您现在为此付出一些努力。如果您不害怕负载峰值导致您的应用宕机，请继续不使用索引。
如果您需要更多帮助，请创建一个新问题，其中包含您的查询、表和索引定义以及解释输出，人们会很乐意帮助您确定该索引是否正常。
【讨论】：
-
是的，我知道索引是如何工作的，但我根本不是专家，所以我会读你的书。感谢您的链接。我喜欢您在创建查询时创建索引的意见，因为此时您可以获得更多信息。
现在只需根据明智的选择创建它们：从主键和外键开始 - 这样可以保持快速连接 - 然后在您将要搜索的单个列（姓名、电话等）上添加索引。
避免创建多列索引，直到您发现性能问题并且可以证明索引有帮助。通常，修改查询比一些复杂的索引更能解决问题。
我唯一延迟创建索引的时间是，如果我要加载一堆数据并在加载之前构建索引，这意味着加载速度要慢得多，因为每次添加行都会更新索引，尽管有些数据库允许索引重建被推迟到加载之后，所以即使这样也没有必要等待。
【讨论】：