# 图谱开发决策记录 记录当前已确认的资金流图谱和关系图谱开发口径，作为后续开发、验收和跨对话延续的依据。 ## 1. 页面嵌入位置 - 图谱功能先嵌入项目详情页的“专项排查”页签。 - 现有前端入口为 `ruoyi-ui/src/views/ccdiProject/components/detail/SpecialCheck.vue`。 - 页面在项目详情内承载，但资金流图谱本身不按 `project_id` 过滤。 - 查询入口以全局身份证号 `cret_no` 或员工姓名为准。 ## 2. 图谱表结构原则 - 建表逻辑尽量保持图谱平台已验证过的 SQL 逻辑。 - 不重新设计统一点表/边表。 - 表名保留图谱平台 SQL 中的五张结果表： - `lx_fund_flow_subject_node` - `lx_fund_flow_account_node` - `lx_fund_flow_own_account_edge` - `lx_fund_flow_detail_edge` - `lx_fund_flow_sum_edge` - 不在五张图谱表中增加 `project_id` 作为查询过滤口径。 - 一条流水可能存在于多个项目中，资金流图谱按全局资金关系构建，避免项目维度导致重复建点或重复算边。 ## 3. 五张表职责 | 表名 | 作用 | | --- | --- | | `lx_fund_flow_subject_node` | 主体点，表示人员、企业、名称代理主体 | | `lx_fund_flow_account_node` | 账户点，表示具体账号或名称代理账户 | | `lx_fund_flow_own_account_edge` | 主体到账户的持有关系 | | `lx_fund_flow_detail_edge` | 账户层逐笔资金交易边 | | `lx_fund_flow_sum_edge` | 主体层资金汇总边，前端默认展示 | 关键点： - 一个人可能有多个账号，所以必须保留主体点、账户点、持有边三层结构。 - 前端默认展示主体层汇总边，不默认展示全部账户层明细边，避免节点过多。 - 点击汇总边后，再查询账户层逐笔流水。 ## 4. 构建逻辑 构建逻辑以 `tupu/资金流图谱代码/lanxi_liushui_no_relation_simplified.sql` 为主。 重要口径： - 项目内 SQL 尽量和图谱平台原 SQL 保持一致。 - 先导入一部分“所有员工流水明细”作为图谱基座。 - 这部分基座数据视为已验证、绝对正确，不应被后续构建流程随意清空或覆盖。 - 后续从 `ccdi_bank_statement` 拉取新增流水时，需要先和图谱基座做一致性判断。 - 如果 `ccdi_bank_statement` 中的流水已经能在图谱基座中匹配到一致流水，则不同步进图谱，避免重复计入。 - 如果没有匹配到一致流水，则按原图谱 SQL 逻辑增量插入图谱。 保留的核心口径： - 本方证件号 `cret_no` 必须存在。 - 对手方名称必须存在，空值、空串、`0` 过滤。 - 金额必须有效，支出和收入统一成 `amount` 与 `flag`。 - 支出 `flag = 1`，收入 `flag = 2`。 - 明细去重，避免重复流水导致金额和笔数翻倍。 - 同名归并只作用于主体层，不改变账户节点和账户明细边。 - 无账号但有名称的对手方，按原 SQL 逻辑生成名称代理账户和名称代理主体。 一期先不展开追溯能力。需要为后续追溯预留字段和逻辑口子： - `source_table` - `penetrate_level` - 后续可扩展 `FIRST`、`LEVEL1` 等来源。 ## 4.1 基座与增量同步口径 图谱表不是“清空重建”的临时结果表，而是承载已验证图谱基座和后续增量的正式结果表。 基座数据： - 来源为先导入的所有员工流水明细。 - 按原图谱平台 SQL 生成五张 `lx_*` 表。 - 基座数据作为可信结果保留。 增量数据： - 来源为后续 `ccdi_bank_statement`。 - 拉取后先按原 SQL 的流水标准化和去重口径生成候选流水。 - 候选流水和既有 `lx_fund_flow_detail_edge` 做一致性比对。 - 已存在一致流水时跳过，不插入图谱。 - 不存在一致流水时，再增量生成账户点、主体点、持有边、明细边和汇总边。 一致性比对建议使用稳定业务特征，而不是 `project_id`： - 本方账号 - 本方户名 - 对手方账号 - 对手方户名 - 交易日期 - 金额 - 收支方向 `flag` - 摘要 `user_memo` - 银行流水号或交易流水号，如果有 增量插入要求： - 点表按 `object_key` 去重插入。 - 持有边按 `object_key` 去重插入。 - 明细边先判重，未存在才插入。 - 汇总边需要按主体对和方向重新聚合或局部 upsert，不能简单追加导致金额翻倍。 ## 4.2 ODPS 基座同步到 MySQL 当前真实部署口径： - 原图谱 SQL 已在 ODPS 中有一份结果。 - ODPS 结果只涉及行内流水。 - ODPS 已经产出五张图谱结果表。 - 可以先将 ODPS 中五张结果表一次性同步到纪检 MySQL。 - MySQL 同步建表脚本记录在 `sql/ccdi/graph/01_lx_fund_graph_mysql_ddl.sql`。 - 生产数据库表结构变更由人工单独执行，不跟随测试环境或应用发布自动更新。 - 项目内保留 SQL 文件，用于本地验证、评审和生产手动执行参考。 同步后的 MySQL 五张表继续使用原图谱表名： - `lx_fund_flow_subject_node` - `lx_fund_flow_account_node` - `lx_fund_flow_own_account_edge` - `lx_fund_flow_detail_edge` - `lx_fund_flow_sum_edge` 同步要求： - ODPS 到 MySQL 首次同步只做基座装载。 - 基座装载完成后，后续不再通过清空五张表重建处理。 - ODPS 字段和 MySQL 字段同名的按显式字段列表导入。 - MySQL 侧新增字段如 `family_relation_type`、`summary_object_key`、`source_table`、`penetrate_level`、`bank_statement_id`、`bank_trx_number` 可为空。 - `lx_fund_flow_sum_edge.detail_ids` 在 MySQL 中使用 `LONGTEXT` 接收 ODPS ARRAY 同步后的 JSON 或字符串表示，前后端查询不强依赖该字段。 ## 4.3 MySQL 后续增量方式 后续新增数据都在纪检 MySQL 内处理： - 来源表为 `ccdi_bank_statement`。 - 增量逻辑从 `ccdi_bank_statement` 抽取候选流水。 - 候选流水按原图谱 SQL 口径标准化、过滤、生成 object_key。 - 先和既有 `lx_fund_flow_detail_edge` 做一致性判重。 - 已存在一致流水时不插入图谱。 - 不存在一致流水时，才增量插入点、账户、持有边、明细边。 - 汇总边 `lx_fund_flow_sum_edge` 按主体对和方向重新聚合或局部 upsert。 调度建议： - 一期建议做每日定时调度，不建议一开始做实时。 - 推荐使用 RuoYi/Quartz 定时任务，每天凌晨或低峰期执行。 - 同时保留后台手动触发能力，便于首次补跑、排查和修复。 - 实时同步不是不能做，但没有必要优先做；实时会增加事务、锁、重复判断和汇总边更新复杂度。 推荐执行节奏： 1. ODPS 五张结果表一次性同步到 MySQL。 2. MySQL 跑一次家庭关系补充和 `summary_object_key` 回填。 3. 每日 Quartz 调度从 `ccdi_bank_statement` 抽取新增候选流水。 4. 候选流水与 `lx_fund_flow_detail_edge` 判重。 5. 未命中重复的流水增量入图。 6. 更新对应主体层汇总边。 7. 前端始终只基于 MySQL 五张 `lx_*` 图谱表查询展示。 ## 4.4 数据库变更执行边界 数据库表结构改动属于生产库手工变更，不纳入测试环境自动更新。 后续开发分工： - SQL 文件由代码库保留，作为生产手工执行依据和本地验证依据。 - 生产执行由人工确认后单独处理。 - 后端开发默认这些表在目标库中已经存在。 - 前端开发不感知数据库变更，只调用后端接口。 - 测试环境如没有这五张表，需要手动执行 SQL 后再联调。 - 应用发布包不自动执行这些 DDL。 ## 5. 家庭关系 家庭关系是本次项目内新增能力，参考 `tupu/资金流图谱代码/资金流图谱_家庭关系补充.sql`。 处理原则： - 不改变资金方向。 - 不改变主体归并逻辑。 - 不改变账户层明细边生成逻辑。 - 只在资金边上增加家庭关系标注。 匹配规则： - 交易任意一侧可映射到员工主体。 - 员工主体必须有身份证号。 - 对手方姓名命中 `ccdi_staff_fmy_relation.relation_name`。 - 同一员工和同一关系人姓名只有一个 `relation_type` 时才标注。 - 多个关系类型冲突时不打标，避免误判。 建议补充字段： - `lx_fund_flow_detail_edge.family_relation_type` - `lx_fund_flow_sum_edge.family_relation_type` ## 6. 查询逻辑 搜索主体： ```sql select * from lx_fund_flow_subject_node where idnocfno = #{keyword} or name like concat('%', #{keyword}, '%'); ``` 查询主体层资金图： ```sql select * from lx_fund_flow_sum_edge where from_key = concat('idno_node/', #{objectKey}) or to_key = concat('idno_node/', #{objectKey}) order by amount desc, total_trans_cnt desc limit #{limit}; ``` 点击汇总边查询逐笔流水： ```sql select * from lx_fund_flow_detail_edge where summary_object_key = #{sumObjectKey} order by trx_date desc limit #{offset}, #{pageSize}; ``` 说明： - 原图谱平台 `detail_ids` 可以保留。 - MySQL 分页查询建议增加 `summary_object_key`，用于从汇总边直接查明细边。 - `summary_object_key` 是查询优化字段，不改变原图谱平台点边模型。 ## 7. 前后端开发边界 后端负责： - 从五张 `lx_*` 图谱结果表读取数据。 - 按身份证号或姓名定位主体。 - 返回主体层图谱节点和汇总边。 - 支持点击资金汇总边分页查询逐笔流水。 - 透出家庭关系字段。 - 空表或脏数据时返回空结果，不让前端报错。 前端负责： - 在“专项排查”页签中呈现图谱展示区域。 - 支持身份证号或员工姓名搜索。 - 支持“资金图谱 / 关系图谱”页签。 - 一期资金图谱做实，关系图谱可先保留入口。 - 默认展示主体层资金汇总图。 - 点击边展示逐笔流水明细。 - 展示图谱明细边中已写入的家庭关系标签，如配偶、父母、子女。 ## 8. 基座保护与异常数据处理 图谱表承载已验证基座，不按“可随意清空重建”设计。人工可以维护或清理异常数据，但默认应保护已有基座。 处理要求： - 后续增量同步不得清空五张 `lx_*` 表。 - 增量同步前必须先判断候选流水是否已存在于 `lx_fund_flow_detail_edge`。 - 已存在一致流水时跳过，避免重复金额和重复笔数。 - 人工清理异常边后，后端查询需要能容忍局部缺失数据。 - 边表有、点表缺失时，后端过滤无法匹配节点的边，不让前端报错。 - 明细边为空时，点击汇总边提示暂无逐笔流水。 - 如果人工确实清理了部分图谱数据，后续增量插入仍需按 `object_key` 和流水一致性规则防重。 ## 9. UI 风格 固定设计口径： - 浅色系统风格。 - 正式后台质感。 - 与当前纪检系统色调保持一致，蓝、白、灰为主。 - 朝图谱平台式交互靠齐。 - 不做黑色大屏。 - 不做网感、霓虹、炫光科技风。 - 图谱画布使用浅灰白背景，边界清楚。 - 搜索区放在顶部，支持身份证号和姓名。 - 页签为“资金图谱”和“关系图谱”。 - 明细使用右侧抽屉或下方面板展示，优先保证字段清楚和分页性能。 ## 10. 后续开发顺序 建议顺序： 1. 先落项目内 SQL：DDL、构建 SQL、家庭关系补充 SQL、索引 SQL。 2. 先支持已导入员工流水明细作为图谱基座。 3. 增加 `ccdi_bank_statement` 到图谱表的增量同步逻辑。 4. 增量同步必须先和既有 `lx_fund_flow_detail_edge` 做一致性判重，已存在则不同步。 5. 后端接口改为读取五张 `lx_*` 图谱表。 6. 前端在“专项排查”页签接入图谱展示区域。 7. 完成资金图谱搜索、展示、点击边查明细。 8. 增加家庭关系标签展示。 9. 验证基座保护、增量防重、一个人多个账号、家庭关系命中等场景。 ## 11. 当前代码进度与偏差 截至 2026-05-28，项目内已经做过一版一期资金流图谱代码，但这版实现口径与当前最终方案不完全一致，后续需要重构而不是直接当最终版。 已完成过的代码： - 后端新增 `CcdiFundGraphController`，接口路径为 `/ccdi/project/fund-graph/graph` 和 `/ccdi/project/fund-graph/edge-detail`。 - 后端新增 DTO/VO：`CcdiFundGraphQueryDTO`、`CcdiFundGraphEdgeDetailQueryDTO`、`CcdiFundGraphVO`、`CcdiFundGraphNodeVO`、`CcdiFundGraphEdgeVO`、`CcdiFundGraphStatementVO`。 - 后端新增 Mapper 和 Service：`CcdiFundGraphMapper`、`ICcdiFundGraphService`、`CcdiFundGraphServiceImpl`、`CcdiFundGraphMapper.xml`。 - 前端新增接口文件 `ruoyi-ui/src/api/ccdi/fundGraph.js`。 - 前端新增组件 `ProjectAnalysisFundFlowTab.vue`。 - 前端已在 `ProjectAnalysisDialog.vue` 中接入资金流图谱页签。 旧版已验证情况： - `mvn -pl ccdi-project -am compile -DskipTests` 通过。 - `npm run build:prod` 通过。 - 真实库只读校验过项目 33 和姓名样例，能查出资金边，点击边能查逐笔流水。 - 曾修正 MySQL 8 保留词别名 `rows` 和字符集排序规则不一致问题。 当前偏差： - 旧版接口是实时从 `ccdi_bank_statement` 聚合资金图谱，不读取五张 `lx_*` 图谱结果表。 - 旧版查询带项目上下文，当前最终口径是不按 `project_id` 过滤，以全局 `cret_no` 或姓名为入口。 - 旧版前端接在项目分析弹窗 `ProjectAnalysisDialog`，当前最终入口应放在“专项排查”页签。 - 旧版没有按图谱平台五表基座和增量同步口径处理。 - 旧版没有家庭关系标注。 后续处理原则： - 可复用旧版的图谱展示、点击边查明细、分页表格等前端交互经验。 - 可复用旧版 DTO/VO 中适合前端展示的字段，但字段来源需要改为五张 `lx_*` 表。 - 后端 SQL 必须从实时聚合 `ccdi_bank_statement` 改为读取 `lx_fund_flow_subject_node`、`lx_fund_flow_account_node`、`lx_fund_flow_own_account_edge`、`lx_fund_flow_detail_edge`、`lx_fund_flow_sum_edge`。 - 前端入口需要从项目分析弹窗迁移或重做到“专项排查”页签。 - 旧版文件在重构时应谨慎处理，避免影响当前项目分析弹窗已有功能。 ## 12. 页面查询与汇总表最新决策 最新决策： - 纪检平台资金流图谱页面不强依赖 `lx_fund_flow_sum_edge`。 - 页面查询以 `lx_fund_flow_detail_edge` 为事实表，由后端按当前查询条件实时聚合。 - 前端不做金额和笔数聚合，只负责渲染后端返回的节点、边和明细。 - `lx_fund_flow_sum_edge` 如生产侧不需要兼容图谱平台页面，可以不作为纪检页面必需表。 - 如果 ODPS 已有 `lx_fund_flow_sum_edge`，可以选择不同步到 MySQL，或同步后仅作为参考缓存，不作为纪检页面查询依据。 原因： - 用户每次查询通常以一个人为中心，一跳图谱范围可控。 - 用户需要按 `trx_date` 任意筛选时间范围。 - 全量 `lx_fund_flow_sum_edge` 不能准确表达任意时间段内的金额和笔数。 - 每天新增明细后维护汇总表会增加复杂度。 - 后端从明细边实时聚合能保证筛选结果准确，且比前端聚合更可靠。 后端聚合口径： 1. 用身份证号、姓名或 `object_key` 定位主体点。 2. 查询该主体名下账户。 3. 从 `lx_fund_flow_detail_edge` 查询这些账户相关流水。 4. 按 `trx_date`、金额、方向、家庭关系等筛选条件过滤。 5. 后端将账户层明细边聚合为主体层资金边。 6. 返回前端用于图谱展示。 时间筛选字段： - 所有时间筛选基于 `lx_fund_flow_detail_edge.trx_date`。 - 不用 `lx_fund_flow_sum_edge.first_trx_date` 或 `lastest_trx_date` 判断筛选结果。 ## 13. 节点穿透最新决策 节点穿透以 `lx_fund_flow_subject_node.object_key` 为唯一标识，不按姓名穿透。 口径： - 实名主体按原 SQL 逻辑生成 `object_key`，即 `md5(trim(idnocfno))`。 - 用户点击节点后，可选择“以此节点为中心查询”或“展开此节点”。 - 默认不自动穿透，避免图谱过长和误展开。 - 后端按被选节点的 `object_key` 查询其账户和流水。 - 节点是否可穿透由后端返回 `canExpand` 控制。 允许穿透： - 有明确身份证号或证件号的实名主体。 - 有明确账户归属、能通过 `lx_fund_flow_own_account_edge` 找到账户的主体。 默认不穿透： - 只有名称、没有证件号、没有明确账户归属的名称代理主体。 - 无法通过 `object_key` 准确定位账户集合的节点。 交互建议： - 一期做“设为中心查询”，即点击节点后重新以该节点为中心画一跳图。 - 后续再做“在当前图上追加展开”，避免一期图谱状态管理过复杂。 ## 14. 最终减法版决策 本节覆盖前文早期关于五张表、`lx_fund_flow_sum_edge`、关系图谱页签的旧设想。后续开发以本节为准。 本节为 2026-05-28 资金流图谱减法版决策，重点是不依赖 `lx_fund_flow_sum_edge`。关于关系图谱页签，后续已在第 16 节更新为“保留关系图谱能力”，以第 16 节为准。 必要表： - `lx_fund_flow_subject_node` - `lx_fund_flow_account_node` - `lx_fund_flow_own_account_edge` - `lx_fund_flow_detail_edge` 不依赖： - `lx_fund_flow_sum_edge` 页面查询： - 输入身份证号、姓名或点击节点 `object_key`。 - 后端定位主体点。 - 后端查询主体持有账户。 - 后端从 `lx_fund_flow_detail_edge` 按账户、`trx_date`、金额等条件实时聚合资金边。 - 前端只渲染后端返回的资金节点、资金边和逐笔明细。 家庭关系： - 只作为资金流图谱中的标签展示。 - 家庭关系识别在图谱构建或数据加工阶段完成，并写入 `lx_fund_flow_detail_edge.family_relation_type`；后端查询接口只读取并返回该字段，不实时匹配家庭表。 - 如果生产构建需要按对手方户名匹配 `ccdi_staff_fmy_relation.relation_name`，应在构建 SQL 中完成，并控制同名误判风险。 - 有明确 `relation_cert_no` 的家庭关系人按实名主体处理，`object_key = md5(trim(relation_cert_no))`。 - 用户点击该节点时，可按该节点 `object_key` 设为中心继续查询。 测试数据： - 测试 DDL 为 `sql/ccdi/graph/01_lx_fund_graph_mysql_ddl.sql`。 - 测试数据脚本为 `sql/ccdi/graph/02_lx_fund_graph_seed_test_data.sql`。 - 测试数据只写四张必要表。 - 测试数据来源于 dev 库 `ccdi_bank_statement` 和 `ccdi_staff_fmy_relation`。 - 原始流水表不被修改。 ## 15. 前后端与页面交互设计 默认查询： - 默认查询全部流水，不默认带交易日期过滤。 - 用户选择交易日期后，后端才按 `lx_fund_flow_detail_edge.trx_date` 过滤。 - 时间过滤不查汇总表，直接从明细边实时聚合。 后端接口建议： ```text GET /ccdi/project/fund-graph/search GET /ccdi/project/fund-graph/graph GET /ccdi/project/fund-graph/edge-detail POST /ccdi/project/fund-graph/manual-edge GET /ccdi/project/relation-graph/search GET /ccdi/project/relation-graph/graph GET /ccdi/project/relation-graph/suspected-enterprises ``` 接口职责： - `search`：按身份证号或姓名查主体点，返回候选主体列表。 - `graph`：按主体 `object_key` 查询一跳资金图，默认全部流水，可选日期、金额、方向过滤。 - `edge-detail`：点击资金边后，分页查询该边下的逐笔流水。 `graph` 入参： ```text objectKey 必填，主体 object_key startDate 可选，交易开始日期 endDate 可选，交易结束日期 amountMin 可选，最小金额 amountMax 可选，最大金额 direction 可选，1支出、2收入 limit 可选，默认20 ``` `graph` 返回： ```text centerNode 当前中心主体 nodes 图谱节点 edges 聚合后的资金边 summary 当前查询范围的总金额、总笔数、家庭关系边数量 ``` 节点字段： ```text objectKey nodeKey idno_node/{object_key} name idNo nodeType PERSON / PROXY canExpand relationType 如果是家庭关系节点，返回配偶/父亲/母亲等 ``` 边字段： ```text edgeKey fromKey toKey fromName toName direction 1支出、2收入 amount transactionCount firstTrxDate lastTrxDate familyRelationType ``` `edge-detail` 入参： ```text fromObjectKey toObjectKey direction startDate endDate pageNum pageSize ``` 页面交互： - 页面位置：项目详情“专项排查”页签。 - 页面标题：图谱展示。 - 展示“资金流图谱”和“关系图谱”两个页签。 - 搜索区只保留必要控件：身份证号/姓名、交易日期、查询、重置。 - 默认空态提示：请输入身份证号或姓名查询资金流图谱。 - 查询后画一跳图，中心节点为当前人员。 - 边上只显示金额和笔数，家庭关系用标签显示。 - 点击资金边，右侧抽屉展示逐笔流水。 - 点击节点，提供“设为中心查询”；默认不自动穿透。 - 只有 `canExpand = true` 的节点展示“设为中心查询”。 性能口径： - 前端不聚合金额和笔数。 - 后端只围绕一个主体的账户集合查明细边。 - 默认全部流水也只查当前主体相关边，不扫全表。 - 必须使用 `lx_fund_flow_own_account_edge.from_key`、`lx_fund_flow_detail_edge.from_key/trx_date`、`lx_fund_flow_detail_edge.to_key/trx_date` 索引。 - 后端 SQL 参数比较需要显式 `COLLATE utf8mb4_general_ci`，避免当前库连接排序规则和表排序规则不一致。 当前 dev 测试数据： ```text 测试身份证号：617673198109148314 测试 object_key：以 `MD5('617673198109148314')` 为准 主体点：10 账户点：14 持有边：14 明细边：72 ``` 测试覆盖： - 默认全部流水聚合。 - 日期范围筛选聚合。 - 支出方向 `flag = 1`。 - 收入方向 `flag = 2`。 - 家庭关系标签：配偶、父亲、母亲。 - 普通对手方：支付宝、淘宝、美团、财付通、小店、银行转账。 - 点击家庭关系节点按 `object_key` 设为中心查询。 ## 16. 2026-05-29 最新验收口径 本节为当前最新口径，用于覆盖前文早期变更记录中的冲突描述。 当前图谱功能保留两类能力： - 资金流图谱：作为专项排查中的核心图谱能力，读取 `lx_fund_flow_subject_node`、`lx_fund_flow_account_node`、`lx_fund_flow_own_account_edge`、`lx_fund_flow_detail_edge`，并叠加 `lx_fund_flow_manual_edge` 手工资金流向。 - 关系图谱：保留页面页签和接口能力，读取 `lx_rel_node`、`lx_rel_family_edge`、`lx_rel_stock_edge`、`lx_rel_represent_edge`，支持家庭关系、股东持股、法定代表人关系和疑似同名企业召回。 当前页面入口： - 项目详情“专项排查”页签展示完整图谱工作台，包含“资金流图谱”和“关系图谱”两个页签。 - 项目分析弹窗“资金流向”页签展示简版资金流图谱。 - 项目分析弹窗“关系图谱”页签展示简版关系图谱。 当前接口入口： ```text GET /ccdi/project/fund-graph/search GET /ccdi/project/fund-graph/graph GET /ccdi/project/fund-graph/edge-detail POST /ccdi/project/fund-graph/manual-edge GET /ccdi/project/relation-graph/search GET /ccdi/project/relation-graph/graph GET /ccdi/project/relation-graph/suspected-enterprises ``` 当前数据库执行口径： - 新环境可参考 `sql/ccdi/graph/01_lx_fund_graph_mysql_ddl.sql` 和 `sql/ccdi/graph/03_lx_relation_graph_mysql_ddl.sql`。 - 已建资金流图谱表的环境使用 `sql/ccdi/graph/06_lx_fund_graph_existing_table_supplement.sql` 补字段和补索引，不删除、不重建、不清空基座数据。 - 已建关系图谱表的环境使用 `sql/ccdi/graph/03_lx_relation_graph_mysql_ddl.sql` 中的补充逻辑补字段和补索引。 - 生产 DDL 和补充 SQL 都由人工确认后手动执行，不随应用发布自动执行。 当前验收样例： ```text 资金流图谱测试身份证号：617673198109148314 关系图谱测试身份证号：330101198001010011 ```