启动项目时，是否应该一开始就创建SQL索引？
我有一个项目，但尚未在生产中创建任何索引。增长最多的表有 30000 行，我测量了对该表创建索引并随后删除它的查询时间。时代很相似。
我决定推迟在生产中创建索引，直到我注意到创建索引时查询的响应时间减少了。
我的做法正确吗？或者我应该现在创建它们？
我对数据库索引主题非常深入（这实际上是我的全职工作，还写了一本关于它的书（SQL 性能解释），可以免费获取这里）。
在我看来，应该在编写查询时创建索引，因为此时您拥有决定要在头脑中创建哪些索引所需的所有信息。换句话说，如果你当时就这么做了，就不需要你付出任何额外的努力。另一个原因是索引有时会影响您编写查询的方式，以便它实际上可以利用该索引。
但是，上述语句假设您知道索引的工作原理，以便您可以决定创建哪些索引。如果您不知道这一点，我真的建议您首先了解正确的索引。同样，我写的书可以在网上免费获得（目录）。根据最近的一项调查，读完这本书大约需要 4-5 个小时。我想说，度过了愉快的时光。
但是，由于现代硬件的“速度惊人”和大量内存（即使是廉价的商品硬件），您绝对有可能无法用这些小表来衡量任何差异（30k 在数据库世界中很小）。然而，因为您无法用 10ms 的计时器分辨率来测量这种差异，但这并不意味着差异不存在。进一步：您是否验证了该索引确实被使用了？您确定您创建的索引对于给定查询来说是一个好的索引吗？ 无论如何，如果整个系统目前对您来说足够快，那么您肯定可以在没有索引的情况下继续。然而，风险仍然存在，即当主要新闻媒体报道您的应用程序时，它的速度不够快。本来应该是你最好的一天可能会变成你最糟糕的一天:(
您没有告诉我们很多有关您的应用程序的信息，所以我必须做一些猜测。我想它更像是一个在线网站之类的 OLTP 应用程序（而不是 BI/OLAP）。尽管索引为写入操作增加了一些开销（
insert、
updatedeletemergeselect即将结束：如果您已经知道哪些索引适合您的查询（使用explain
验证它），请立即添加它们，以免为时已晚。如果您不确定，我仍然建议您现在就为此付出一些努力。如果您不担心负载峰值会导致您的应用程序崩溃，请继续不使用索引。 如果您需要更多帮助，请创建一个包含查询、表和索引定义以及解释输出的新问题，人们将很乐意帮助您确定该索引是否正常。
避免创建多个列索引，除非您已经证明存在性能问题并且可以证明索引有帮助。通常，重新处理查询会比某些复杂的索引更好地解决问题。
我延迟创建索引的唯一时间是，如果我要加载一堆数据，并且在加载之前构建索引意味着加载速度要慢得多，因为索引会针对每行添加进行更新，尽管有些数据库允许推迟索引重建直到加载完成，所以即使这样也没有等待的意义。