Drizzle Schema Analyzer — Drizzle 模式分析器

Drizzle Schema Analyzer 对Drizzle ORM schema定义进行正确性、性能、类型安全性和迁移安全性的分析。 审查表定义、列类型、索引、关系、约束和迁移文件。 作为一名高级数据库工程师，审计您的Drizzle schema以确保其生产就绪。

使用 在需要审查Drizzle ORM schemas、优化查询性能或验证迁移安全性时调用此技能。 基本调用： 分析/path/to/src/db/schema/中的Drizzle schemas 审查此Drizzle schema以获取最佳实践 检查最新Drizzle迁移的迁移安全性 聚焦分析： 检查所有Drizzle表的索引策略 审计关系定义以检测N+1风险 审查列类型选择以确保数据完整性 验证迁移文件以检测破坏性更改 代理读取Drizzle schema TypeScript文件，解析表和关系定义，并生成综合质量报告。

工作原理 步骤1：发现和解析Schema文件 代理定位所有Drizzle schema定义： # 查找所有schema文件 find /path/to/src/db/ -name ".ts" -type f # 确定包含Drizzle表定义的文件 grep -rl "pgTable\|mysqlTable\|sqliteTable\|createTable" /path/to/src/db/ --include=".ts" # 查找关系定义 grep -rl "relations\|defineRelations" /path/to/src/db/ --include=".ts" # 定位迁移文件 find /path/to/drizzle/ -name ".sql" -type f | sort 代理解析每个schema文件以提取： 表定义（pgTable、mysqlTable、sqliteTable） 列类型和约束（notNull、default、primaryKey、unique） 索引定义（index、uniqueIndex、复合索引） 关系定义（一对一、一对多、多对多） 枚举和自定义类型（pgEnum、mysqlEnum） 时间戳和审计列（createdAt、updatedAt、deletedAt） 导出模式（barrel导出、循环引用）

步骤2：审计表定义 代理检查每个表的列配置： 列类型分析： // GOOD：正确使用类型和约束 export const users = pgTable("users", { id: uuid("id").defaultRandom().primaryKey(), email: varchar("email", { length: 255 }).notNull().unique(), name: varchar("name", { length: 100 }).notNull(), status: userStatusEnum("status").notNull().default("active"), metadata: jsonb("metadata").$type(), createdAt: timestamp("created_at", { withTimezone: true }).notNull().defaultNow(), updatedAt: timestamp("updated_at", { withTimezone: true }).notNull().defaultNow(), }); // 代理检测到的问题： FAIL：表“users”列“email”——varchar没有长度约束 RISK：默认无限长度，允许数据质量问题 FIX：添加长度：varchar("email", { length: 255 }) FAIL：表“orders”列“amount”——real()用于货币值 RISK：浮点精度损失，尤其是在金融计算中 FIX：使用numeric("amount", { precision: 12, scale: 2 })或integer（以美分为单位） FAIL：表“events”列“created_at”——时间戳没有时区 RISK：时区模糊，尤其是在不同地区 FIX：timestamp("created_at", { withTimezone: true }) WARN：表“posts”列“body”——text()没有.notNull() Nullable text列会消耗额外的存储空间并使查询复杂化 FIX：添加.notNull()和默认值，如果空字符串是可接受的 WARN：表“products”列“price”——没有.notNull()约束 RISK：NULL价格会绕过应用程序验证并破坏计算 FIX：添加.notNull()并在应用程序层处理 WARN：表“sessions”没有“id”列或复合主键 RISK：没有唯一的行标识符用于更新或删除 FIX：添加主键列或复合主键：（t）=>（{ pk：primaryKey（t.orderId，t.productId）}）

步骤3：分析索引策略 代理评估索引覆盖与可能的查询模式： 索引分析： 表“users”（估计行数：高流量表） 索引：

• PRIMARY KEY on “id”（隐式）
• UNIQUE on “email”