正在根據文本列做一個完全匹配過濾器，概念上比基於密鑰和使用編程語言進行過濾來抓取一組行更慢？基於文本列進行過濾
例如：
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