关于数据库表上的部分键和索引的问题
假设我对数据库表有两个查询。
查询是根据查询中使用的字段来定义的：
Query1：取决于 f1、f2 和 f3
Query2：取决于 f1、f2、f3 和 f4
我记得读过 SQL 查询引擎（在本例中为 mySQL）解析的地方从索引中最左边的字段开始的索引树。
如果这是正确的，那么我假设不是像这样在表上定义两个索引：
Index 1 (for Query1) : CREATE INDEX idx_1 {f1, f2, f3}
Index 2 (for Query2) : CREATE INDEX idx_2 {f1, f2, f3, f4}
我可以简单地定义一个索引，其中包含两个查询中使用的键的并集 - 即
我只需要定义这个索引：
(for BOTH Query1) : CREATE INDEX the_idx {f1, f2, f3, f4}
我有有两个问题：
我的假设正确吗？即我可以简单地定义一个索引 (the_idx) 而不是前两个索引吗？
此索引行为是否也适用于 PostgreSQL 查询引擎？
Suppose I have two queries on a database table.
The queries are defined in terms of fields used in the query:
Query1: depends on f1, f2, and f3
Query2: depends on f1, f2, f3 and f4
I remember reading somewhere that the SQL query engine (mySQL in this case) parses the index tree starting from the leftmost fields in the index.
If that is correct, then I assume that instead of having two indices defined on the table like this:
Index 1 (for Query1) : CREATE INDEX idx_1 {f1, f2, f3}
Index 2 (for Query2) : CREATE INDEX idx_2 {f1, f2, f3, f4}
I can simply define one index which contains the union of the keys used in both queries - i.e.
I only need to define this index:
(for BOTH Query1) : CREATE INDEX the_idx {f1, f2, f3, f4}
I have two questions:
Is my assumption correct?. i.e. can I simply define the one index (the_idx) instead of the previous two?
Does this index behavior hold true for PostgreSQL query engine as well?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的。
它称为覆盖索引，您希望根据最有可能使用查询的列对列进行排序。 IE：如果 f2 是最常见的列，您需要使用：
不，Postgres 不支持覆盖索引。
索引不是 ANSI 标准；供应商之间的术语如此一致真是一个奇迹。
Yes.
It's called a covering index, and you want to order the columns based on which is most likely to be used queries. IE: If f2 is the most common column, you'd want to use:
No, Postgres does not support covering indexes.
Indexes are not ANSI standard; it's a miracle the terminology is so consistent between vendors as it is.
一般来说，填充的索引越多就越有用。然而，您添加到该索引的内容越多，所需的开销就越大。
最好的办法是尝试一下，并查看执行计划，看看它是否按照您期望的方式使用。
根据结果集中返回的实际列，使用较短的索引可能更有利。
in general the more populated index will be useable. however the more you add in to that index, the more overhead it will require.
the best thing would be to try it, and look at the execution plan to see if it is used in the manner you expect.
depending on the actual columns returned in the result set, it may be more beneficial to use a shorter index.
MySQL 手册 相当清楚地表明，是的，可以在任何非哈希索引（这是其中的大多数）中搜索键的任何“前缀”。
我找不到 PostgreSQL 的任何类似文档，但您始终可以创建表，然后执行 EXPLAIN（无论如何，这不是一个坏主意）。
The MySQL manual makes it reasonably clear that yes, any "prefix" of a key can be searched in any non-hash index (which is most of them).
I couldn't find any comparable documentation for PostgreSQL, but you could always create the table and then do an EXPLAIN (not a bad idea anyway).