我在数据库中有一些表超过40 M的记录。
在计算机重启时，在第一个set statistics index id（对于每个索引），我花了大约一分钟。
第一次命令滑行后只有几毫秒。 在服务重启或程序重启时我没有这个问题：我只在重启时才看到这种行为，只是第一次执行索引重新计算。
Set statistics index index_dummy;
所以问题是： 如何避免这个'功能'？
答案 0 :(得分：1)
解决方案很简单：每次重启后都不要set statistics（或者考虑不要经常重启，这一分钟的延迟会变得明显）。
Firebird计算的索引统计信息相对简单，因此除非您的数据量（行数）有规律地改变数量级，否则选择性（索引值的唯一性）在＆＃34;之间变化很大。非常独特＆＃34;并且＆＃34;非常相同＆＃34;，重新计算可能对优化器没有可测量的影响，因为计算的统计数据只会稍微变化，这使得重新计算它的值很小甚至没有。
重启后第一次需要很长时间的原因可能是因为您的数据库（或至少是索引页）可以完全适合文件系统缓存。在引导后立即对所有索引执行set statistics将开始将所有索引页读入缓存。
随后重新执行set statistics将能够从缓存中读取页面，从而避免命中磁盘，从而显着加快速度。
请注意，完全有可能使用set statistics实际上是故意的并且使用（滥用）来填充文件系统缓存。这样，在初始性能启动后，数据库的所有其他用户都可以获得将所有索引加载到文件系统缓存中的好处。
如果这是贵公司的操作程序，您可能想在每次重启后询问为什么需要做set statistics（因为实际上：除此之外，还有如果指数值的数量和唯一性相对稳定，则无需定期执行此操作。）