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

Question

我们使用的是 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条记录，未来两个表都有望增长。

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

注意：这里详细解释了我的实际需求/用例。

Answer 1

如果您要基于 varchar 列进行查询，那么索引 varchar 列并没有错。但是请记住，某些索引以及它们在单个字段中可以索引的数量是有限制的。例如，您不能为可以包含无限量文本的列建立索引。但是，您应该可以毫无问题地对 varchar(256) 进行索引。尝试一下，并分析查询性能的改进，看看它是否有帮助。

Answer 2

索引 varchar 列没有问题

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

您的表很小，性能可能与 OR 子句有关。不幸的是，无论您如何构造查询，同样的问题都适用（而且我对 PostgresSQL 不够熟悉，无法提供太多抱歉）