如果一个表的几乎全部列（除了一些创建时间，更新时间，创建人，更新人）加起来要求唯一，如果建唯一索引吗？因为每次查询也相当于全表扫描，但是又要求唯一限制。但是他的遍历 IO 是顺序的，而且几乎我要查询的列都在索引中（覆盖索引）我觉得肯定是比全表扫描快的。但是是否有必要再建个索引，或者有什么更好的做法吗？
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2369 days ago, the information mentioned may be changed or developed.
 |
1
机翻语文，看不懂
|
4 |
2
如果仅仅是为了要求唯一。。。
为什么不程序全部列一起计算 hash 这样只需要处理一个列 |
 |
pmispigMay 11, 2020
3
写个函数计算这几个列字符串拼接的 md5 值，以后就直接看 md5 值就可以了
|
 |
whileFalseMay 11, 2020
4
ls 说的 hash 是一个办法，不过更新就挺麻烦的。
|
 |
sadfQED2May 11, 2020 via Android
5
由业务代码保证唯一，或者像上面老哥说的所有列拼起来计算 md5
|
 |
abcbuzhimingMay 11, 2020
7
说 hash 的没考虑过数据量稍微上来一点就是会撞的这个问题吗？
|
|
reusMay 11, 2020
8
|
 |
MuninnMay 11, 2020
10
可能是我运气好吧 我用了很多年 还没撞过 笑
|
 |
MithrilMay 11, 2020
11
你可以直接用 MD5，或者其他更简单的摘要算法对你全列加和做个 hash，然后对保存这个数值的列做聚类索引。
检索的时候把这个列作为优先条件，然后再查你的条件。这样保证可以快速过滤数据，又可以保证碰撞不会影响最终结果。 |
 |
xupefeiMay 11, 2020 via iPhone
12
用一个列做索引，然后字符串拼贴后做 bloom filter 。
插入数据时，如果在 bloom filter 里发现冲突，就用索引去一个一个检查冲突项。 |
 |
HstarMay 11, 2020
14
这个思路就是表中单独一列存摘要，摘要可以纯拼接字符串或者用摘要算法算一个，如果存在有几列的数据可能会很长那么只能用摘要算法。
数据里不大的情况下不需要关心摘要碰撞，如果有强唯一需求，可以用碰撞概率更低的摘要算法或者业务逻辑上先检查摘要一致再逐列检查是否一致。 |
|
reusMay 11, 2020
15
@Mithril 就算是更弱的 sha1，也从来没有在你说的“自然情况下”出现过碰撞。直到 2017 年才出现人为构造的碰撞，和你的理解恰恰相反： https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
|
 |
RuiQMay 11, 2020
16
哈希索引
|
 |
fzhyzamtMay 11, 2020
17
用 crc32 作账号唯一键 id 几年没撞过
|
Select Language