在SQLite轻量数据库的实际项目里，不少团队为了便于后续分库合表，会直接把UUID字符串设成表的主键。这种做法在开发期看似省事，但等到数据量上涨，写入变慢、查询卡顿的问题就会暴露。本文通过一组可控的基准测试，把UUID主键和传统的整型自增主键放在同样环境下对比，并进一步分析无序标识对B树索引的真实影响。
测试环境与建表方案设计
为了排除外部干扰，所有测试都在同一台笔记本上完成，系统为Linux，SQLite版本为3.4以上，关闭了同步刷盘以外的附加日志选项。我们建立两张结构完全一致的表，一张使用INTEGER PRIMARY KEY自增字段，另一张使用TEXT类型的UUID字符串作为主键。两张表都额外带两个普通字段用来模拟业务列，避免测试只测主键本身而失去参考意义。
建表语句需要特别注意，SQLite里整型主键如果写成INTEGER PRIMARY KEY，会被优化为行记录内部的rowid别名，存储极其紧凑；而UUID主键只能以文本或二进制形式存放在普通页里。下面给出两张表的创建代码，方便读者复现：
-- 整型自增主键表 CREATE TABLE t_int ( id INTEGER PRIMARY KEY, name TEXT, created_at TEXT ); -- UUID文本主键表 CREATE TABLE t_uuid ( id TEXT PRIMARY KEY, name TEXT, created_at TEXT );
在写入测试前，我们用脚本预先生成十万条仿真数据，UUID采用标准version4随机值，整型则从一开始连续递增。这样的数据分布能够反映绝大多数业务系统的真实写入模型：UUID完全无序，整型严格有序。测试时统一使用事务批量提交，每千条提交一次，降低事务开启关闭本身带来的噪声。
写入与查询性能实测对比
批量插入阶段，整型主键表完成十万条写入仅用约一点二秒，而UUID文本主键表耗时接近四点五秒，差距接近四倍。造成这一现象的核心原因并不只是字符串比整数长，更关键的是SQLite底层使用B树组织主键索引，有序整型总是追加到最右叶子页，几乎不发生页分裂；UUID随机分布则会让新记录插入到任意已有页中间，触发大量页面重排与碎片。
点查性能同样拉开差距。我们对两张表各做五万次按主键取单行的查询，整型表平均延迟在微秒级，UUID表由于主键索引体积大、比较成本高，平均延迟高出数倍，且在低缓存环境下由于索引页无法全部驻留内存，磁盘读次数明显上升。以下为简化版的测试代码：
import sqlite3, uuid, time
conn = sqlite3.connect('test.db')
c = conn.cursor()
# 整型写入
start = time.time()
for i in range(100000):
c.execute("INSERT INTO t_int (name, created_at) VALUES (?, ?)",
(f"user{i}", "2024-01-01"))
if i % 1000 == 0:
conn.commit()
conn.commit()
print("int insert cost", time.time() - start)
# UUID写入
start = time.time()
for i in range(100000):
c.execute("INSERT INTO t_uuid (id, name, created_at) VALUES (?, ?, ?)",
(str(uuid.uuid4()), f"user{i}", "2024-01-01"))
if i % 1000 == 0:
conn.commit()
conn.commit()
print("uuid insert cost", time.time() - start)
除了绝对耗时，我们还统计了数据库文件体积。同样十万条记录，UUID文本主键表文件比整型表大约高出百分之六十，这部分膨胀主要来自更长主键以及更稀疏的索引页填充率。如果项目预期数据量达到千万级，这种空间放大还会进一步放大备份与迁移成本。
优化路径与替代主键方案
如果业务必须使用全局唯一标识，又想缓解SQLite的写入压力，第一个可行做法是把UUID存为二进制而不是文本。SQLite的BLOB类型存放十六字节UUID，比三十六字符文本更短，比较效率也优于字符串。改造方式只需把表定义中的TEXT换成BLOB，写入时用uuid.bytes而非str(uuid.uuid4())。实测该做法能把写入耗时从四点五秒降到约三点一秒，文件体积也明显缩小。
另一个思路是改用有序唯一标识，例如ULID或基于时间的UUID version7。它们前缀携带毫秒时间戳，同一毫秒内生成的标识局部有序，大幅减少B树页分裂。下面展示ULID风格主键的简易生成与插入示例，虽然需要引入额外库，但在分布式写节点较多的场景下收益明显：
import sqlite3, ulid, time
conn = sqlite3.connect('ulid.db')
c = conn.cursor()
c.execute("CREATE TABLE t_ulid (id TEXT PRIMARY KEY, name TEXT)")
start = time.time()
for i in range(100000):
c.execute("INSERT INTO t_ulid (id, name) VALUES (?, ?)",
(ulid.new().str, f"user{i}"))
if i % 1000 == 0:
conn.commit()
conn.commit()
print("ulid insert cost", time.time() - start)
最后需要强调，如果系统本身就是单机本地库、且不需要对外同步数据，那么继续使用INTEGER PRIMARY KEY是最省心且最高效的选择。UUID类主键带来的分布式友好性，在SQLite这种常驻端侧或嵌入式的数据库里往往不是刚需。团队应在设计初期就评估数据规模与部署形态，避免盲目套用服务端数据库的经验，导致后期不得不做成本高昂的主键迁移。