GUID 存储在 varchar 字段中

Question

我继承了几个使用 GUID 作为 PK 的数据库。并非所有数据类型都是唯一标识符，大多数是 varchar(50) 和一些 varchar(100)。字段是真正的 GUID，有些是由

myID = 'xxx'+convert(varchar(40),newID())

总的来说有点乱

此设计对性能有何影响？是否值得重新处理表以转换数据类型。表通常约为 1/2 M 记录，其中有几个表在 2-4M 记录范围内。

这个问题的推动力是我正在尝试（不成功）优化一个连接 24 个表和视图的过程，而服务器处理得不好。

感谢您的任何见解

Answer 1

一般来说，使用长聚集索引键不是一个好主意。为此，键是否由几个短列或几个长列组成并不重要。这使得每个索引的维护以及该表上每个索引的读取访问都变得更加昂贵。由于 PK 默认情况下由聚集索引强制执行，因此您很可能有一个非常长的聚集索引键。

一般来说，让聚集索引键单调递增也是一个好主意。由于您的列是根据 NEWID 进行评估的，因此它将在整个表中分布新行，从而导致碎片。超长的钥匙会让情况变得更糟。

最后，一般来说，最好不要花太多时间预先调整性能。如果您进行新的开发，请遵循最佳实践（如上面的两个建议）。使用现有软件，只修复那些令人头疼的问题。

现在看来你已经头痛了。因此，我首先将这些主键迁移到标识列（首选）或默认为 newsequentialid() 的 uniqueidentifier 列。

但如果您不能停机，那么这将是一个困难的改变。在这种情况下，我将首先添加新索引来支持您当前最头痛的问题（阅读：存储过程）。然后再努力清理混乱。