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

Question

对于大字符串 UNIQUE 约束（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. 对于所需的任何text / blob列，请访问记录外存储。 （宽列不与该行的小项目一起存储；它们存储在其他块中。）
6. 从内部存储（非字对齐，小尾数法等）转换为所需的格式。 （少量的CPU代码，但有必要。）

如果下一步是比较两个字符串（对于JOIN或ORDER BY），则该简单的子例程调用将扫描是否有许多字符。 （好吧，大多数utf8排序规则都不是“简单的”。）而且，是的，比较两个INT会更快。