2000W 个不重复的 32 位长字符串存于 mysql 中，现在怎样判断该数据表中存在某个特定值？

[Reign]

目前的业务逻辑是，有 2000W 个 32 位长字符串存在 mysql 中，该 mysql 表就只有 2 个字段，自增 id 和 hash ，现在要验证这个表中是否存在某个 hash 值，怎样用最简单快速的方法查询？我想到过用 redis 来存，但是内存吃不消，有没有好的解决方案？谢谢

[ichou]

@cloudzhou 你不觉得你多了一次写入么，哈哈
如果要保证原子性，你还必须要加上事务，写并发一旦飙起来，扑街

[luban]

redis 开压缩，两三 G 内存吧

[billlee]

才两千万，直接建索引足够了

[xfwduke]

有效数据行长度 40 bytes
2000kw 数据 762MB
算上 Innodb 的空洞, 各种乱七八糟的元数据, 3GB 差不多了吧
这点数据, 写算法都多余, 建个索引

就现在服务器的内存量, 最后整个索引估计都在 buffer pool 里面.
别说服务器了, 桌面机都能搞定, 并发访问不大的话

[shiny]

做索引，而且不需要整个字符串都在索引里面。

[ryd994]

hash 不要用 hex 字符串存，用二进制字符串或者 binary 类

[ryd994]

另外楼上有说取前几位加列的，你们真的懂数据库索引么？
索引 n 叉树结构本来就是先比较前面的
如果后几位的随机性比前几位好的话，取后几位做联合索引，或者用于分表，倒是有的
换句话说，如果这种技巧有用，数据库自己早就该用了

[azh7138m]

彩虹表吧，之前黄易那个我算完是 7500w 条， MySQL 分下表就好了，其他优化不做查起来也是快的飞起

[jsou]

才 2000w 数据,建个索引,一个 where 条件不就出来了.
如果这都要优化这优化那的,那这数据库软件就不能用了.

[ijustdo]

把这个 32 位串当做表的主键

[Septembers]

直接建立个 Hash Index 吧
see https://dev.mysql.com/doc/refman/5.7/en/index-btree-hash.html

[Septembers]

Hex String 直接 string 储存开销有点大
可用固长 binary 储存可获得小一半的开销（同时也能降低索引的储存开销）
see https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html

[abccoder]

建立索引直接搞

[ijustdo]

别在 yy 其它建撒索引了 把这个 32 位串当做表的主键 这样最快 不行你们可以试试看

[realpg]

高度怀疑楼主只是在编问题，根本没有这个环境进行测试

首先使用我的专用低性能测试机（用于测试程序性能） MYSQL 导入 2000W 条记录，插入 2000W 条数据用时 2787 秒(因为生成随机串的发生器有一定不随机性，生成了一部分重复数据，实际数据量 19787975 条，近似当两千万看吧 懒得继续插了)



结构（索引情况）


服务器配置：
AMD 不知道啥时候的双核低端 CPU ， 2G*2 DDR2 800 内存，硬盘 500G 普通 SATA 淘汰硬盘

随便从库里找 50 个串进行搜索，使用 SQL NO CACHE 同时每个数据只查一次避免其他缓存干扰

执行时间均为 0.00002 秒

[realpg]

不小心发出去了
插入两千万条数据用了将近 3000 秒，对我的破机器 IO 性能有直接概念了吧
DDR2 内存时期的古董双核 AMD 入门 CPU ，执行性能也有概念了吧
索引直接加在 hash_id 上，未限定索引长度，全默认，唯一索引

直接检索，都是 0.0002 秒这个量级，检索过一次产生缓存以后，每次查询都是 0.0001

[mingyun]

@realpg 赞实践