主页 / dba / 问题 / 264
Accepted
BrunoLM
Asked: 2011-01-05 23:46:34 +0800 CST

Guid vs INT - 哪个更好作为主键？

  • 772

我一直在阅读使用或不使用Guid和int.

int更小，更快，易于记忆，保持时间顺序。至于Guid，我发现的唯一优势是它是独一无二的。在哪种情况下 aGuid会比 a 更好int，为什么？

从我所见，int除了数量限制之外没有任何缺陷，这在许多情况下是无关紧要的。

究竟为何而Guid生？我实际上认为它除了作为简单表的主键之外还有其他用途。（有什么真正的应用程序使用Guid的例子吗？）

( Guid = UniqueIdentifier ) SQL Server 上的类型

sql-server performance

6 个回答

  1. Best Answer

    此处和此处的 Stack Overflow 中已对此进行了询问。

    Jeff 的帖子解释了很多关于使用 GUID 的优缺点。

    GUID 优点

    • 每个表、每个数据库和每个服务器都是唯一的
    • 允许轻松合并来自不同数据库的记录
    • 允许跨多个服务器轻松分布数据库
    • 您可以在任何地方生成 ID，而不必往返于数据库，除非需要部分顺序（即使用newsequentialid()）
    • 大多数复制方案无论如何都需要 GUID 列

    GUID 缺点

    • 它比传统的 4 字节索引值大 4 倍；如果您不小心，这可能会对性能和存储产生严重影响
    • 调试繁琐 ( where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
    • 生成的 GUID 应该部分顺序以获得最佳性能（例如，newsequentialid()在 SQL Server 2005+ 上）并启用聚集索引

    如果您确定性能并且不打算复制或合并记录，请使用int，并将其设置为自动增量（SQL Server 中的标识种子）。

    • 135

  2. 我成功地使用了混合方法。表同时包含一个自增主键整数id列和一个guid列。guid可根据需要用于对行进行全局唯一标识，并可用于行的id查询、排序和人工识别。

    id 标识此表中的行。GUID（至少在理论上）在已知宇宙中的任何位置标识此行。在我的项目中，每个 Android 手机在本地 SQLite 数据库上都有一个结构相同的表副本。该行及其 GUID 均在 Android 上生成。然后，当 Android 同步到后端数据库时，其本地行将写入后端表，而不必担心与从任何其他 Android 手机创建的行发生冲突。

    • 35

  3. 如果您将数据与外部源同步，则持久 GUID 会好得多。我们使用 GUID 的一个简单示例是发送给客户的工具，用于抓取他们的网络并执行某些类别的自动发现，存储找到的记录，然后将所有客户记录集成到中央数据库中回到我们这边。如果我们使用一个整数，我们将有 7,398 个“1”，并且很难跟踪哪个“1”是哪个。

    • 25

  4. 使用自动增量 ID 可能会泄露有关您的业务活动的信息。如果您正在经营一家商店并用于order_id公开识别购买，那么任何人都可以通过简单的算术找出您每月的销售额。

    • 18

  5. rmir​​abelle的答案就是我所做的。但是，对于更大规模的项目，有一个终极设计，两者都可以使用：

    用途：键映射表

    TableA.ID 在您的数据库中本地用作主键，以及用于 JOINing 的键。TableAMap.ID 与TableA.ID 相同，TableAMap.UniversalID 仅用于系统间。

    TableA

- ID int (PK)
- Data varchar(100)

TableAMap

- ID int (PK)
- UniversalID GUID (Indexed - nonclustered)

    数据库复制/导入/导出很少需要 GUID。因此，与其将 GUID 放在主表上，它每行占用额外的 8 个字节，并且 GUID 索引将（默认情况下）存储在同一卷上；一个单独的表（又名规范化）来拯救。

    使用单独的表，您的 DBA 可以自由地将其存储在另一个较慢的磁盘上。此外，如果仅某些批处理作业需要 GUID，您可以在需要它之前创建 GUID 索引，然后将其删除。

    此外，当然可以简单地将 UniversalID 添加到 TableA，而不是添加诸如 TableAMap 之类的扩展表。

    • 4

  6. 我在这个线程上看到了很多关于随机 GUID 和 NEWSEQUENTIALID() 之类的典型答案。是的，我同意任何形式的 GUID 都很大，但这确实是他们唯一的问题。我会告诉你，随机 GUID 并不是它们被“证明”的碎片问题。在您所见过的关于 SQL Server 的最异端介绍中，我证明了随机 GUID 碎片实际上是一个因测试不足和错误信息而长期存在的神话。事实证明他们不是问题...我们是问题！

    总结一下如何防止数百万插入的 GUID 碎片......

    1. 由于分布均匀，当您达到大约 1% 的碎片时，您将在几乎所有页面上的表中同时发生大量碎片。当您超过 1% 的逻辑碎片时，您必须采取措施。

    2. 您需要采取的措施是在填充因子上方创建可用空间。这意味着您不能使用 REORGANIZE，因为它无法创建额外的页面来分散索引以使可用空间高于填充因子。事实上，REORGANIZE COMPACTS pages up to the Fill Factor。换句话说，它尽最大努力在最坏的时间尽可能多地删除可用空间。相反，您必须改用 REBUILD。

    3. 事实还证明，由于压缩，REORGANIZE 实际上会导致并延续碎片。事实证明，实际上最好不要做任何索引维护，而不是做错，而 REORGANIZE 所做的索引压缩完全错误，因为它无法在填充因子之上创建可用空间来停止碎片。如果您是 24/7 或使用无法在线重建的标准版，请尽可能等待维护期。

    4. 此外，REORGANIZE 被宣传为比 REBUILD 占用更少的资源。这实际上是不正确的，尤其是当您降低填充因子以防止即使在非 GUID 索引上出现碎片时。

    我同意，由于我们多年来所接受的教育，这一切似乎都是不可能的。这是我制作的演示文稿的最后一张幻灯片，它显示了 GUID 聚集索引的一年历史（参见图例），使用预排序的 GUID 作为不断增加的基线，没有碎片，没有索引维护的随机 GUID，以及具有 3 个不同的随机 GUID以每天 100 千行的插入速率使用 1%“低阈值”重建的填充因子。

    “公寓是几乎没有发生碎片化的地方

    这是一张显示 REORGANIZE 对日志文件有多糟糕的幻灯片。红线是所谓的“最佳实践”线，图表最底部的小绿线是 1%“低阈值”重建线。

    REORGANIZE 和“低阈值”REBUILD 之间的资源使用比较

    如果你想看演示，请看下面的视频，我在其中打破了随机 GUID 碎片的神话，并浪费了世界上 98% 的人在过去 22 年错误使用的所谓“最佳实践”索引维护年。然后，还要了解有关索引维护的经验教训适用于其他类型的索引。

    这是视频链接。作为对那些戴着耳机的人的警告，他们在 15:00、30:15 和 45:25 时间戳插入了一些相当突然发生且响亮的广告，以“支付账单”以保持 GROUPBY.org 的运行。

    这是链接。

    Black Arts Index Maintenance 1.2 - Guids vs. Fragmentation

    • 4

相关问题