Thunderbolt最小索引策略为什么同步服务端不建外键也不建二级索引【免费下载链接】thunderboltAI You Control: Choose your models. Own your data. Eliminate vendor lock-in.项目地址: https://gitcode.com/GitHub_Trending/thund/thunderboltThunderbolt 是一款「AI You Control」的多端 AI 助手你可以自由选择模型、数据归自己所有、摆脱供应商锁定。它的多设备同步由 PowerSync 驱动而服务端数据库的最小索引策略正是这套同步架构能够又快又稳的关键——服务端不建外键、不建二级索引只保留主键和user_id索引。先看架构服务端只是一个“同步中转站”Thunderbolt 的同步链路是这样的每个设备桌面端、手机、浏览器都持有一个本地SQLite数据库所有读写都先落到本地 SQLite保证离线也能飞快响应PowerSync同步服务在 SQLite 与后端PostgreSQL之间流式传输增量数据客户端的写入通过PUT /v1/powersync/upload上传后端在 PostgreSQL 事务中应用。关键点在于重查询都发生在客户端的 SQLite 上而不是后端 PostgreSQL 上。后端只承担“收写、存行、按用户推增量”的职责。这个定位直接决定了它的索引哲学。最小索引策略只保留两类索引翻看后端的 PowerSync 表定义 backend/src/db/powersync-schema.ts你会发现每张表的索引都非常“克制”规律高度一致保留的索引原因主键复合主键或单列id唯一性约束同步 upsert 的基础每表一个user_id索引PowerSync 同步规则全靠WHERE user_id ?过滤数据❌ 外键约束不建❌ 二级/查询优化索引不建❌ 软删除、active 状态索引不建❌ 加密列上的索引不建以 settings 表为例索引定义就是复合主键(key, user_id)加一个idx_settings_user_idchat_threads、chat_messages 等表则只有单列主键加user_id索引。完整规则写在 docs/architecture/multi-device-sync.md 的 “Indexing Strategy” 一节。为什么不建外键你可能会想chat_messages有thread_id、model_id为什么不加外键保证引用完整项目文档 docs/architecture/composite-primary-keys-and-default-data.md 给出了四条理由架构定位后端数据库是同步服务器不是查询引擎。JOIN 和关系维护都在前端 SQLite 完成后端强制外键收益极小端到端加密Thunderbolt 支持零知识 E2EE见 docs/architecture/e2e-encryption.md服务端存的多半是密文根本无法在密文上做有意义的关系校验写入性能外键检查会给每次 INSERT/UPDATE 增加开销而同步场景恰恰是高频写入同步弹性允许客户端数据在关系暂时不一致时比如部分同步中途也能顺利上传避免整批操作被拒绝。实际代码里像modelId这类字段就是一个普通文本列不带.references()也不建复合外键约束。为什么不建二级索引传统业务库习惯“每个查询条件都配一个索引”但在同步服务端这么做是负优化每个索引都在拖慢写入。同步期间大量 INSERT/UPDATE/DELETE索引越多每次变更要维护的 B-Tree 越多用不上。没有 JOIN、没有复杂过滤在服务端执行二级索引建了也白建加密列上索引毫无意义你无法在密文上过滤或搜索存储成本白白增加。唯一的“例外”是user_id索引——它不是为业务查询服务的而是因为 PowerSync 的每条同步规则形如SELECT * FROM powersync.chat_threads WHERE user_id bucket.user_id可对照 powersync-service/config/config.yaml 中的 sync_rules没有这个索引同步规则的扫描就会退化为全表扫描。所以user_id索引是“必需”其余都是“多余”。复合主键最小策略的另一半这套策略还配合了复合主键设计settings、models、tasks、prompts、model_profiles等“默认数据”表使用(id, user_id)或(key, user_id)作为主键让每个用户都能拥有同名的默认行比如人人都有的openai-gpt-4o模型配置。而chat_threads、chat_messages等用户自建数据表每行 ID 全局唯一用单列id主键即可。表清单见 shared/powersync-tables.ts——它是前后端与同步规则共同的单一事实来源。主键天然自带索引复合主键 user_id索引恰好覆盖了同步所需的全部访问路径这正是“最小”的精髓只索引同步真正会访问的列。这套策略带来的收益✨写入更快更少的索引维护意味着上传/应用操作的事务更短、更稳️加密友好服务端只存行与密文不为它建任何“假装有用”的索引存储更省每个少掉的索引都是省下来的空间和写放大同步更弹性无外键约束客户端队列可以在关系暂不一致时继续排空不被 400 卡死。一句话总结Thunderbolt 把“重查询”留在设备本地的 SQLite把服务端还原成一个极简、高速、对加密数据透明的同步中枢——不建外键、不建二级索引不是偷懒而是刻意为同步场景做的减法。延伸阅读composite-primary-keys-and-default-data.md、multi-device-sync.md、powersync-account-devices.md【免费下载链接】thunderboltAI You Control: Choose your models. Own your data. Eliminate vendor lock-in.项目地址: https://gitcode.com/GitHub_Trending/thund/thunderbolt创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考