1
guochenglong 360 天前
这么长的字段,索引得多大啊
|
2
KimAndBella 360 天前
1. 设置索引肯定不行,太大了
2. 存这个字段的 md5 ,有什么意义?你肯定是 like 的方式查询这个字段,不可能说全内容先 md5 再通过 md5 去查询 3. 如果这个字段内容是通用的,很多记录都会有相同的内容,那么可以考虑新增一张表,字段 1 存储全内容,字段 2 存储 md4 ,原表存储 md5 4. 如果 3 不行的话,考虑 es 吧 5. 考虑业务是否真的需要这样做 |
3
MadDoggy 360 天前
前缀索引了解一下
|
4
Huelse 360 天前
请把专业的活交给专业的工具,关系性数据库不是干这个的
|
5
ZZ74 360 天前
500 个字符的索引 光索引的存储大小就和整张表差不多了。
我都怀疑关系型数据库是否真的会去走索引。。。。 确定永远等于查询的话,md5 也可 |
6
NoKey OP @KimAndBella 多谢恢复。有个系统,鉴权的 token ,400 多个字符,我要记录这个 token ,后续要对比,就是全查,我考虑着这么长的字符,计算一个 md5 查起来是不是效率点。脑壳痛~🤣
|
7
crysislinux 360 天前 via Android
@NoKey 要不改改设计,加个短的 client id ,如果是用户系统就是 user id ,鉴权去查 client id 对应的 token 存不存在,是否还有效。登录系统也是这样设计的,没听说谁去数据库查加密了的密码的。
|
8
rekulas 360 天前
如果你是全等查询,那 md5 作为索引是正确的,速度几乎不受多少影响 即使是亿级表也在 1-10 毫秒级
|
9
june4 360 天前
我记得在哪本权威 sql 调优书里写过类似场景,就是大字符串比较要加一个索引 hash 列,不用太长(太长占过多内存,比如完整 md5 就过长,如果数据量大的话能省不少内存),md5 前 6-8 个字符足够,因为二个值出来的 hash 相同也没关系。
然在 sql 里写 where hash = ? and str_value = ?,mysql 会优先通过索引找到 hash 相同的行(一般就 1 个),然后再比较 str_value 值。 |
10
adoal 360 天前
建 hash index
|
11
xuanbg 359 天前
存着不影响性能,读的时候不批量读取很多行也没什么性能问题。建索引也不是不能建,就是太长了性能不好。如果超长了就建不了索引了。非要索引的话,建议存 hash 建索引。
|
13
msaionyc 359 天前
直接存查询性能会非常低,当然如果数据量不大的场景其实也没问题。
MD5 摘要后加索引的方式是可行的,性能会提升非常多 |
14
dode 355 天前
把 token 存 redis 呢
|