这是一个创建于 401 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如字段大概长度是 500 个字符，我们存到数据库
这个字段设置为索引，同时查询的时候，是等于的方式查（不是 like ）
这样在数据量大起来的时候，有查询新性能问题不？
请大佬赐教一下
需不需要额外存一个字段的 md5 值，每次查询 md5 即可，这样字段值会短很多。
谢谢
这个字段设置为索引，同时查询的时候，是等于的方式查（不是 like ）
这样在数据量大起来的时候，有查询新性能问题不？
请大佬赐教一下
需不需要额外存一个字段的 md5 值，每次查询 md5 即可，这样字段值会短很多。
谢谢
 |
1
guochenglong 2023-11-23 17:52:26 +08:00
这么长的字段，索引得多大啊
|
 |
2
KimAndBella 2023-11-23 17:59:24 +08:00
1. 设置索引肯定不行，太大了
2. 存这个字段的 md5 ，有什么意义？你肯定是 like 的方式查询这个字段，不可能说全内容先 md5 再通过 md5 去查询 3. 如果这个字段内容是通用的，很多记录都会有相同的内容，那么可以考虑新增一张表，字段 1 存储全内容，字段 2 存储 md4 ，原表存储 md5 4. 如果 3 不行的话，考虑 es 吧 5. 考虑业务是否真的需要这样做 |
 |
3
MadDoggy 2023-11-23 18:16:47 +08:00
前缀索引了解一下
|
 |
4
Huelse 2023-11-23 18:16:52 +08:00
请把专业的活交给专业的工具，关系性数据库不是干这个的
|
 |
5
ZZ74 2023-11-23 18:50:58 +08:00
500 个字符的索引 光索引的存储大小就和整张表差不多了。
我都怀疑关系型数据库是否真的会去走索引。。。。 确定永远等于查询的话，md5 也可 |
 |
6
NoKey OP @KimAndBella 多谢恢复。有个系统，鉴权的 token ，400 多个字符，我要记录这个 token ，后续要对比，就是全查，我考虑着这么长的字符，计算一个 md5 查起来是不是效率点。脑壳痛~🤣
|
 |
7
crysislinux 2023-11-23 19:24:46 +08:00 via Android
@NoKey 要不改改设计，加个短的 client id ，如果是用户系统就是 user id ，鉴权去查 client id 对应的 token 存不存在，是否还有效。登录系统也是这样设计的，没听说谁去数据库查加密了的密码的。
|
 |
8
rekulas 2023-11-23 19:39:06 +08:00
如果你是全等查询,那 md5 作为索引是正确的,速度几乎不受多少影响 即使是亿级表也在 1-10 毫秒级
|
 |
9
june4 2023-11-23 22:03:56 +08:00
我记得在哪本权威 sql 调优书里写过类似场景，就是大字符串比较要加一个索引 hash 列，不用太长（太长占过多内存，比如完整 md5 就过长，如果数据量大的话能省不少内存），md5 前 6-8 个字符足够，因为二个值出来的 hash 相同也没关系。
然在 sql 里写 where hash = ? and str_value = ?，mysql 会优先通过索引找到 hash 相同的行（一般就 1 个），然后再比较 str_value 值。 |
 |
10
adoal 2023-11-23 22:17:45 +08:00
建 hash index
|
 |
11
xuanbg 2023-11-24 08:10:41 +08:00
存着不影响性能，读的时候不批量读取很多行也没什么性能问题。建索引也不是不能建，就是太长了性能不好。如果超长了就建不了索引了。非要索引的话，建议存 hash 建索引。
|
|
12
xuanbg 2023-11-24 08:13:50 +08:00
@NoKey 鉴权的 token 它没有自己的 id 么？我是把 token 存 redis 的，key 就是 Token:id 。这个没必要存数据库啊。
|
 |
13
msaionyc 2023-11-24 11:05:34 +08:00
直接存查询性能会非常低，当然如果数据量不大的场景其实也没问题。
MD5 摘要后加索引的方式是可行的，性能会提升非常多 |
 |
14
dode 2023-11-28 14:05:08 +08:00
把 token 存 redis 呢
|
Select Language