opsxsql/OPTIMIZATION_PLAN.md

SQL-Platform-Pro 优化清单

基于当前实现状态（commit 39ffc14）的差距分析，按优先级 P0/P1/P2 分级。 状态标记：🟢已有基础 🟡部分实现 🔴未实现

---

一、假阳性/假阴性治理

现状

• MySQL 117 条审核规则（DDL-036 + DML 等），已持久化到 DB + 前端可调 severity/enabled
• 已做一轮降级（9 条 ERROR→WARNING），但缺少「为什么误报」的反馈闭环
• PostgreSQL / Redis / MongoDB 审核规则薄弱（PG 少量、Redis 仅 FLUSHDB 拦截、MongoDB 无专用规则）

优化项

#	优先级	内容	现状	工作量
1.1	P0	审核结果反馈机制 — 审批人在审批时可标记某条 finding 为「误报」，记录到 audit_feedback 表（rule_code, ticket_id, feedback_type, reason），月度统计误报率 TOP10 规则	🔴	2d
1.2	P0	上下文感知规则 — ALTER TABLE ADD INDEX 在小表（<1万行）应 WARNING 而非 ERROR；连接目标库查 table_rows 动态调整 severity	🔴	3d
1.3	P1	规则分组白名单 — 支持实例级别禁用/调整规则（如测试环境放宽所有 DDL 规则），instance_rule_override 表	🔴	2d
1.4	P1	PG 审核规则补全 — 参照 MySQL 规则体系，补齐 PG 特有规则（SERIAL 滥用、JSONB 无索引、VACUUM 建议、大对象等）	🟡	3d
1.5	P2	MongoDB 审核规则 — Pipeline 复杂度限制、$where/eval 禁止、dropDatabase 拦截、索引建议	🔴	3d
1.6	P2	规则测试基准 — 每条规则至少 3 个 case（正常通过/应拦截/边界），CI 自动验证规则回归	🔴	3d

---

二、大 SQL / 复杂语句处理

现状

• _split_statements() 用 sqlparse 切割多条 SQL
• 无 SQL 长度/复杂度上限（有 max_query_length 但仅查长度）
• MongoDB Pipeline 无复杂度检查

优化项

#	优先级	内容	现状	工作量
2.1	P1	SQL 复杂度评分 — 解析 JOIN 数量、子查询嵌套层数、UNION 数量，超过阈值（可配置）提升 risk_level	🔴	2d
2.2	P1	审核超时保护 — 单条 SQL 审核超过 5s 自动跳过（标记 timeout），避免正则/解析卡死	🔴	1d
2.3	P1	审核缓存 — 相同 SQL 文本（去空格后 hash）短期不重复审核，LRU 缓存 1000 条	🔴	1d
2.4	P2	MongoDB Pipeline 复杂度 — 限制 stage 数量（默认 20）、$lookup 嵌套层数、$group 内存风险	🔴	2d
2.5	P2	SQL 格式化展示 — 审核详情中高亮问题位置（行号+列号），用 sqlparse 格式化	🔴	1d

---

三、事务一致性（多条 SQL 原子性）

现状

• MySQL 执行有 conn.rollback() 失败回滚
• PG 执行有 transaction() 包裹
• 但 跨库没有事务，同库多条 SQL 部分成功部分失败时缺少明确的补偿机制
• Redis/MongoDB 多命令无事务概念（Redis 有 MULTI/EXEC 但未使用）

优化项

#	优先级	内容	现状	工作量
3.1	P0	执行进度透明 — 多条 SQL 逐条执行，每条记录 status( pending/running/success/failed )，前端实时展示	🟡	3d
3.2	P0	部分失败处理策略 — 可选：stop_on_error（默认，遇错停止）/ continue_on_error（跳过失败继续）/ transaction（整体回滚）	🔴	2d
3.3	P1	自动回滚 SQL 生成 — INSERT→DELETE、UPDATE→反向 UPDATE、DDL→DROP/ALTER REVERSE，记录到 rollback_sql 字段	🔴	5d
3.4	P1	Redis MULTI/EXEC — 工单中多条 Redis 命令用 pipeline 批量执行，保证原子性	🔴	1d
3.5	P2	跨库事务标记 — 跨库工单标注「无原子性保障」警告，审批人二次确认	🔴	1d

---

四、锁表与业务影响分析

现状

• 有工单执行锁（防并发执行同一工单）
• 无 EXPLAIN 预估、无影响行数预估、无锁表风险提示
• 无大表 ALTER 的 pt-osc / gh-ost 建议

优化项

#	优先级	内容	现状	工作量
4.1	P0	EXPLAIN 预检 — 审核阶段对 DML 执行 EXPLAIN（MySQL）/ EXPLAIN ANALYZE（PG），提取 rows 预估扫描行数，超过阈值（可配置，默认 10 万）标 ERROR	🔴	3d
4.2	P0	大表 ALTER 检测 — 查 information_schema.tables 获取表行数，大表（>10万行）ALTER 时提示「建议使用 pt-online-schema-change / gh-ost」，risk_level=high	🔴	2d
4.3	P1	影响行数预估 — DML 工单执行前用 SELECT COUNT(*) FROM ... WHERE <condition> 预估影响行数，超过阈值（默认 1 万）强制高等级审批	🔴	2d
4.4	P1	执行时间预估 — 基于 EXPLAIN 的 rows × 历史执行平均耗时，给出粗略预估（快<1s / 中<30s / 慢>30s / 极慢>5min）	🔴	2d
4.5	P2	执行超时强杀 — MySQL max_execution_time / PG statement_timeout 硬超时，超时自动 KILL 并标记 failed	🟡	1d
4.6	P2	维护窗口控制 — 可配置允许执行 DDL 的时间窗口（如凌晨 2-5 点），窗口外提交自动拒绝	🔴	1d

---

五、敏感操作审核强化

现状

• DROP TABLE → 审核规则 ERROR（DDL-004）
• Redis FLUSHDB/FLUSHALL → 仅限 admin
• 但审批只有一级（任意 admin/dba 可批），无多级审批
• 无风险等级区分（所有工单走同一审批流）

优化项

#	优先级	内容	现状	工作量
5.1	P0	工单风险等级 — 根据 SQL 类型 + 操作对象自动计算 risk_level(low/medium/high/critical)：DROP/TRUNCATE/FLUSHDB=critical，大表 ALTER=high，普通 DML=medium，SELECT=low	🔴	2d
5.2	P0	多级审批流 — risk_level=high 需要 2 人审批（DBA+管理员），critical 需要 3 人审批（DBA+管理员+CTO 或指定人），利用现有 WorkflowStep 模型	🟡	3d
5.3	P1	高危操作二次确认 — critical 级别工单执行前，执行人必须输入工单编号确认（防误操作）	🔴	1d
5.4	P1	敏感表保护 — 配置「保护表清单」（如 user/password/order/pay），对这些表的任何 DML/DDL 自动提升 risk_level，额外审批	🔴	2d
5.5	P2	执行前备份 — critical 工单执行前自动备份受影响表（CREATE TABLE xxx_backup AS SELECT *），备份保留可配置天数	🔴	3d
5.6	P2	MongoDB 危险操作 — dropDatabase、dropCollection、remove({}) 拦截 + 多级审批	🔴	1d

---

六、数据脱敏与审计

现状

• MaskingRule 模型已有（full/partial/hash/truncate/regex 5 种类型）
• 查询接口有 DataMasker 应用脱敏
• 审计日志 AuditLog 记录操作
• 但审核详情中 SQL 可能看到生产敏感数据、通知中可能泄露信息

优化项

#	优先级	内容	现状	工作量
6.1	P0	通知脱敏 — 通知消息中的 SQL 内容截断（>200 字符只显示前 100 + ...），隐藏 WHERE 中的值（如 phone='138****1234'）	🔴	1d
6.2	P1	审核日志不可篡改 — AuditLog 表增加 checksum 字段（SHA256 of content），定期校验完整性；或写入只追加日志文件	🔴	2d
6.3	P1	操作导出 — 审计日志支持 CSV/Excel 导出（按时间/用户/操作类型过滤），满足合规审计需求	🔴	2d
6.4	P1	审核详情脱敏 — 审批人看到的工单 SQL 中，对配置了脱敏的字段值做 mask（如 INSERT INTO users (phone) VALUES ('138****1234')）	🔴	2d
6.5	P2	会话级脱敏策略 — 不同角色看到不同级别的脱敏（admin 看完整、dba 看部分脱敏、developer 看完全脱敏）	🔴	2d
6.6	P2	SQL 注入检测 — 审核阶段检测疑似 SQL 注入模式（如连续单引号、UNION SELECT 注入、hex 编码绕过）	🔴	2d

---

优先级排序（建议实施路线）

第一阶段（2 周）— 安全基线

5.1 工单风险等级         → 后续所有功能的基础
1.2 上下文感知规则       → 减少误报最有效的手段
4.1 EXPLAIN 预检         → DML 执行安全核心
3.1 执行进度透明         → 多条 SQL 可观测性
6.1 通知脱敏             → 快速见效

第二阶段（2 周）— 体验优化

5.2 多级审批流           → 基于风险等级的审批
3.2 部分失败处理策略     → 多条 SQL 容错
4.2 大表 ALTER 检测     → DBA 最关心的场景
4.3 影响行数预估         → 审批人最需要的信息
1.1 审核结果反馈机制     → 持续优化规则质量
2.2 审核超时保护         → 稳定性兜底

第三阶段（2 周）— 高级特性

3.3 自动回滚 SQL 生成   → 最高价值但最复杂
4.4 执行时间预估        → 配合维护窗口
5.3 高危操作二次确认    → 防呆机制
5.4 敏感表保护          → 细粒度管控
1.4 PG 审核规则补全     → 多 DB 支持
6.2 审计日志不可篡改    → 合规需求

第四阶段（持续）— 生态完善

1.5 MongoDB 审核规则
1.6 规则测试基准
2.1 SQL 复杂度评分
5.5 执行前备份
6.3 操作导出
6.6 SQL 注入检测

---

预估总工作量

阶段	工作量	核心目标
P0 合计	~15 人天	安全基线 + 防误报
P1 合计	~23 人天	审批流 + 影响分析
P2 合计	~18 人天	高级特性 + 合规
总计	~56 人天	—