索引/性能策略的大量相同值

Question

基本信息：这是在OpenStreetMap数据的索引过程的上下文中。为了简化问题：核心信息分为3个主要类型，值为“W”，“R”，“N”（VARCHAR(1)）。

该表大约有大约75M行，所有带“W”的列组成大约42M行。现有索引与此问题无关。

---

现在问题本身：数据的索引是通过一个过程完成的。在此过程中，有一些循环执行以下操作：

[...] SELECT * FROM表WHERE the_key =“W”; [...]

结果再次循环，上面的查询本身也在循环中。这需要花费大量时间并且大规模地减慢过程。索引the_key显然无用，因为索引可能使用的所有值都是相同的（“W”）。脚本本身运行速度很快，只有SELECT需要很长时间。

我

• 需要创建一种“特殊”类型的索引，将此考虑在内并使SELECT更快？如果是这样，哪一个？
• 需要调整一些服务器参数（它们已经过调整，它们提供的结果似乎很好。如果需要，我可以发布它们吗？）
• 必须忍受速度，只需获得更多硬件以获得更多力量（Tim Taylor grunt grunt ）？

上述各点的替代方案（除非重写或不使用它）？

Answer 1

如果将work_mem设置得足够高以启用位图索引扫描，则此查询可以使用索引。但是，很有可能优化器仍然不会选择使用它。总而言之，对此进行优化并不多。看起来周围的循环代码需要改进。

Answer 2

首先你说：

  

桌子大约有7500万左右   行，所有带“W”的列组成   ~42M行。

然后你说你做了

SELECT * FROM table WHERE the_key = "W";

循环几次并期望它执行？这是不可能的 - 没有索引会加速这个查询 - 它必须返回42M行 - 超过一半。如果您拒绝重写此索引过程以避免多次查询，那么它只是The Daily WTF值得的。