具有预测和产品的查询的良好索引（postgreSQL）答案

【问题标题】：Good indexes for queries with projections and products (postgreSQL)具有预测和产品的查询的良好索引（postgreSQL）
【发布时间】：2018-01-24 11:09:06
【问题描述】：

对于这两种情况，什么是好的索引？

一）

SELECT p.content, u.name
FROM posts p, admins a, users u
WHERE
p.tag = a.tag and 
a.id = u.id and 
p.content = 'Hello World';

SELECT u.name, p.date
FROM users u, posts p
WHERE
u.userid = p.userid and 
p.content = 'Hello World';

我尝试通过逐个创建不同的索引来了解性能如何受到影响。对于每个新索引，查询运行得更快，但是在删除它们之后，获得的性能仍然存在。所以最后，我无法比较。

【问题讨论】：

今天的提示：切换到现代、明确的JOIN 语法 - 更易于编写（没有错误）、更易于阅读，并且在需要时更易于转换为外连接。
数据库将数据和统计信息等缓存到内存中。这可能对您有用：stackoverflow.com/questions/1216660/…
要备份@jarlh : JOIN 符号现在已经超过 25 年了，它已经足够投票、开车、甚至结婚等等了。更不用说旧的基于 , 的符号了在大多数 RDBMS 中已弃用。
@MatBailie：尽管我同意你的观点，但我认为 where 子句中旧的隐式连接在任何 DBMS 中都不会被弃用。事实上，他们必须支持它们，因为它仍然是 SQL 标准的一部分。一些 DBMS 已弃用其在 where 子句中用于 outer 连接的非标准语法
@a_horse_with_no_name ：如果在 ANSI SQL 标准中意味着 RDBMS 实现了某些东西，那么生活会简单得多。没有什么可以将still part of the SQL standard 与have to support them 关联起来；）

【解决方案1】：

永远不要在FROM 子句中使用逗号。始终使用正确、明确的JOIN 语法。

所以，这样写查询：

SELECT p.content, u.name
FROM posts p JOIN
     admins a
     ON p.tag = a.tag JOIN
     users u
     ON a.id = u.id
WHERE p.content = 'Hello World';

还有：

SELECT u.name, p.date
FROM posts p JOIN
     users u
     ON u.userid = p.userid
WHERE p.content = 'Hello World';

最好的索引在

不幸的是，每个表都没有一个索引可以匹配这些查询。他们使用不同的列。

【讨论】：

这些索引中的列顺序在这种情况下起着重要作用吗？另外，假设“WHERE p.content = 'Hello World';”始终是固定的，以某种方式将其用于部分索引不是更好吗？
@Gouz 。 . .索引中列的顺序非常重要。
会不同（相对）表大小，更喜欢不同列顺序的多列索引吗？例如案例 A：以下 2 个案例中的索引顺序是否应该保持不变？：1）我期望 users
@Gouz 。 . .在大多数情况下，这些将是查询的最佳索引，因为该索引将直接用于where 子句。