9 Commits

Author	SHA1	Message	Date
ThearchyHelios	f774e42463	数据剖析可以同时剖析几张表：剖析设置加「同时剖析的表数」（table_concurrency，1–3，缺省 1，即以前的一张做完再做下一张；上限 3 是给这个源上的分析留出连接池的临时连接），每张表的查询仍一条一条发，所以同一时刻对业务库最多这么多条查询。剖析任务的执行改成按设置开几个执行者，按任务里的顺序一张结束就开始下一张；进度、发过的查询各落在自己那张表上（不再记「正在做的那一张」）。每张表开始前照旧重读数据源：停用、关掉剖析或止损后不再开始新的表，正在做的几张照常做完（止损时剩下的项记止损的原因），都结束后再把没开始的记停下；止损的连续失败、超时比例按几张表的查询合起来算。停止、关停时正在做的几张各自收尾，做完的项照常写进目录，都收完才往上交（等的时候又被停止也等完）；一张表让任务整体出错（快照被改动、数据源没了、记结果写库出错）时，另几张按停止收尾、原因写这一句，本进程续不上租约的不写。同时要估同一张表的行数时只估一次（按表加锁，先来的没估成后来的自己估）。同源已有剖析时的 409 说法从「第 x / y 张表」改成「已完成 x / y 张表」。界面：设置表单多一格（单位「张」，提示写明业务库同时要应付几条查询、和分析共用连接），风险说明、卡片悬停、开始前的醒目一句在大于 1 时写明「同时剖析 N 张表、每张表的查询一条一条地发」，预算多一行，这次最多用时按几轮算。测试：同一时刻在途查询不超过设置、每张表仍一条一条发（1/2/3 三种）、几张一起显示进行中并按顺序开始、同时停止各自写进目录、止损后不再开始新表、停用时正在做的做完、一张出错另几张按停止收尾、共享行数只估一次；check-catalog-profile 加一节（预算、估算、说法、两行进行中、表清单）。验收：后端全量 14979 通过；止损那条并发测试单独跑 30 遍、整个剖析任务测试文件并行跑 15 遍都没有偶发；tsc；check-catalog-profile 217 项、check-copy 28 项全过	2026-10-21 09:08:10 +08:00
ThearchyHelios	f5c9f0c13c	剖析任务接口收取值观察范围，对话框给出「取值观察」；定时维护挑不出要观察的表时把原因记进触发记录 ... 验收：取值观察只能经定时维护触发——POST /catalog/profile-jobs 的 scope 只收 needed、all，可剖析任务本来就支持 observe（只观察、不剖析）。另外 12 小时内观察过的表不再观察时，任务以 0 张表结束，原因只在剖析任务的 notice 里，从定时维护触发时触发记录（ScheduleFire.inputs）看不出来。 后端： - ProfileJobIn.scope 加 observe（maintenance 是定时维护用的，接口照旧不收）。挑不出表时照旧 409 profile_nothing， 说法是 NOTHING_TO_OBSERVE（「最近 12 小时内都观察过了」）。 - catalog_profile_jobs.nothing_reason：按此刻的表结构和目录一张表都挑不出来时交回 ProfileNothing 的原话；排在 起草后面时说不准，返回 None。 - source_maintenance._start：建出 0 张表的剖析任务、这次触发又没有探查（开始时表结构不会变）、也没排在起草后面 （目录不会变）时，判断得出任务会以 0 张表结束，把原因记进 inputs.skipped（同一套 NOT_RUN 说法进 reason）。 任务照建、触发照旧是 started：每小时一次的维护不至于一天二十几次「没能发起」。同一次触发里有探查、或者排在 起草后面时判断不了，保持现状，写进了模块说明。 前端：剖析对话框的范围里加「取值观察：有数据目录的 N 张表」（说法照维护设置里「取值观察」那一步：码值分布、 最新业务日期、按日行数和行数，和同口径的历史比出取值变化；最近 12 小时内观察过的这次不再观察），建任务带 scope: observe。张数按清单上有数据目录、不是视图的表算（isObservable，profile.ts），观察到期没有由服务端判， 所以是上限。挑不出表时说「没有要观察的表」和服务端原话，不给「改选全部表」（那是剖析，不是观察）。文案进 PROFILE_TEXT。 测试：test_catalog_observe 新增一条（接口建 observe 任务、只做观察检查，再建一次 409 profile_nothing，maintenance 422）；test_source_maintenance 新增一条（只选取值观察，12 小时内再触发：任务 0 张表，inputs.skipped 和 reason 写明 原因）。去掉修复回跑两条都挂。check-catalog-profile 跟上：范围多一项 observe:1，说法核对；新一节建取值观察任务 （请求体 {scope: observe}）、都观察过时的「没有要观察的表」且没有「改选全部表」。tsc、check-copy 通过， check-catalog-profile 204 项全过。	2026-10-17 08:51:51 +08:00
ThearchyHelios	9252e6bb0e	W4-d 检查：check-catalog-changes 换成真检查；check-catalog、check-catalog-profile、check-catalog-loop、check-capabilities 跟上 ... - check-catalog-changes（骨架里的占位换掉）：假接口加夹具（虚构的网店库），写请求在浏览器层拦下、断言请求体。守的是「变化」 视图的分组（要处理 / 提醒 / 说明，组内照服务端的先后）、两种筛选进请求和地址、刷新后还在；一条变化的依据、前后、影响面 （目录项现在的状态、「这条 SQL 现在会报列不存在」、模板链到编排页那个节点、有效记录条件）；动作照服务端给的 actions 画、做不了 的写原因；清理先确认、加入码值带含义、知道了、误报的请求体，误报没写理由（含只填空白）按钮不能点；处理完写目录版本、建了的 起草任务点得进进度；表详情一节（变化、撤销过的「已列全」、四种观察和口径、口径换过的提醒、断档的日子也在小柱图里）；数据源 角标（读屏写全、点了到「变化」）；定时维护缺省关、开启时提示低峰时段、建（target_kind=source_maintenance）和改（PATCH 只带 改了的和版本）、步骤走 PUT、最近一次建了哪个任务和哪几步没执行；后台任务条按服务端的两种先后、页头读屏不写数字、提醒在条上 写全文、「查看」打开对应的对话框、探查的到数据源卡片；窄屏不撑宽页面。去掉排序、去掉「没写理由不能点」回跑，这几项都会报出来。 - check-catalog、check-catalog-profile：DraftStrip 的断言换成后台任务条（data-catalog-job-strip、data-catalog-job），页头的 「起草」「数据剖析」只断言读屏写状态、不写数字；剖析的「最近查询多数超时」改在任务条上断言全文；check-catalog-profile 的假接口 按建的先后给出队列，两种排法（起草在前 / 剖析在前）的文字都断言；窄屏下任务条看得见。三个目录检查都给变化、观察、后台任务、 upkeep 配上空的假接口，不把假的源放行到服务端去查。 - check-catalog-loop.mjs 的 PROFILE_ON 换成 table_max_queries: 40、table_max_s: 60（和 check-catalog-profile 的 DEFAULTS 一致， 05 (g)）。 - check-capabilities：全局渠道可订阅的事件里有了「数据源有变化要处理」（第 4 波打开了订阅），登记了还没推送的只剩召回。 本包相关的检查（catalog-changes、catalog、catalog-profile、catalog-loop、capabilities、manage）在另起的一套后端 + vite 上都过了。	2026-10-16 20:05:43 +08:00
ThearchyHelios	ee7b8b2f97	剖析与探查的方言修正（C1）和没有真库时的方言验证（C2） ... 为什么：剖析是全站唯一主动查业务库的地方，以前只在守卫放行和字符串片段两层上测过，从没在真库上跑过。 本机四个容器（PG 16、MySQL 8.4、MariaDB 11、Oracle Free 23）实测，旧的 IN 列表写法在 PostgreSQL 上整数子列 对文字主键直接报 operator does not exist: character varying = integer，关系一条都核对不了。 C1 方言修正： - IN 列表的字面量按被指向列的类型族写（key_literals）：父列文字写 '12'，父列数字只收整数写法的值，父列是时间、 对不上的不拼并在备注里写「两端类型不同」；子表是 CHAR(n) 时去掉补齐的尾随空格。 - 列类型改存按方言编译的完整写法（VARCHAR2(20 CHAR)、NUMBER(10, 0)、ENUM('a','b')、TIMESTAMP WITH TIME ZONE）， 编译不了退回 str()。SQLAlchemy 把 Oracle 的 VARCHAR2 反射成通用 VARCHAR（容器实测），照数据字典写成 VARCHAR2。 ENUM / SET 另记 enum_values；Oracle 小写带引号的表和列记 quote_name；各索引（含主键）的首列记进 index_first_columns（下一波取值观察判断能不能对大表发窗口查询）。新探查的快照哈希会变，旧运行封存的不受影响。 - catalog._type_family 认 ENUM / SET 是文字、INTERVAL 不是数字，去掉引号里的取值再认；新增 column_family （有 enum_values 的是文字，PostgreSQL 枚举编译出来只有类型名）；is_date_column 不再把 ENUM('date') 认成日期列。 - 码值候选：ENUM / SET 不看列名直接算候选，ENUM 列定义里这次没出现的取值也写进码值（含义待填）；VARCHAR2(20 CHAR) 的长度按 20 算；CHAR 码值去尾随空格；MySQL 上写明按排序规则分组、比较（可能不分大小写）。 - 统计信息估出的行数不超过整表统计上限时再跑一次有上限的计数确认，统计过期的大表不再被当成小表做整表统计。 - 日期列的最小值、最大值只看 0001-01-02 到 9999-12-31 之间的值，零日期、占位日期、PG 的 ±infinity 不计入， 照实写「另有 N 个无效日期未计入」，日期范围里带 invalid 个数（界面显示）。 - 新增取值观察用的方言方法 date_literal / day_trunc / sample_from，以及按日行数、时间窗口里的取值分布、块采样三类 查询的拼法（窗口上端截在 9999-12-31 之前，不让 infinity 多出一天）。 - 说明文字不再说「抽样」：大表看的是「按存储顺序取前 N 行」；设置项「抽样键值数」改叫「核对键值数」。 C2 验证： - tests/test_profile_dialect_golden.py：五种方言 × 全部剖析和观察查询的完整 SQL 钉在 tests/fixtures/dialect/， sqlglot 逐条解析、过只读守卫，再用 qualify + annotate_types 核对 IN 两边类型族一致（附旧写法的对照）。 - scripts/dialect-it.sh（不进 CI）：本机起四个容器，建虚构夹具（保留字列、Oracle 小写带引号的表、CHAR 码值、 MySQL ENUM、零日期 / infinity / 占位日期、做旧的统计信息、超上限的大表、带索引的日期列），用 AgentLab 自己的 探查和剖析代码跑全部查询，断言零报错、结论和手算一致。四种库都通过；MariaDB 插入时自己更新行数估算，统计信息 做不旧，照实打印。把 IN 列表改回旧写法回跑，PG 上照样报出上面那条错误。跑完删容器、留镜像。	2026-10-16 10:25:28 +08:00
ThearchyHelios	ff278afd7e	剖析的范围在开始时定：排在起草后面的剖析任务，开始时按起草后的目录重挑要剖析的表 ... 真实后端验收里「起草完接着剖析」这条主路走不通：剖析任务建的那一刻就按当时的目录定了表单，可它排在起草后面，起草还没提出 关系，只靠关系才有检查项的表（链接表、明细表）一张都挑不进来，起草写完关系后剖析照旧跳过它们。 - 开始剖析时（_ProfileRun._rescope）按那一刻的目录重定：需要剖析的表、全部表整份重挑（这个任务的表都还没开始）；指定的表里 建任务时判为「没有可剖析的项」的再看一次，现在有了就排上。 - 排在起草后面时挑不出表也照建，不再 409（起草多半会提出关系）；开始时还挑不出来，任务以 0 张表结束，提醒里写明为什么。 - 界面：排队时写明要剖析哪些表开始时按起草后的目录再定，开始前的张数是按现在的目录算的。 - 新测试在去掉重挑的代码上两条都失败。	2026-10-15 19:43:29 +08:00
ThearchyHelios	90fa83d807	check-catalog-profile 跟上「需要剖析」的新说法（多出码值、日期列的也算，上次是空表的不算）	2026-10-15 19:35:01 +08:00
ThearchyHelios	4c4fa8e4e9	「需要剖析」多认一种：上次剖析之后多出了码值、日期检查（new_checks）；停止排队任务时不再读过期的 job（起草、剖析两处） ... - 以前只认从没剖析过、上次没做完、又冒出了待核实关系三种：上次剖析时没有可剖析的项（指定了表、记为跳过），后来有人把一列 记成状态类，或者日期列变了，「需要剖析的表」永远漏掉它。现在按当前要做的检查对上次剖析的检查项（kind、target），多出了 码值、日期检查就要剖析，原因 new_checks；上次是空表而跳过的仍不算（不发查询不知道有没有数据），界面和 409 的说法写明。 due_reason 改收 plan_checks 列出的检查，没人用的 profile_checks 去掉。 - 停止一个排队中的任务时，排队那一步没停成（刚被后台认领）要回滚，回滚让读到的 job 属性全部过期，再读 job.id 就在异步会话里 同步加载（MissingGreenlet），接口 500。起草的 cancel 在 main 上就是这样写的，剖析照抄了；两处都先把 id、状态取出来。 新测试在旧代码上复现了这个 500。	2026-10-15 19:28:17 +08:00
ThearchyHelios	6c728aaacd	数据剖析按复核意见修三处：没来得及收尾的表照实说、停止中的说法、展开的进行中一行不跟着查询数重取 ... - 服务重启的说明不再一律说「做完的项已写进数据目录」（R1 前端这一侧）。目录只在一张表结束时和它的结果一起写：停止、关停 服务时正在剖析的那张来得及收尾，做完的项照常写进去（服务端记部分完成，原因写「已做完的 N 项照常写进了数据目录」）；进程 被杀、下次启动时才标中断的那张没来得及收尾，这次的结论一项都没写进去，服务端把它记成已停止、查完的项改记跳过。界面按逐表 的状态认出这样的表（已停止却有开始时刻：正常收尾的表不会是已停止，没开始的表没有开始时刻），服务重启、停止的说明里点名它 「剖析到一半服务就停了，没来得及收尾，这次的结论没有写进目录，保留原来的结论」，有别的表收了尾才说「其余做完的项已写进数据 目录」；逐表一行用服务端给这张表的原话（查完的几项没写进目录），一项都还没查完、原因就是任务那一句时写「没来得及收尾」。 不说「做完的项没写进去」：被杀时它可能一项都还没查完。 - 「正在停止」不再说等正在执行的那条查询结束（R4）。停止时服务端不等这条查询（它在发过的查询里记失败），库那边按单条时限截止 它，收尾写完停止就答；单条时限设得长时，旧说法会让人以为要等满时限。改成「正在执行的那条查询不再等待，由数据库按单条时限 截止；已做完的项照常写进目录…」，和服务端的说法一致；接口、停止逻辑的注释同步改。 - 展开进行中的那一行，只在一项检查开始、结束时重取这张表的完整结果（R5）。服务端只在这两个时刻写检查清单、正在做哪一项和发过 的查询，其间每发一条查询只加查询数和用时；以前重取的依据带着查询数，进行中几乎每次轮询（1.5 秒）都多取一份没变的结果， 一张 40 条查询的表约多 40 次。依据改成状态、结束的项数和正在做哪一项。 检查脚本 check-catalog-profile：伪造的停止照服务端分「来得及收尾」（正在剖析的那张记部分完成、原因写做完的已写进目录）和 「没来得及收尾」（记已停止、查完的项改记跳过、说法照服务端）两种；停止那一节跟着改（正在剖析的那张是部分完成，汇总 「完成 1，部分完成 1，已停止 3」），「正在停止」的说法改查新句子；服务重启一节加关停时收了尾、进程被杀（查完一项、一项都 没查完）三种；表详情一节加剖析到一半进程被杀；进行中一节加一条：展开进行中的一行后只多发查询时不再请求 tasks/{seq}，一项 结束、换下一项时重取一次。先在改动前的代码上跑过，这几条照复核说的那样不通过（展开后多取了 2～3 次、停止中还是旧说法、 服务重启一律说已写进），改完通过。	2026-10-15 19:18:17 +08:00
ThearchyHelios	e7ab6a14c5	数据剖析的浏览器检查：新建 check-catalog-profile，check-catalog 里同步接口那套剖析检查删掉 ... check-catalog-profile 照 check-catalog 的写法：数据源、目录、剖析任务、起草任务都用 page.route 伪造（虚构的网店业务库， 表名 orders、customers、visits 这类），任务怎么往前走由检查自己推，没配的写请求一律 503，最后核对真库没变。查的是： 范围与个数（按清单行上的 profile_due、profile_checks、视图算）、按表写的预算和这次最多约几条查询、只读一条一条发可随时 停止的说明、进行中逐表行和各类检查进度、页头进度入口和提醒、停止、展开逐表的检查清单和发过的查询、结束后的汇总筛选和 重试、止损和服务重启、409 六种情况加老服务端没带机读码、和起草互相排队的说法、表清单的「剖析」一列和「需要剖析」筛选、 表详情的一节和「剖析这张表」（含正忙时说清这张表在不在那个任务里）、设置两项新字段和被拒时报错落到那一项、窄屏。 同步接口那一节里顺带查的码值弹窗（光标落在空着的码值上、回车保存只换那一列、填完回到结果接着下一列）一并搬过来。 check-catalog 删掉旧的剖析设置、剖析、剖析 409 三节，假服务端的同步剖析接口换成剖析任务（取进行中、最近一次答空， 建任务一律 503）；其余各节不动。check-all 的 ORDER、ESTIMATE 登记 catalog-profile。 界面顺带改三处（截图里看出来的）：结束后的进度写做完了几张（同起草，停止、失败、跳过的不算）；没开始就停下的表不写 各类检查的 0/N；表详情一节里码值候选不在目录里时不给「填写含义」（码值弹窗改的是目录里那一项）。	2026-10-15 18:33:46 +08:00