简单的问题。假设我有一个users 表和一个cars 表。 cars 表有一个 user_id、make、model,我总是用 user_id 查询它的数据:
SELECT * FROM cars WHERE user_id = 123 AND make = 'honda'
SELECT * FROM cars WHERE user_id = 123 AND model = 'accord'
假设我总是使用 user_id 查询 cars 表,是添加两个多列索引 [user_id, make] 和 [user_id, model](对于额外的列可能更多)还是为每个索引添加一个单列索引更好? user_id、品牌和型号列?
让我感到困惑的是拥有多个以相同 foreign_key 开头的多列索引的想法。看起来这最符合我的查询,但不确定它对数据库的正确性/效率/浪费程度。
最佳答案
这个答案考虑了数据库中什么是最“正确/最有效/最少浪费”。
Assuming I always query the cars table with a user_id,
也就是说,您对数据执行的操作或访问数据的方式与数据库设计和整体性能无关。它仅与该单个查询相关。
is it better to add two multicolumn indexes [user_id, make] and [user_id, model] (and potentially more for additional columns), or a single-column index for each user_id, make, and model column?
单列索引是多余的,性能不好,没有 yield 。
- 另外,您应该更新每一列的统计数据。
首先,除了你的问题,PK 应该是:
( user_id, make, model )
因为(没有看到表的完整 DDL),这是提供行唯一性的唯一方法,这在关系数据库中是必需的。您不需要额外的索引,即使添加了属性列也是如此。
- 如果您在该文件中有一个 car_id 字段,由于它需要额外的索引,它是多余的、冗余的和负面的性能。您可以安全地将其删除。
其次,对于您所描述的查询,该 PK 索引是您唯一需要的索引。
- What's confusing me is the idea of having several multicolumn indexes that all start with the same foreign_key.*
是的,这应该引起警觉。并不是说它们都以相同的 FK 开头,而是它们以相同的列开头。具有最大列集的索引使其他列变得多余。
关于postgresql:具有外键的多个多列索引?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30365566/