我目前正在集成API密钥验证，我使用一些不同的数据点（电子邮件+时间等）生成密钥到一个小的唯一（到目前为止）十字形字符串，即“ 7edbf060 ”（这是无法更改的，因为许多密钥已经消失了）我正在寻找将这些密钥转换/存储到GUID或BIGINT中以便更快地在表上进行索引/搜索，因为这将被访问大约每秒300-500x（目前每天有4000万以上的请求）因此，性能是一个很大的因素！
显然，将十六进制密钥保留为VARCHAR列并对其执行搜索效率非常低！所以我的想法是，一旦用户发送他们的密钥，我就可以将其转换为其他东西（GUID / BIGINT）并以这种方式执行我的查找。
SELECT CONVERT(uniqueidentifier, 0x7edbf060)
--output: 60F0DB7E-0000-0000-0000-000000000000
SELECT CONVERT(bigint, 0x7edbf060)
--output: 2128343136
由于密钥是非顺序生成的，因此索引必须被聚集并且将被分段，但是我有脚本可以在一天内重新对这些表进行重新签名以保持其受控制。
所以我想的是这样一个表： [GUID] （uniqueidentifier，PK，非null）， [Key] （varchar（8））， [电子邮件] （varchar（max） ））
这些是我唯一/最好的选择吗？我担心的是十六进制密钥，一旦转换为SQL中的uniqueindentifier，似乎只使用前面的8个字符后跟“-0000-0000-0000-000000000000”，一旦转换为bigint，该值已经在20亿范围内，不知道一旦有几千条记录在整个地方都有这么一个选项将会执行。
非常感谢任何帮助/建议！感谢。
答案 0 :(得分：1)
我建议您将其原生存储为二进制（4）数据类型，因为这是源数据的实际类型。二进制列可以是主键列，也可以根据需要编制索引。适当的数据类型是最适合存储的数据域的数据类型。即使是最苛刻的应用程序，数据类型性能也很少考虑。
从性能的角度来看，我希望你可以每秒实现数千个选择请求（假设返回单行），即使在适度的硬件上，只要表足够小以保留在缓冲区缓存中。只要数据在内存中，碎片也不是单例请求的考虑因素。碎片只会在影响缓冲效率时影响随机请求的性能。
对于太大而无法保留在缓冲区缓存中的表，随机密钥将需要与非缓存差异成比例的物理I / O.您需要一个能够满足随机密钥的最终I / O需求的存储子系统。
你提到搜索。如果这些需要表扫描而不是点查找，则根据表大小实现性能目标可能会有问题。指定插入速率和预期的表大小。