考虑查询性能，MySQL中存储SQL Server生成的UUID的最优方式

既然你已经明确空间维度BINARY(16)是最优解，那咱们直接聚焦查询性能的最优实现——核心思路就是：坚持用BINARY(16)存储，把字符串转二进制的工作放在Java层做，配合索引最大化查询效率。

1. 为什么BINARY(16)是性能最优的选择 #

• 索引效率更高：相同的索引页能容纳更多的BINARY(16)数据（仅16字节），远多于VARCHAR(32)（32字节+额外存储开销），减少磁盘IO次数，查询时更快定位数据。
• 比对速度更快：二进制类型的比对是直接按字节进行的，比字符串逐字符比对的效率高几个量级。

2. Java层的关键转换处理 #

因为你的Java应用中是32位十六进制字符串（比如A6D42A825114472FAF402180E20B3751），要转换成MySQL的BINARY(16)，需要注意两点：

• 基础十六进制转二进制：用成熟工具类把字符串转成字节数组，比如：

  // JDK自带工具（Java 8及以上）
  byte[] uuidBytes = javax.xml.bind.DatatypeConverter.parseHexBinary(uuidStr);
  // 或者用Guava更直观
  byte[] uuidBytes = BaseEncoding.base16().lowerCase().decode(uuidStr.toLowerCase());
  

• 字节序调整（重要！）：SQL Server的newid()生成的UUID是混合字节序（前8字节为小端序，后8字节为大端序），如果直接转二进制会和SQL Server的binary(16)不匹配。比如字符串A6D42A82-5114-472F-AF40-2180E20B3751对应的SQL Server binary(16)是0xA6D42A825114472FAF402180E20B3751，但直接解析字符串得到的字节数组前4字节为0xA6,0xD4,0x2A,0x82，而SQL Server实际存储的是0x82,0x2A,0xD4,0xA6，所以需要调整前8字节的字节序：

  public static byte[] sqlServerUuidToBytes(String uuidStr) {
      byte[] bytes = DatatypeConverter.parseHexBinary(uuidStr);
      // 调整前4组的字节序（共8字节）
      swapBytes(bytes, 0, 3);
      swapBytes(bytes, 1, 2);
      swapBytes(bytes, 4, 5);
      swapBytes(bytes, 6, 7);
      return bytes;
  }
  
  private static void swapBytes(byte[] arr, int i, int j) {
      byte temp = arr[i];
      arr[i] = arr[j];
      arr[j] = temp;
  }
  

• 插入/更新时，直接用JDBC的setBytes()方法传入转换后的字节数组，避免MySQL做字符串转二进制的额外开销。

3. 查询时的性能优化 #

• 查询前同样把Java中的字符串转换成字节数组，用参数化查询：

  String sql = "SELECT * FROM your_table WHERE uuid_column = ?";
  try (PreparedStatement pstmt = conn.prepareStatement(sql)) {
      pstmt.setBytes(1, sqlServerUuidToBytes(uuidStr));
      ResultSet rs = pstmt.executeQuery();
      // 处理查询结果
  }
  

• 给BINARY(16)列创建普通索引：

  CREATE INDEX idx_uuid ON your_table(uuid_column);
  

  这样查询时能直接走索引，避免全表扫描，性能拉满。

4. 避坑提醒 #

• 不要用VARCHAR(32)或CHAR(32)存储：空间大、索引效率低，字符串比对速度慢，完全没必要。
• 不要依赖MySQL的UNHEX()函数查询：比如WHERE uuid_column = UNHEX(?)，虽然能工作，但会导致索引失效（除非创建表达式索引，比如CREATE INDEX idx_uuid_unhex ON your_table(UNHEX(uuid_column));，但不如提前在Java层转换高效）。
• 字节序一定要调整：如果忽略这一步，存储的二进制和SQL Server的binary(16)不匹配，查询会返回空结果，踩过坑的人都懂。

内容的提问来源于stack exchange，提问作者user762421