mar*_*kus 7 postgresql performance index index-tuning query-performance
我们在 Postgres 9.2.10 数据库中有一个大约有 20 列的表。为了在某些SELECT查询上获得更好的性能，我们计划在数据类型为 的列上添加索引timestamp。由于索引也会降低插入的性能，我们做了以下性能测试：
我们在表中插入了 500 万条记录。那是最大值。我们期望在生产中的记录数。然后我们测量了在时间戳列上插入有索引和没有索引的 10000 条记录的时间。这是我们每天预期的最大插入次数，峰值每秒不超过 5 次插入。
结果如下：
至少对于本次测试，该指数仅略微降低了性能。对于我们的要求，我没有看到添加索引的问题。
但这只是实验室环境中的一项测试，在生产数据库上运行时是否还有其他陷阱？我们是否会遇到INSERT在特定情况下突然需要超过 5 秒的情况？
不，小列上的基本 btree 索引通常维护起来很便宜。当然，当表因死行而积累了一些膨胀时，它会稍微昂贵一些，但差异应该很小。并且您必须考虑在磁盘上为索引提供额外的存储空间。
有件事似乎值得一提：以任何方式对索引中涉及的列进行更新都不能使用热更新（“仅堆元组”），因此这可能会增加更改索引列的更新的一些成本。但尽管如此，这只会阻止一项内部优化，没什么大不了的。并且仅当您将该专栏包含在更新中时才相关。