标签: uniqueidentifier

我们正在设计一个众所周知的读取量大的系统（每分钟读取数万次）。

• 有一个表names作为一种中央注册表。每行都有一个text字段representation和一个唯一的字段，key它是该字段的 MD5 哈希值representation。¹该表目前有数千万条记录，预计在应用程序的生命周期内会增长到数十亿条。
• 还有许多其他表（具有高度变化的模式和记录计数）引用该names表。这些表之一中的任何给定记录都保证有一个name_key，它在功能上是names表的外键。

_{1：顺便说一句，正如您所料，此表中的记录一旦写入便不可变。}

对于表以外的任何给定表names，最常见的查询将遵循以下模式：

SELECT list, of, fields 
FROM table 
WHERE name_key IN (md5a, md5b, md5c...);

我想优化读取性能。我怀疑我的第一站应该是最小化索引的大小（尽管我不介意在那里被证明是错误的）。

问题：和列
的最佳数据类型是什么？ 有理由使用over吗？或者？keyname_key
hex(32)bit(128)BTREEGIN

由于各种原因，从日志记录到延迟关联，我已经在我的系统中使用 UUID 有一段时间了。当我变得不那么天真时，我使用的格式发生了变化：

1. VARCHAR(255)
2. VARCHAR(36)
3. CHAR(36)
4. BINARY(16)

当我到达最后一个时BINARY(16)，我开始将性能与基本的自动增量整数进行比较。测试和结果如下所示，但如果你只是想总结，表示INT AUTOINCREMENT和BINARY(16) RANDOM对数据相同的性能范围高达20万（该数据库已预先填充之前测试）。

我最初对使用 UUID 作为主键持怀疑态度，事实上我仍然如此，但是我看到这里有潜力创建一个可以同时使用两者的灵活数据库。尽管许多人强调两者的优点，但使用这两种数据类型抵消了哪些缺点？

• PRIMARY INT
• UNIQUE BINARY(16)

此类设置的用例将是表间关系的传统主键，唯一标识符用于系统间关系。

我本质上试图发现的是两种方法之间的效率差异。除了使用的四倍磁盘空间（在添加额外数据后可能在很大程度上可以忽略不计）之外，在我看来它们是相同的。

架构：

-- phpMyAdmin SQL Dump
-- version 4.0.10deb1
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Generation Time: Sep 22, 2015 at 10:54 AM
-- Server version: 5.5.44-0ubuntu0.14.04.1
-- PHP Version: 5.5.29-1+deb.sury.org~trusty+3

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";


/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 …

我的一位同事给我发了一个有趣的问题，我无法完全解释。

他运行了一些代码（包括在下面）并从中得到了一些意想不到的结果。

本质上，当将 a UniqueIdentifier（Guid从这里开始我将称之为）转换为 a binary(or varbinary) 类型时，结果的前半部分的顺序是倒序的，但后半部分不是。

我的第一个想法是系统的字节序是原因，并且Guid保留了显示，但binary不能保证形式。

显然这是一个实现细节，但我想知道是否有一个很好的解释。

代码：

declare @guid uniqueidentifier = '8A737954-CBEC-40CE-A534-2AFFB5A0E207';
declare @binary binary(16) = (select convert(binary(16), @guid));
select @guid as [GUID], @binary as [Binary];

结果：

GUID                                 Binary
8A737954-CBEC-40CE-A534-2AFFB5A0E207 0x5479738AECCBCE40A5342AFFB5A0E207

如您所见，每个部分的前半部分Guid（一直到40CE）是向后存储的。也就是说，the的第一部分是向后的，然后是第二部分，然后是第三部分，但是这些部分的顺序是保留的。之后，最后两个部分按照它们在.GuidGuid

declare @guid_to_binary table
(
    [id] int identity(1,1),
    [guid] uniqueidentifier,
    [binary_conversion] binary(16)
);
declare @i int = 1;
while @i <= 100
begin
    insert into …