如何检查是否在数据库中存在的记录 - 最快的方法

Question

我在那里我存储唯一的文本字符串，然后我做选择

String checkIfAlreadyScanned = "SELECT id FROM \"STRINGS_DB\" where STR ='" + mystring + "'"; 

然后检查是否在数据库中存在该字符串表我是否值存在。我的数据库有大约5mil的记录;我可以改进我的方法吗？

也许有一种方式创建一个新的属性（hashedSTR）为例，并将字符串转换为一些独特的数字值，然后得到这些数字，而不是字符串？这会更快吗？ （？将是在所有的工作）

Answer 1

保证了最快的处理，确保：

• 您正在搜索的字段建立索引（您讲述一个“独一无二”的字符串，所以我假设它已经是这样了。因为这个原因，“限1”是没有必要的。否则，它应该被添加）
• 您在使用Command对象的ExecuteScalar()方法

Answer 2

String checkIfAlreadyScanned = "SELECT 1 FROM \"STRINGS_DB\" where STR ='" + mystring + "'"; 

如果您的结果集包含行，那么你就会有记录

Answer 3

限制结果设置为1：

String checkIfAlreadyScanned = @" 
    SELECT id 
    FROM ""STRINGS_DB"" 
    where STR ='" + mystring + @"' 
    limit 1"; 

这一个指数该专栏以及针对ExecuteScalar()的@Laurent建议将产生最佳结果。

此外，如果mystring有任何机会已被用户触及然后参数化查询，以避免SQL注入。

一个清洁的版本：

String checkIfAlreadyScanned = @" 
    SELECT id 
    FROM ""STRINGS_DB"" 
    where STR = '@mystring' 
    limit 1 
    ".replace("@mystring", mystring); 

Answer 4

[编辑] 限制结果返回到返回它遇到的第一个记录符合标准： 使用Sql Server：选择TOP 1 ...; 对于mysql/postgres：select ... LIMIT 1;

如果可以有多个，那么在您的select语句中添加“TOP 1”可能会返回得更快。

String checkIfAlreadyScanned = "SELECT TOP 1 id FROM \"STRINGS_DB\" where STR ='" + mystring + "'"; 

这样，它只需要找到字符串的第一个实例。

但是，如果您没有倍数，那么使用这种方法不会看到太多好处。

就像其他人所说的那样，在它上面加上索引可能会有所帮助。

Answer 5

假设你实际上并不需要的id列，我认为这使编译器有机会最优化：

select 1 
where exists(
    select 1 
    from STRINGS_DB 
    where STR = 'MyString' 
) 

Answer 6

多久这些文本字符串？如果它们很长，可以通过存储字符串的散列（以及原始字符串）来提高性能。

CREATE TABLE strings_db (
    id  PRIMARY KEY INT, 
    text  TEXT, 
    hash  TEXT 
); 

您的哈希列可以存储MD5总和，CRC32s或您选择的任何其他哈希算法。它应该被索引。

然后修改您的查询是这样的：

SELECT id FROM strings_db WHERE hash=calculate_hash(?) 

如果你的文本字段的平均大小是比你的哈希的尺寸足够大，这样做在较短场搜索将磁盘I帮助/ O.这也意味着在插入和选择时计算散列以及用于存储散列的额外磁盘空间会产生额外的CPU开销。所以所有这些因素都必须考虑在内。

P.S.始终使用预准备语句来避免SQL注入攻击！

Answer 7

虽然这里所有的答案都有其优点，但我想提一下另一个方面。

以这种方式构建您的查询并传递字符串不会帮助数据库引擎优化您的查询。相反，您应该编写一个存储过程，将其称为传递一个参数，并让数据库引擎构建一个查询计划并重用您的命令。

当然领域应该被索引

Answer 8

其实就是就是这样的东西你喜欢的。但它有一些限制。 PostgreSQL支持一个hash索引类型：

CREATE INDEX strings_hash_idx ON "STRINGS_DB" USING hash (str); 

作品进行简单的等式搜索与=，就像你拥有了它。我quote the manual的限制：

散列索引操作目前未WAL-记录，所以哈希索引 可能需要一个数据库崩溃后要与REINDEX重建。它们是 也不通过流式传输或基于文件的复制进行复制。对于 这些原因，目前不推荐使用散列索引。

---

一个真正的生命表，433K行，59 MB总简单的测试：

SELECT * FROM tbl WHERE email = 'some.user@some.domain.com' 

-- No index, sequnence scan: Total runtime: 188 ms 
-- B-tree index (default): Total runtime: 0.046 ms 
-- Hash index:    Total runtime: 0.032 ms 

这不是巨大的，但一些。与我测试中的电子邮件地址相比，差异将更大，更长的字符串。索引创建是1秒或2秒。与任一索引。

Answer 9

测试是没有意义的，只是包括在where子句中的“测试”：

INSERT INTO silly_table(the_text) 
'literal_text' 
WHERE NOT EXISTS (
    SELECT * 
    FROM silly_table 
    WHERE the_text = 'literal_text' 
    ); 

现在，你让测试仅在需要时：在语句的结束行将存在。有没有这样的事情尝试。

对于那些不了解测试是没有意义的：测试会意义，如果试验后的情况就不会被允许在测试后改变。这将需要测试&锁定方案。或者更糟的是：在交易中进行测试。

更新：版本作品（基本一致）：

DROP TABLE exitsnot CASCADE; 
CREATE TABLE exitsnot 
     (id SERIAL NOT NULL PRIMARY KEY 
     , val INTEGER -- REFERENCES something 
     , str varchar -- REFERENCES something 
     ); 

INSERT INTO exitsnot (val) 
SELECT 42 
WHERE NOT EXISTS (
     SELECT * FROM exitsnot 
     WHERE val = 42 
     ); 
INSERT INTO exitsnot (str) 
SELECT 'silly text' 
WHERE NOT EXISTS (
     SELECT * FROM exitsnot 
     WHERE str = 'silly text' 
     ); 
SELECT version(); 

输出：

DROP TABLE 
NOTICE: CREATE TABLE will create implicit sequence "exitsnot_id_seq" for serial column "exitsnot.id" 
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index "exitsnot_pkey" for table "exitsnot" 
CREATE TABLE 
INSERT 0 1 
INSERT 0 1 
              version            
---------------------------------------------------------------------------------------------- 
PostgreSQL 9.1.2 on i686-pc-linux-gnu, compiled by gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 32-bit 
(1 row)