在启动项目时,是否应该在开始时创建SQL索引？
我有一个项目,我还没有在生产中创建任何索引.将增长最多的表有30000行,我已经测量了对该表的查询时间,创建索引并在之后删除它.时间非常相似.
我决定推迟在生产中创建索引,直到我发现在创建查询时减少了查询的响应时间.
我的方法是否正确？或者我应该现在创建它们？
我非常深入研究数据库索引的主题(它实际上是我的全职工作,还写了一本关于它的书(SQL Performance Explained),这里可以免费获得).
在我看来,应该在编写查询时创建索引,因为这是您拥有决定在头脑中创建哪些索引所需的所有必需信息的时间.换句话说,如果你当时这样做,它不需要你额外的努力.另一个原因是索引有时会影响您编写查询的方式,因此它实际上可以利用该索引.
但是,上述语句假定您知道索引的工作方式,以便您可以决定要创建哪些索引.如果你不知道,我真的建议先了解正确的索引.同样,我写的这本书可以在网上免费获得(目录).根据最近的一项调查,您需要大约4-5个小时来阅读它.花时间,我会说.
然而,由于现代硬件的速度和大量内存 - 甚至是廉价商品硬件 - 的荒谬速度 - 你绝对不能用这些小表(30k在DB世界中很小)测量任何差异.然而,你是因为你无法用10ms的定时器分辨率来测量这种差异,这并不意味着差异不存在.进一步:您确认该索引是否实际使用过？您确定您创建的索引是给定查询的良好索引吗？
从来没有,如果整个系统目前足够快,你肯定可以继续没有索引.然而,风险仍然存在,在主要新闻媒体覆盖您的应用程序的当天,它还不够快.什么应该是你最好的一天可能会成为你最糟糕的一天:(
你没有告诉我们很多你的应用程序,所以我要做一些猜测.我想它更像是一个像在线网站的OLTP应用程序(而不是BI/OLAP).虽然索引会增加写操作(insert,和)的开销update,但delete与merge它们带来的好处相比,这通常很小select(仍然假设是OLTP).当然你可以滥用索引(例如,在一个表上创建数百个),这样开销也成为一个主要问题.但是,在OLTP表上添加"一些"索引肯定不会因维护开销而导致任何问题.
即将结束:如果您已经知道哪些索引适合您的查询(使用说明进行验证),请在为时已晚之前添加它们.如果你不确定,我现在仍然建议你付出一些努力.如果您不担心负载峰值会使您的应用程序停机,请继续使用索引.
如果您需要更多帮助,请创建一个包含查询,表格和索引定义以及解释输出的新问题,人们将很乐意帮助您确定该索引是否正常.