Sdcb Chats 技术博客：数据库 ID 选型的曲折之路 - 从 Guid 到自增 ID，再到 Guid
原文中文，约12900字，阅读约需31分钟。
📝
内容提要
Sdcb Chats 项目在主键选择上经历了从 Guid、自增 ID、加密 ID 到再次回归 Guid 的演变，体现了性能、安全与用户体验之间的权衡，反映了技术选型的复杂性与迭代的重要性。
🔎
延伸解读
技术选型的复杂性
Sdcb Chats 项目的 ID 选型经历了多次迭代，反映了在性能、安全性和用户体验之间的权衡。开发者在选择主键时需考虑具体应用场景，避免盲目跟风。每种方案都有其优缺点，需根据实际需求灵活调整。
数据迁移的挑战
从 Guid 迁移到自增 ID 的过程并非简单，涉及复杂的数据迁移脚本和外键关联的更新。开发者需确保数据一致性和完整性，避免在迁移过程中引入新的问题。这一过程强调了对技术债务的重视和及时解决的重要性。
安全性与用户体验的平衡
在展示 ID 时，Sdcb Chats 选择对自增 ID 进行加密，以提升安全性和用户体验。加密后的 ID 既能防止恶意猜测，又符合用户对现代应用的期望。这一决策展示了在技术实现中，安全性与用户感知之间的微妙平衡。
❓
Q&A
Sdcb Chats 项目在主键选择上经历了哪些阶段？
Sdcb Chats 项目经历了从 Guid、自增 ID、加密 ID 到再次回归 Guid 的演变。
为什么最初选择 Guid 作为主键？
因为 Guid 具有全局唯一性，适合在分布式系统中使用，避免 ID 冲突。
迁移到自增 ID 后有哪些性能提升？
自增 ID 提供了更小的索引尺寸和更快的查询速度，减少了索引碎片。
在迁移过程中遇到了哪些挑战？
最大的挑战是数据迁移的复杂性，需要确保数据的一致性和完整性。
为什么选择对界面显示的 ID 进行加密？
为了提升安全性，避免用户通过 URL 猜测其他聊天会话，同时改善用户体验。
最终为什么决定将加密后的 ID 显示为 Guid 格式？
因为 Guid 格式的 ID 更符合用户对现代应用的认知，同时避免了直接暴露自增 ID 的问题。
🏷️
