Mysql：对大字符串的'UNIQUE'约束

Question

在MYSQL期间对大字符串（varchar）（大约100个字符左右）具有UNIQUE约束的可能缺点可能是：

• 插入阶段
• 检索阶段（在另一个主键上）

查询的长度是否会影响读/写的性能？ （除了用于记账的磁盘/内存）。

谢谢

Answer 1

几个问题。索引中的列大小有限制（191,255,767,3072等，具体取决于各种事物）。

您的列符合限制。

只需为该列制作UNIQUE或PRIMARY键。存在一些轻微的性能问题，但要记住这一点：获取一行比涉及用于定位它的密钥的任何数据类型问题更昂贵。

您的专栏不适合。

现在变通办法变得丑陋了。

• 索引前缀（INDEX foo(50)）存在许多问题和效率低下。
• UNIQUE foo(50)是错误的。它声明前50个字符被限制为唯一，而不是整个列。
• 散列字符串的解决方法（参见md5，sha1等）存在许多问题和效率低下的问题。尽管如此，这可能是强制执行长字符串唯一性的唯一可行方法。

（如果需要，我会详细说明。）

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

1. 向下钻取包含数据的BTree（并按PK排序）。这可能涉及将一个块（或更多）从磁盘带入buffer_pool。
2. 解析块以找到该行。 （块中可能有几十行。）
3. 在进程中的某个时刻锁定行以进行读取和/或被某些其他连接阻塞，例如更新或删除。
4. 将行分开 - 也就是说，分成列。
5. 对于所需的任何text / blob列，请访问off-record存储。 （宽列不与行的小项一起存储;它们存储在其他块中。）
6. 从内部存储（不是字对齐，小端等）转换为所需的格式。 （少量CPU代码，但必要。）

如果下一步是比较两个字符串（对于JOIN或ORDER BY），那么一个简单的子例程调用扫描多个字符。 （好吧，大多数utf8校对都不是'简单'。）而且，是的，比较两个INT会更快。