 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 |
|