何时手动重新计算索引统计信息答案

【问题标题】：When to manually re-calculate indices statistics何时手动重新计算索引统计信息
【发布时间】：2017-10-23 10:01:33
【问题描述】：

我有一个存储连续数据的应用程序。然后根据两列（timestamp 和 integer）选择行。

为了保持性能尽可能好，我必须重新计算索引的统计信息，但是根据时间间隔重新计算有两个问题：

我读到最好在负载最小的时间内每天重新计算一次索引统计信息，这对于某些网络或公司数据库来说是很好的建议，但这是完全不同的情况，所以我想添加一些“智能” "进入自动重新计算。

每个表是否有一些行数（42；1,000；1,000,000？），之后应该重新计算统计信息？是否还取决于表中当前的总行数？

【问题讨论】：

如果有空的话，最好销毁索引，从头开始重建。它要么是drop 和create，要么是alter index NAME inactive，然后是alter ... active
还要考虑批量插入。如果您不需要实时反应，那么创建临时的非索引文件（可能作为外部表）并按计划（如每 5 分钟一次）一个特殊的守护进程确保每个人都停止从数据表中读取可能是有意义的，然后停用索引，然后从临时累加器批量插入数据，然后重新激活索引，然后清除这些累加器，然后让其他程序再次读取表。 SQL 不太适合直接插入硬件传感器等定期生成的数据，最好将其解耦
@Arioch'谢谢，我已经有某种队列，我可以从其中一次在execute block 中插入许多行。但我这样做没有停用索引。
那么你的索引树每行都被改变了，并且树在“快速改变功能失调的一侧倾斜”和“重新平衡，部分重建到功能失调较少的状态之间摇摆，与投入了很多时间”然后你一次又一次地这样做。如果您确实必须进行大规模的“批量插入” - 那么有时将工作暂停、终止索引、插入大量数据并重新构建索引会总体上更快。
此外，如果您的数据库变慢 - 那么可能还有其他原因，例如糟糕的事务管理。您查看一些关于 firebird 变慢的一般原因的常见问题解答，例如 OIT/OAT/NT 间隙失控失控等。

【解决方案1】：

服务器使用统计信息从可用索引中选择最佳索引。检查非空数据库上的查询计划。如果它在当前统计数据下是最优的，并且相对数据分布不随时间变化，或者没有其他指标可供选择，则不需要强制重新计算。

其他方法涉及使用查询文本直接指定最佳计划，或使用算术运算从评估中排除某些字段的索引，而不管实际统计信息如何。

例如，如果查询包含条件：

  table_1.some_field = table_2.some_field

并且您不希望服务器在字段 table_1.some_field 上使用索引然后写：

  table_1.some_field + 0 = table_2.some_field

这样你可以强制服务器使用一个索引而不是另一个。

【讨论】：

我不确定我是否理解关于数据分布的部分。由于数据是连续保存的，我会说数据分布会随着时间而变化。
@Artholl 当前版本的 Firebird 没有非常广泛的统计信息（没有直方图，只有基本的选择性信息），所以如果您有数据库中代表性人口的统计信息，那么通常不需要经常计算统计，因为Firebird是根据比较相关指标的选择性来选择指标的，虽然实际的选择性可能会发生变化，但很可能不会改变各个指标的选择性之间的相对差异。
@MarkRotteveel 谢谢。代表性人口是我无法轻易获得的，因为一列可能具有大约一千个不同值的值。它可能只是一个安装上的一个值，而另一个安装上的千值。问题是，这可能会随着时间而改变，在这种情况下，它会完全破坏保存的选择性。