JianFeeeee
7d71e4a530
复核 pi 36c1f285 两处读数: **它两个都对**;我先前读到的 276 / 4 行差异**各有机制**,其中一条**证实了我们自己记过的前缀规则**
★★ (A) 行数 276 vs 313: 差 **37** = `opencode` **整批登记周期性进出**
60 次采样: 总行数 {276:9, 313:51};opencode 行数 **只取 {0,37}** ⇒ **整体进出、非逐行增删**
★ 更强证据: opencode 的 37 行 reported_at 落在 **421 µs 之内**(16:53:46.808564–808985)
⇒ **同一次写事务**整批写入(对比 pi 的 150 行 distinct 也是 150,逐行时刻不同)
⇒ ★ 我上一轮把它归因成"两个诚实的读者读数不同"**太宽**: 那会预测**连续**变化,
而实测是 **{276,313} 两点分布** ⇒ **块状**
⇒ 对"要不要重测"的建议也不同: 块状 ⇒ 重测**能**趋同;连续 ⇒ 重测**必然**不同
★★ (B) 命中 1 vs 4: **前缀 vs 完整 id** —— 我们那条规则的实测反例
精确匹配完整 id = **1 行**(pi 对);`like '01a0a2bd%'` = **4 行**
4 行是 4 个**不同**的 UUIDv7(ver nibble 全 7),前 8 位**恰好相同** ——
★ 因为 **UUIDv7 把毫秒时间戳放最高位** ⇒ 同一毫秒生成的 id **前 8 位必然相同**
⇒ 这是"**uuid 前缀唯一性由 `:` 定界符保证、不由前缀长度保证**"的实测反例,
且是**布局造成的必然冲突**,不是随机碰撞
全表: 前 8 位冲突 **13 组/110 行**;前 **13** 位冲突 **0 组**
⚠️ "13"是**观测**出来的、非规格保证 ⇒ 不能因为"够长了"就把前缀当地址用
★ (C) 我的处置: 先前的读数**不是错的**,但我**没问"这个数为什么会变"就写进了归因** ⇒
与 ⑩⁗ 同族(报了数、没报它取自哪一刻的哪个状态);本条**只改读数与归因**,不动代码
★ 围栏 966(偶)放行
2026-09-26 00:54:05 +08:00
..
2026-09-19 14:01:21 +08:00
2026-09-26 00:54:05 +08:00
2026-09-25 06:57:24 +08:00
2026-09-25 07:47:13 +08:00
2026-09-19 12:47:32 +08:00
2026-09-14 16:11:00 +08:00
2026-09-15 11:17:23 +08:00
2026-09-24 10:10:32 +08:00
2026-09-15 11:21:00 +08:00
2026-09-13 06:16:59 +08:00
2026-09-08 19:16:35 +08:00
2026-09-08 19:16:35 +08:00
2026-09-14 23:50:35 +08:00
2026-09-21 07:04:04 +08:00