MySQL如何处理长度有限的复合唯一索引?
假设 MySQL (MyISAM) 表中有两列:
title VARCHAR(1500)
url VARCHAR(155)
我想在这两列上创建一个复合唯一索引。我知道太长的列(例如我的 title
列)的限制长度功能。它如何与复合索引一起发挥作用?
我想要的是这样的:
|--- url_value ---| + |--- title_value ---|
|--------155------| + |--------rest-------| <-- This should be the key length
我的意思是键应该具有最大长度(我使用 utf8 作为编码,因此唯一索引每列允许的字符数限制为 333 个字符),其中 url< 列的所有 155 个字符唯一索引中应考虑 /code> 和
title
列的 178 个字符。抱歉英语不好。我尽力解释。因此,如果这看起来令人困惑,请耐心等待,如有必要,我很乐意提供更多信息。
Assuming two columns in a MySQL (MyISAM) table:
title VARCHAR(1500)
url VARCHAR(155)
I want to create a composite unique index on both columns. I know of the limiting length feature for too long columns (like my title
column). How does it play with compound indexes?
What I want is something like:
|--- url_value ---| + |--- title_value ---|
|--------155------| + |--------rest-------| <-- This should be the key length
By that I mean the key should have maximum length (I am using utf8 as encoding so I am limited to 333 characters allowed per column for unique indexes), where all 155 characters of column url
and 178 characters of column title
should be respected in the unique index. Sorry for the bad English. I tried to explain as well as I could. So bear with me if it seems confusing and I gladly will provide more information, if necessary.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我不太确定你的问题是什么,所以这可能无法真正回答它,但是在这样的长字段上强制执行唯一性的一种选择是使用 MD5 或任何其他方法对长字段的哈希值强制执行唯一约束其他适合您需求的哈希算法。所以...
您可以创建一个触发器,每次更新
title
时都会自动填充title_md5
。然后,您将唯一索引放在(url,title_md5)
上。当然这有一些缺点。实际表中存在更多开销——尽管其中大部分可以通过更小/更高效的索引来抵消。此外,索引
title_md5
并不会使搜索实际title
列更快,因此您可能需要在title
上建立“重复”索引,如果你需要对此进行搜索。I'm not exactly sure what your question is, so this may not really answer it, but one option for enforcing uniqueness on long fields like that is to instead enforce a unique constraint on a hash of the long fields, using MD5, or any other hashing algorithm that suits your needs. So...
You could create a trigger that automatically populates
title_md5
every timetitle
is updated. Then you put your unique index on(url,title_md5)
.Of course this has some drawbacks. There is more overhead in the actual table--although much of that can be offset by the smaller/more efficient index. Also, indexing
title_md5
doesn't make searching the actualtitle
column any faster, so you may need a "duplicate" index ontitle
, if you need to do searching on that.