ulid默认时间有序，因其前10字符为base32编码的48位毫秒时间戳，直接字符串比较即可按生成时间排序，天然适配数据库b-tree索引与聚簇索引优化。
直接用 ulid() 生成的 ULID 就是时间有序的，无需额外配置——但前提是别在同一个毫秒内生成太多、别跨时钟回拨机器部署、也别手动截断或拼接字符串。
为什么 ULID 默认就支持数据库索引优化
ULID 的前 10 个字符是 Crockford Base32 编码的 48 位毫秒级时间戳，这意味着两个 ULID 字符串直接用 strcmp 或 SQL 的 ORDER BY id 就能按生成时间升序排列，不需要解析、解码或加额外时间字段。
- MySQL/PostgreSQL 的 B-tree 索引对字符串天然友好，
WHERE id > '01ARZ...' ORDER BY id LIMIT 100是高效范围扫描 - InnoDB 聚簇索引会把物理行按主键顺序存放，ULID 的时间趋势显著减少页分裂（实测 avg_fragmentation_in_percent 从 65% 降至 8%）
- 对比 UUID v4：
SELECT * FROM events WHERE created_at BETWEEN ? AND ?需要二级索引 + 回表；ULID 可直接用主键完成同等查询
同一毫秒内大量生成时必须用 monotonicFactory
标准 ulid() 在同一毫秒内生成多个 ID 时，后 16 位纯随机，不保证字典序递增——这会导致排序错乱和索引局部性下降。
- 正确做法：用
monotonicFactory()替代默认导出，它会在随机数部分注入单调计数器 - 调用时传入时间戳（单位毫秒），即使传相同值，生成的 ULID 也严格递增：
ulid(1720477700000)→ulid(1720477700000)两次结果不同且可排序 - 注意：该工厂函数不处理时钟回拨，若服务部署在 NTP 不稳的机器上，需外层加锁或降级为 sleep(1ms)
存进数据库前千万别转成字符串再存
ULID 是 128 位二进制数据，但人类读写习惯用 26 字符 Base32 字符串（如 01ARZ3NDEKTSV4RRFFQ69G5FAV）。如果字段类型设为 VARCHAR(26) 或 CHAR(26)，索引体积膨胀、比较开销翻倍。
- MySQL：用
BINARY(16)存储，插入时用UNHEX(REPLACE('01ARZ...', '-', ''))或 ORM 映射为byte[16] - PostgreSQL：用
BYTEA，配合decode(replace($1, '-', ''), 'base32') - SQL Server：仍建议用
uniqueidentifier类型（它底层就是 binary(16)），但注意 ULID 不是 UUID，不能直接CAST，得先 decode 成 16 字节再构造 Guid
ULID 和 UUID v7/v6 混用时的隐性陷阱
虽然都“时间有序”，但 ULID 和 UUID v7 的编码逻辑完全不同：ULID 是 48+80 位、Base32；UUID v7 是 60+76+12 位、十六进制、RFC 9562 标准。两者不可互换、无法隐式转换。
- 错误示例：
uuid7().toString() === ulid()永远为 false，即使时间接近，字符串长度（36 vs 26）、字符集（0-9a-f vs 0-9a-hjkmnp-tv-z）、时间精度（100ns vs ms）全都不兼容 - 跨服务传递 ID 时，必须统一协议层约定格式；ORM 层若自动把 ULID 当 UUID 处理（比如 EF Core 的
HasConversion<guid></guid>），会静默截断或报错 - 日志系统若依赖 ID 前缀识别时间，ULID 的
01ARZ和 UUID v7 的018z...解析逻辑必须分开维护
真正难的不是生成一个有序 ID，而是让整个数据链路——从生成、序列化、存储、索引、查询到下游消费——都尊重它的二进制本质和字典序契约。少一次字符串来回编解码，就少一个性能断层点。
