正在根据文本列做一个完全匹配过滤器，概念上比基于密钥和使用编程语言进行过滤来抓取一组行更慢？基于文本列进行过滤
例如：
select columns from table where textcolumn='exactphrase';
VS
select columns from table where key='key';
for (results : resultset) {
if (resulsts.getString(textcolumn).equals(exactphrase)) { ... } }
我为MySQL如何（Innodb的）具有过滤文本列优惠和性能缺陷可能是什么（如果有的话）基本上好奇。
tldr; “查找”记录不会有性能差异。
由于使用（索引）PK，所以最多将返回单个记录。该服务器足够智能以便而不是对文本列执行表扫描，即使由于PK的1-1基数而没有编制索引。 （查询规划者是聪明的。）
的差异则：
，服务器可能会返回一个“无用”记录到客户端;这可能浪费少量的带宽（并且如果文本不是必需的，除了测试之外无疑更浪费），但更重要的是它的查询的语义的。
服务器支持不同的排序规则模式;它可能因此在服务器上对于不区分大小写的（例如）是，并且导致与客户端过滤器稍有不同的结果。
虽然非常退化情况可想而知，这应该采取的“等效时间”没有一个明确的使用/性能情况。然而，IMOHO在客户方面仍然sl sl不乐，没有进一步的理由。
也许，但我怀疑它。
在一组约束中，每个表，数据库和查询都是不同的。如何“快”的查询是，在一台服务器上，可以依靠以下（在许多其他事情）：
一般来说它总是更快的SQL做的一切，但这取决于所有上述所以它不能肯定。
唯一确定的方法是自己尝试。如果您遇到问题，您可以随时发布您的查询，解释计划，表格和索引定义，也许有人可以提供帮助。
对不起，我更新了我的帖子。我很欣赏这个解释，但是当我真正意味着一个索引列时，我不小心写了主键。 – tau
@tau同样，现代的查询计划者很聪明。根据统计数据，他们几乎总是会赞成索引超过表扫描。如果有疑问，请询问使用的*特定*查询计划。 – 2012-11-27 19:38:10