过了一会儿，我的系统管理员错误地将我的数据库恢复到了更早的时间点。
3 小时后，我们注意到了这一点，在此期间创建了 80 个新行（auto increment 具有外键依赖性）。
因此，此时我们在需要合并的两个表中有 80 个具有相同 ID 的不同客户。
我不记得我们是如何解决这个问题的，但花了很长时间。
现在，我正在设计一个新数据库，我的第一个想法是使用 GUID 索引，尽管这种用例很少见。
我的问题：你的ID这么长的字符串怎么处理？
我的意思是，当 2 个程序员在谈论一个客户时，可以说：
“嘿。我们遇到了客户端 874454 的问题”。
但是您如何使用 GUID 保持简单，这确实是一个可能导致一些麻烦和通信中断的问题。
谢谢
【问题讨论】：
标签： database guid auto-increment
如果您不使用复制，GUID 会产生比它们解决的问题更多的问题。首先，您需要确保它们不是聚集索引（至少这是 SQL Server 中 PK 的默认设置），因为您确实会降低插入性能。其次，它们比整数长，因此不仅占用更多空间，而且使连接速度变慢。每个查询中的每个联接。
你将创造一个更大的问题来试图解决一个罕见的问题。而是想办法进行设置，这样您就不会花费数小时从错误中恢复过来。
您可以创建一个审计解决方案。这样你就可以轻松地从各种失误中恢复过来。并提前编写代码进行恢复。然后在出现问题时相对容易修复。坦率地说，我绝不会允许在没有某种形式的审计的情况下设置包含公司关键数据的数据库。不这样做太危险了。
或者您甚至可以准备一个脚本来将记录移动到一个临时位置，然后用新的身份重新插入它们（并将子记录上的身份更新为新的身份）。您这样做了一次，dba 应该已经创建了一个脚本（并将其放在源代码管理中），以便下次您需要进行类似的修复时可以使用它。如果您的 dba 如此无能，他不会创建和保存此类脚本，那么请摆脱他并聘请知道他在做什么的人。
【讨论】：
在大多数视图中只显示一个前缀。这就是 DVCS 所做的，因为它们中的大多数通过十六进制编码的哈希来识别大多数对象。
（OTOH，我知道在许多圈子中使用 UUID 作为主键很流行；但要说服我，需要的远不止一些可怕的故事）
【讨论】：