其中涉及到表：EMPLOYEE和EMAILLIST。这样的方式是，如果EMPLOYEE.EMAIL1或EMPLOYEE.EMAIL2没有匹配的条目，则将返回这些行。
EMAIL表已建立索引。现在，响应时间为14秒。表计数统计信息：目前，EMPLOYEE已获得165,018条记录，而EMAILLIST已获得1,810,228条记录，并且预计这两个表都将在未来增长。 br />
索引VARCHAR列是一个好主意/方法吗？由于我们在应用程序中之前未索引VARCHAR列，因此我立即想到了这个问题。对此，专家的建议/建议受到高度赞赏。
对于当前的查询和索引，14秒的响应时间是合理的还是有进一步调整的余地？根据这种表的大小和响应时间，其他用户的实时体验/意见是什么？
注意：这里详细解释了我的实际需求/用例。 >
#1 楼
如果要基于varchar列进行索引，则没有任何问题。但是，请记住，某些索引及其在单个字段中可以索引多少有限制。例如，您无法索引可以包含无限量文本的列。但是，您应该能够对varchar（256）进行索引，而不会出现问题。尝试一下，分析查询性能方面的改进，看看是否有帮助。#2 楼
像这样索引varchar列没有问题十亿行表中的varchar列作为FK会成为问题。然后，您将拥有用于PK和FK的代理键，但是您仍然需要对自然varchar键的唯一约束/索引。到OR子句。不幸的是，无论您如何构造查询，都存在相同的问题（而且我对PostgresSQL并不十分了解，对此深表遗憾）
评论
感谢您的宝贵意见。在这方面是否有进一步调整我的查询的范围，以将响应时间从14秒减少到什么时间？
–加纳姆
2011年1月24日13:53
没有EXPLAIN的结果，就不可能告诉我们要优化什么。版本8.2.3也已过时，您应该升级到较新的版本，您的维护工作落后了4年。在许多情况下，版本8.3、8.4和9.0也会更快。更好的统计信息也有助于提高性能。
–弗兰克·海肯斯（Frank Heikens）
2011年1月25日上午8:07