索引VARCHAR列是一个好主意/方法吗？

32

我们正在使用PostgreSQL v8.2.3。

有涉及的表：EMPLOYEE和EMAILLIST。

Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)

2个表以这种方式连接，如果EMPLOYEE.EMAIL1或EMPLOYEE.EMAIL2没有匹配的条目，则将返回这些行。

SELECT employee.email1, employee.email2,
        e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched
   FROM employee
   LEFT JOIN emaillist e1 ON e1.email = employee.email1
   LEFT JOIN emaillist e2 ON e2.email = employee.email2
 WHERE e1.email IS NULL OR e2.email IS NULL

列EMAIL是VARCHAR（256）的EMAILLIST表索引。现在，响应时间为14秒。

表格计数统计信息：目前，EMPLOYEE已获得165,018条记录，而EMAILLIST已获得1,810,228条记录，并且这两张表都有望在未来增长。

索引VARCHAR列是一个好主意/方法吗？由于我们在应用程序中之前未对VARCHAR列进行索引，因此我立即想到了这个问题。非常感谢专家对此的建议/建议。
使用当前的查询和索引，14秒的响应时间是合理的还是有进一步调整的余地？根据这种表的大小和响应时间，其他用户的实时体验/意见是什么？

注意：我的实际需求/用例在这里详细说明。

— 加纳姆
source

25

如果您要基于varchar列进行索引，则没有任何问题。但是，请记住，某些索引及其在单个字段中可以索引多少有限制。例如，您无法索引可以包含无限量文本的列。但是，您应该能够对varchar（256）进行索引，而不会出现问题。尝试一下，并分析查询性能方面的改进，看是否有帮助。

— 异特罗卡地
source

感谢您的宝贵意见。在这方面是否可以进一步调整查询以将响应时间从14秒减少到什么范围？

— Gnanam 2011年

2

没有EXPLAIN的结果，就不可能告诉我们要优化什么。版本8.2.3也已过时，您应该升级到较新的版本，您的维护工作落后了4年。在许多情况下，版本8.3、8.4和9.0也更快。更好的统计信息也有助于提高性能。

— Frank Heikens 2011年

5

这样就没有索引varchar列的问题

当您将varchar列作为十亿行表中的FK时，可能会成为问题。然后，您将拥有PK和FK的代理键，但是您仍然需要对自然varchar键的唯一约束/索引。

您的表很小，性能可能与OR子句有关。不幸的是，无论您如何构造查询，都存在相同的问题（我对PostgresSQL并不十分了解，对此深表歉意）

— gbn
source

0

尝试摆脱查询的“ OR e2.email IS NULL”部分，并查看其运行速度。如果运行速度更快，您可以通过“全部联合”运行速度更快

— 乔·洛夫
source