用途：审计数据库主键策略，兼顾身份建模与索引性能两个维度。缺失主键或主键耗尽等缺陷会直接封顶评分。
主要检查项：表和集合缺失主键或唯一行标识；随机 UUIDv4 作为聚集/前导 B-tree 键造成插入碎片与索引膨胀，建议改用时间有序的 UUIDv7/ULID 或 bigint identity，并标记热插入表上的 uuid_generate_v4() 默认值；在 Postgres 18 及以上（2025 年 9 月 GA）推荐原生 uuidv7()，将 gen_random_uuid()/v4 视为降级，而 PG 18 以下或非 Postgres 引擎仍可使用 gen_random_uuid() 与应用侧 UUIDv7；可变自然键（email、slug）作主键会把变更传播到所有外键，建议改稳定代理键；int4/serial/SERIAL 主键在行数可能超过约 21 亿时存在耗尽风险，bigint/bigserial 更安全；复合主键的首列应匹配主要访问或分区模式。
严重度分级：关系/宽列表无主键为 severity 5、fail、axis both、confidence established；int4/serial 主键接近耗尽需 Tier-1 行数证据才为 severity 5，否则 static 下为 severity 4 warn、directional；热插入表的 UUIDv4 聚集主键为 severity 3、warn；可变自然键主键为 severity 3、warn。
检查方式：Tier-0 用 scripts/parse-schema.mjs 解析 DDL/快照，断言每张表声明 PRIMARY KEY 或文档存储有 _id/shard 身份，并检查主键列类型及默认值；Tier-1 用只读 SQL 验证，例如查询 information_schema 找出无主键的表，或用 SELECT max(id) AS cur, 2147483647 AS int4_max, round(100.0*max(id)/2147483647,1) AS pct_used FROM <table>; 检查 int4 主键余量。
输出：按 finding.schema.json 逐条输出，示例包括 M2.events.no_primary_key、M2.audit_log.int4_pk_exhaustion、M2.orders.uuidv4_clustered_pk；每条含 evidence.observed（引用主键 DDL 或目录结果）、verification.reproduce（可运行查询）与带置信度的影响区间。
限制：没有 Tier-1 的 max(id) 与增长信号时，不得声称 int4 即将耗尽；UUIDv4 并非错误，成本在于热插入的索引局部性，不得编造插入吞吐百分比；代理键与自然键的选择依上下文而定，应呈现权衡而非断言唯一正确。