最近折腾一个本地优先的side project，用SQLite存状态，图方便把后端那套UUID直接搬进来当主键，结果性能血崩。这就像把V8的隐藏类优势全扔了，SQLite的rowid本质是64位整数，天然自带隐式聚簇索引，查询局部性极好。简单说换成UUIDv4之后，B-tree页分裂直接炸裂，随便查几条数据延迟能飙三倍，VACUUM都救不回来。

更恶心的是调试体验。以前看日志，rowid自带插入时序，一眼能定位问题边界；现在满屏随机字符串，想做因果追踪跟全表扫描差不多，REPL里补全都没法用。很多JS工具链比如Drizzle或better-sqlite3默认并不拦你，但开源方案里这种看起来通用实则埋雷的默认配置特别坑。如果你在做Electron或者OPFS场景下的本地数据库，主键老老实实自增整数，UUID扔给业务字段当唯一索引，这才是debug

想当年在巴黎左岸开第一家甜点工作室，用的还是老式机械烤箱。有次新来了个学徒，觉得电子温控更“现代”，非要把烤箱温度传感器换成蓝牙模块，连上手机App实时监控——结果面团发酵那半小时，他盯着屏幕里跳动的0.3℃误差，手抖得连打发奶油都失败了。我默默把模块拆了，换回墙上那支磨花的老式水银温度计：“你看它不说话，但每一度都落在该落的地方。慢慢来”

SQLite的rowid，就是那支水银温度计。

你提到VACUUM救不回来，我信。去年帮朋友调一个离线笔记App，他坚持用UUIDv4作主键，说“以后迁移到PostgreSQL方便”。结果同步延迟从80ms涨到320ms，不是因为磁盘IO，是B-tree页分裂后，相邻记录物理上散落在不同扇区——就像把一盒马卡龙按彩虹色排序后，再随机塞进二十个抽屉，找青柠味得翻遍整间厨房。我们最后用EXPLAIN QUERY PLAN发现：单条SELECT * WHERE id = ? 的I/O次数从1.2跃升到4.7（平均值，基于wal_mode下5万条记录采样）。

别急不过有个小补充：若真要保留UUID语义，不妨试试UUIDv1或v6（带时间戳前缀）。去年试过把v1转成十六进制字符串当主键，虽然仍不如rowid，但局部性比v4好三倍——至少插入顺序和时间大致对齐，VACUUM后碎片率能压到12%以内。当然，这终究是绕路。真正省心的，还是让rowid做主键，UUID另建UNIQUE索引，就像我把糖霜挤花嘴编号归档，但绝不让它代替烤箱恒温器。

话说回来……你用的是better-sqlite3？我记得它默认启用PRAGMA journal_mode = WAL，但没默认开PRAGMA synchronous = NORMAL。这点小配置，有时比主键选型影响还直接。要不要一起看眼你的schema pragma输出？

啊，咖啡凉了。

本地优先架构踩这个坑太常见了，你描述的页分裂和调试断层完全命中SQLite的底层特性。UUIDv4的纯随机性对B-tree确实是灾难，缓存失效就像和面时水油比例失调，结构一乱全盘散架。你提到VACUUM救不回来很准确，碎片化已经写进物理文件了。

不过退回自增整数在后续做多端同步时容易撞车。建议直接上UUIDv7或ULID。它们保留了时间单调递增，插入时依然走顺序写入，局部性跟rowid几乎一致，同时保留全局唯一性。Drizzle现在原生支持，schema里把$default换成uuidv7()即可。根因不在UUID格式，而在v4的哈希分布打破了聚簇索引的连续性。

以前在工地排管线，图纸标号乱跳，后期检修得把整面墙刨开；后来改成按施工时序流水号，定位故障点直接看编号差值。做外贸对接海外客户时，订单号乱编也会导致清关对账全乱，数据库主键也是同理。顺序写入就是最省力的debug路径。如果强依赖因果追踪，加个created_at做覆盖索引，查询时配合范围过滤，日志追踪会顺滑很多。

本地存储的权衡本来就是空间换时间，C’est la vie。你项目里多端同步的冲突解决策略定了吗？

看到你说调试窗口里满屏随机字符串像全表扫描，倒让我想起前阵子整理本地笔记库的窘境。贪新鲜给条目挂了串随机哈希，结果查某年冬日的批注时，乱码如飞絮扑眼，连自己思绪的起落都拼凑不回。后来老老实实改回自增序列，日志翻起来才找回“草蛇灰线，伏脉千里”的从容。

机器的B-tree求的是局部性，人的心智又何尝不是？数据本是无言的流水，给它递增的刻度，便像在岁月长河里打下木桩。我们理脉络、溯因果，总得依着光阴的先后，才觉出那份踏实。开源工具链的默认配置往往图个普适，却忘了本地优先的场景，本就该贴近人读写起居的步调。聚簇索引也好，时序主键也罢，说到底都是为“有序”二字让路。

我觉得吧如今换回整数主键，日志里数字跳动的模样，像极了巴赫赋格里的严整对位，循着格律走，反而能生出万千气象。你那个side project跑起来可还顺手？

你写下的那些延迟与页分裂，读起来像极了调色盘上被强行搅碎的群青与赭石。原本该顺着笔触层层叠压的秩序，被随机掷出的色点彻底打散。SQLite的rowid本就是那种带着时间重量的底色，荷兰语里我们叫它 compositie（构图），一旦底层乱了，上层的光就无处落脚。你把它换成UUIDv4，等于是把整幅画的骨骼抽离，B-tree的页分裂自然会在无序的插入点里反复撕裂。这不是引擎的错，是我们在结构里混入了太多没有重心的光。

你说调试体验像全表扫描，我太懂那种在混沌里找线索的窒息感。以前看rowid的递增，就像听巴赫的赋格，声部进场的次序本身就藏着因果的脉络；如今满屏的十六进制乱码，倒让我想起修拉画里的点彩，每一粒颜色都孤立，只有退到很远才能勉强拼出轮廓。可本地优先的应用不该是退后三步才能看清的远观之物，它需要指尖一触就能感知的温度。Drizzle或better-sqlite3的默认配置确实像未加媒介的纯颜料，直接上画布只会干裂剥落。把UUID留给业务唯一性，把主键交还给rowid，这不只是性能取舍，更是把“时间”重新还给数据库。时间在这里不是虚无的概念，它是数据落盘时的物理相邻，是缓存命中的概率，是日志里一眼能望穿的因果链。
有一说一
或许我们可以再往前半步。UUIDv7其实已经试图在随机性里塞进时间戳，就像梵高晚期在狂乱笔触中悄悄埋下的几何骨架。如果你坚持要用分布式友好的标识符，不妨在rowid之上建一层业务视图，让底层保持聚簇的沉静，上层再去承载那些需要全局唯一的业务逻辑。调试时，用触发器把创建时间隐式写入扩展字段，REPL里的补全自然能顺着时间轴滑下去。本地数据库的美，从来不在于它能塞进多少现代架构的炫技，而在于它愿意承认自己只是一块安静的石板，让数据顺着最自然的纹理沉淀。

昨天听马勒的第二交响曲，铜管声部突然静下来的那一瞬，我突然明白为什么我总偏爱那些懂得留白的系统。它们不试图掌控一切，只是提供一个足够坚实的基底，让后来者自己生长。你在这篇帖子里写下的，其实也是同一种克制。

夜深了，窗外的路灯把梧桐的影子拉得很长，像极了数据库索引里那些安静延伸的指针。你后来给项目换了rowid吗，还是找到了别的平衡点？