Sdcb Chats 技术博客：数据库 ID 选型的曲折之路 - 从 Guid 到自增 ID，再到 Guid
💡
原文中文，约12900字，阅读约需31分钟。
📝
内容提要
Sdcb Chats 项目在主键选择上经历了从 Guid、自增 ID、加密 ID 到再次回归 Guid 的演变，体现了性能、安全与用户体验之间的权衡，反映了技术选型的复杂性与迭代的重要性。
🎯
关键要点
- Sdcb Chats 项目在主键选择上经历了从 Guid、自增 ID、加密 ID 到再次回归 Guid 的演变。
- 项目初期选择 Guid 作为主键，因其全局唯一性和在分布式系统中的优势。
- 随着数据量增长，Guid 的性能问题逐渐显现，导致索引碎片率高。
- 为了提升性能，项目重构时迁移至自增 ID，带来了更小的索引尺寸和更快的查询速度。
- 自增 ID 减少了索引碎片，节省了存储空间，但数据迁移复杂性高。
- 完成自增 ID 迁移后，项目面临如何安全展示 ID 的问题，最初直接使用自增 ID 导致安全隐患。
- 为解决安全问题，决定对界面显示的 ID 进行加密，提升安全性和用户体验。
- 最终选择将加密后的 ID 显示为 Guid 格式，以满足用户对现代应用的认知。
- 在技术选型中，需权衡性能、安全性、用户体验和开发效率，没有一劳永逸的完美方案。
- Sdcb Chats 项目展示了开源项目的迭代与进化，强调了开放和务实的态度。
❓
延伸问答
Sdcb Chats 项目在主键选择上经历了哪些阶段？
Sdcb Chats 项目经历了从 Guid、自增 ID、加密 ID 到再次回归 Guid 的演变。
为什么最初选择 Guid 作为主键？
因为 Guid 具有全局唯一性，适合在分布式系统中使用，避免 ID 冲突。
迁移到自增 ID 后有哪些性能提升？
自增 ID 提供了更小的索引尺寸和更快的查询速度，减少了索引碎片。
在迁移过程中遇到了哪些挑战？
最大的挑战是数据迁移的复杂性，需要确保数据的一致性和完整性。
为什么选择对界面显示的 ID 进行加密？
为了提升安全性，避免用户通过 URL 猜测其他聊天会话，同时改善用户体验。
最终为什么决定将加密后的 ID 显示为 Guid 格式？
因为 Guid 格式的 ID 更符合用户对现代应用的认知，同时避免了直接暴露自增 ID 的问题。
➡️
