年少不知自增好，错把UUID当个宝！！！

在 MySQL 中，使用 UUID 作为主键 在大表中可能会导致性能问题，尤其是在插入和修改数据时效率较低。以下是详细的原因分析，以及为什么修改数据会导致索引刷新，以及字符主键为什么效率较低。

---

1. UUID 作为主键的问题

（1）UUID 的特性

• UUID 是一个 128 位的字符串，通常表示为 36 个字符（例如：550e8400-e29b-41d4-a716-446655440000）。

• UUID 是全局唯一的，适合分布式系统中生成唯一标识。

（2）UUID 作为主键的缺点

1. 索引效率低

• 索引大小：UUID 是字符串类型，占用空间较大（36 字节），而整型主键（如 BIGINT）仅占用 8 字节。索引越大，存储和查询的效率越低。

• 索引分裂：UUID 是无序的，插入新数据时，可能会导致索引树频繁分裂和重新平衡，影响性能。

2. 插入性能差

• 随机性：UUID 是无序的，每次插入新数据时，新记录可能会插入到索引树的任意位置，导致索引树频繁调整。

• 页分裂：InnoDB 存储引擎使用 B+ 树作为索引结构，随机插入会导致页分裂，增加磁盘 I/O 操作。

3. 查询性能差

• 比较效率低：字符串比较比整型比较慢，尤其是在大表中，查询性能会显著下降。

• 索引扫描范围大：UUID 索引占用的空间大，导致索引扫描的范围更大，查询效率降低。

---

2. 修改数据导致索引刷新的原因

（1）索引的作用

• 索引是为了加速查询而创建的数据结构（如 B+ 树）。

• 当数据被修改时，索引也需要同步更新，以保持数据的一致性。

（2）修改数据对索引的影响

• 更新主键：

  • 如果修改了主键值，MySQL 需要删除旧的主键索引记录，并插入新的主键索引记录。

  • 这个过程会导致索引树的调整，增加磁盘 I/O 操作。

• 更新非主键列：

  • 如果修改的列是索引列（如唯一索引、普通索引），MySQL 需要更新对应的索引记录。

  • 这个过程也会导致索引树的调整。

（3）UUID 主键的额外开销

• 由于 UUID 是无序的，修改主键值时，新值可能会插入到索引树的不同位置，导致索引树频繁调整。

• 相比于有序的主键（如自增 ID），UUID 主键的修改操作代价更高。

---

3. 字符主键导致效率降低的原因

（1）存储空间大

• 字符主键（如 UUID）占用的存储空间比整型主键大。

• 索引的大小直接影响查询性能，索引越大，查询时需要的磁盘 I/O 操作越多。

（2）比较效率低

• 字符串比较比整型比较慢，尤其是在大表中，查询性能会显著下降。

• 例如，WHERE id = '550e8400-e29b-41d4-a716-446655440000' 的效率低于 WHERE id = 12345。

（3）索引分裂

• 字符主键通常是无序的，插入新数据时，可能会导致索引树频繁分裂和重新平衡，影响性能。

---

4. 如何优化 UUID 主键的性能

（1）使用有序 UUID

• 使用有序 UUID（如 UUIDv7），减少索引分裂和页分裂。

• 有序 UUID 的生成方式可以基于时间戳，保证插入顺序。

（2）将 UUID 存储为二进制

• 将 UUID 存储为 BINARY(16) 而不是 CHAR(36)，减少存储空间。

  sql 代码解读复制代码CREATE TABLE users (
      id BINARY(16) PRIMARY KEY,
      name VARCHAR(255)
  );
  

（3）使用自增主键 + UUID

• 使用自增主键作为物理主键，UUID 作为逻辑主键。

  sql 代码解读复制代码CREATE TABLE users (
      id BIGINT AUTO_INCREMENT PRIMARY KEY,
      uuid CHAR(36) UNIQUE,
      name VARCHAR(255)
  );
  

（4）分区表

• 对大表进行分区，减少单个索引树的大小，提高查询性能。

---

~Summary

• UUID 作为主键的缺点：

  • 索引效率低，插入和查询性能差。

  • 修改数据时，索引需要频繁刷新，导致性能下降。

• 字符主键效率低的原因：

  • 存储空间大，比较效率低，索引分裂频繁。

• 优化建议：

  • 使用有序 UUID 或二进制存储。

  • 结合自增主键和 UUID。

  • 对大表进行分区。