Mysql :大字符串上的“唯一”约束

Question

在MYSQL中为大字符串 (varchar) (大致为100个字符)设置唯一约束可能会带来什么不利影响：

• 插入阶段
• 检索阶段(在另一个主键上)

查询的长度会影响读写的性能吗？(除了用于记帐的磁盘/内存使用外)。

谢谢

Answer 1

几个问题。索引中列的大小有限制(191,255,767,3072等，取决于各种情况)。

您的列符合限制.

只需为该列设置一个UNIQUE或PRIMARY键即可。这里有一些轻微的性能问题，但是要记住这一点:获取一行比涉及用于定位它的键的任何数据类型问题都要花费更多。

你的专栏不适合.

现在，解决办法变得丑陋起来。

• 索引前缀(INDEX foo(50))存在许多问题和效率低下。
• UNIQUE foo(50)完全错了。它声明前50个字符必须是唯一的，而不是整个列。
• 散列字符串(cf、md5、sha1等)存在许多问题和效率低下。不过，这可能是执行长字符串唯一性的唯一可行方法。

(如果需要的话，我会详细说明。)

获取一行(假设语句被解析并且PRIMARY KEY可用)。

1. 向下钻取包含数据的BTree (并由PK命令)。这可能涉及将磁盘中的块(或更多)带到buffer_pool中。
2. 解析块以找到行。(该块中可能有几十行。)
3. 在进程的某个时候，锁定行，以便读取和/或被其他连接(例如，更新或删除)阻塞。
4. 把这一行拆开--也就是说，分成几列。
5. 对于所需的任何文本/blob列，请进入非记录存储区。(宽列不与行的窄列一起存储；它们存储在其他块中。)昂贵的部分是定位(如果没有缓存的话从磁盘读取)包含大TEXT/BLOB的额外块。
6. 将内部存储器(不对字、小终端等)转换为所需的格式。(少量CPU代码，但有必要)。这意味着数据文件在操作系统甚至硬件上都是兼容的。)

如果下一步是比较两个字符串(用于联接或ORDER )，那么对扫描的一个简单的子例程调用(不管有多少个字符)。(好，大多数utf8排序规则都不是“简单”的。)是的，比较两个INT会更快。

磁盘空间

INT是否应该用于PRIMARY KEY而不是VARCHAR(100)？那得看情况。

• 每个辅助键都有一个PRIMARY KEY副本。这意味着，一个PK，即VARCHAR(100)，使得二级索引比如果PK是INT时更大。
• 如果没有辅助键，那么上面的注释意味着INT是更大的方法！
• 如果有两个以上的辅助键，那么使用varchar可能更笨重。
• (对于一个辅助键，它是tossup。)

速度

• 如果SELECT的所有列都位于辅助索引中，则查询可以完全在索引的BTree中执行。(“覆盖索引”，如EXPLAIN中“使用索引”所示)。这有时是一个有价值的优化。
• 如果上述情况不适用，并且通过辅助索引查找行很有用，那么就有两个BTree查找--一次在索引中，然后通过PK。这有时是一个明显的放缓。
• 这里的要点是，人为地添加INT id可能比简单地使用庞大的VARCHAR作为PK要慢。每一宗案件都应根据其权衡作出判断；我不是在作笼统的陈述。