请教一下，长字符串存到数据库中有没有查询性能问题

这么长的字段，索引得多大啊

1. 设置索引肯定不行，太大了
2. 存这个字段的 md5 ，有什么意义？你肯定是 like 的方式查这个字段，不可能说全内容先 md5 再通过 md5 去查询
3. 如果这个字段内容是通用的，很多记录都会有相同的内容，那么可以考虑新增一张表，字段 1 存储全内容，字段 2 存储 md4 ，原表存储 md5
4. 如果 3 不行的话，考虑 es 吧
5. 考虑业务是否真的需要这样做

前缀索引了解一下

请把专业的活交给专业的工具，关系性数据库不是干这个的

500 个字符的索引 光索引的存储大小就和整张表差不多了。
我都怀疑关系型数据库是否真的会去走索引。。。。
确定永远等于查询的话，md5 也可

@KimAndBella 多谢恢复。有个系统，鉴权的 token ，400 多个字符，我要记录这个 token ，后续要对比，就是全查，我考虑着这么长的字符，计算一个 md5 查起来是不是效率点。脑壳痛~

@NoKey 要不改改设计，加个短的 client id ，如果是用户系统就是 user id ，鉴权去查 client id 对应的 token 存不存在，是否还有效。登录系统也是这样设计的，没听说谁去数据库查加密了的密码的。

如果你是全等查询,那 md5 作为索引是正确的,速度几乎不受多少影响 即使是亿级表也在 1-10 毫秒级

我记得在哪本权威 sql 调优书里写过类似场景，就是大字符串比较要加一个索引 hash 列，不用太长（太长占过多内存，比如完整 md5 就过长，如果数据量大的话能省不少内存），md5 前 6-8 个字符足够，因为二个值出来的 hash 相同也没关系。
然在 sql 里写 where hash = ? and str_value = ?，mysql 会优先通过索引找到 hash 相同的行（一般就 1 个），然后再比较 str_value 值。

建 hash index

存着不影响性能，读的时候不批量读取很多行也没什么性能问题。建索引也不是不能建，就是太长了性能不好。如果超长了就建不了索引了。非要索引的话，建议存 hash 建索引。

@NoKey 鉴权的 token 它没有自己的 id 么？我是把 token 存 redis 的，key 就是 Token:id 。这个没必要存数据库啊。

直接存查询性能会非常低，当然如果数据量不大的场景其实也没问题。

MD5 摘要后加索引的方式是可行的，性能会提升非常多

把 token 存 redis 呢