5 Commits

Author	SHA1	Message	Date
ThearchyHelios	095cc4c8ab	SQL 差异说明收尾（第 2 轮）：PostgreSQL 符号运算符和 || 混用不判等价；条件写在聚合里、时间窗口、反连接、经主键定死的列不再说错 ... - 保真守卫（_misread）：PostgreSQL 写成符号、sqlglot 却当成 LIKE 那一级来读的运算符（~、~*、~~、~~*、@@、-|-、@> 等） 和别的二元运算混用时拦下（PostgreSQL 里它们和 ||、& 同级、从左往右，status ~ 'p' || 'x' 是 (status ~ 'p') || 'x'）； 另拦 PostgreSQL 的前缀 @、|/、||/、COLLATE 后面的 ::；不知道是哪种库时拦块注释里套着的 /*、紧跟着字的 --、#、双引号 括起来的名字（MySQL 默认的 sql_mode 里是字符串）。都只给兜底，附原文的逐行对照。 - 条件写在聚合的参数里（SUM(status = 'paid')、COUNT(… OR NULL)、COUNT(NULLIF(…))、SUM(amount * (1 - is_deleted))） 算作这一边对这一列有条件（_Usage 的 case），另一边多出同一列上的 WHERE 条件时不再说「这一边没有这个条件」，只给兜底。 - 时间：timed 认 BETWEEN 和时间列上 LIKE 像日期的模式（paid_at LIKE '2026-09%'），时间窗口不再被说成有效行过滤； 「另一边没有按时间筛选」之前看另一边可能是时间窗口的条件（聚合参数里的时间比较、date_key、stat_month 这类列、 20260901 / 202609 这类整数、上下界一对），有就不说；认不准是不是时间列的窗口（_window_like）不说成有效行过滤。 两边的时间列在不同的表上时写成「表.列」。 - 反连接：用到 LEFT JOIN 可空一侧的列的条件（WHERE r.id IS NULL、r.order_id IS NULL）不说成有效行过滤，时间列在 可空一侧时也不说按它筛时间。 - 给了表结构时，聚合参数所在的表的键在组里定死了（按 u.id 分组时的 u.city），MAX 对 MIN、AVG(DISTINCT) 对 AVG 不说。 - 另一边原文也 LEFT JOIN 了、规范化因为结果不怕重复去掉了的表，不说「另一边没有关联」。 - 回归语料：收尾第 1 轮之后复验报的全部 blocker / major 收进 sql_pairs（_DIFF_R5、_DIFF_TIME_R5、_SAME_HARD_R5、 _SAME_SCHEMA_R5 执行；REGRESSIONS_R5、EXPLAIN_TRAPS_R5 只查结论），新增对应的测试。 - 模块说明照实补上：新增的守卫、时间条件的认法、只给兜底的情况、收窄换来的代价、MySQL 按默认 sql_mode 读的假设。 认出等价的比例：语料（SQLite，给表结构）169 对里 157 对，和改动前一样；PostgreSQL、MySQL 也不变；不知道是哪种库时 少认 1 对（same:quoted-names，双引号括起来的名字）。	2026-10-06 08:10:41 +08:00
ThearchyHelios	6767b5f2fc	SQL 差异说明收尾（第 1 轮）：不靠约束改写、解析保真守卫、具体说法只在简单形状上说四类 ... - 去掉所有依赖表约束的改写：凭主键 / 唯一键去掉 LEFT JOIN、去掉 DISTINCT，COUNT(列) 当 COUNT(*)，凭 NOT NULL 去掉 IS NOT NULL（_unique_key_bound、_constraint_rewrites、_not_null_source 删掉）。SQLite 的类型亲和、COLLATE、部分唯一 索引、MySQL 的隐式转换都会让「唯一」不成立，宁可认不出；约束只拿来让说明少说（schema_cache 的外键也读进来）。 - 解析保真守卫（_misread，按方言切词、按括号深度分层）：MySQL / MariaDB / 不知道方言时字符串里的反斜杠转义、1_000 和 0o17 这类数字、挨着写的字符串常量、同一层里没加括号地混用比较运算和 IS / IN / LIKE / BETWEEN / 另一个比较、按位运算 （含 COLLATE）和别的二元运算混用、XOR、不知道方言时的 ||、MySQL 以外的 &&：不在语法树上判等价，只给兜底，text_diff 给原文的逐行对照；normalize_sql 逐词规范化时数字和紧跟着的名字算一个字面量。 - 具体说法重写（_Explainer）：只在两边都是简单形状（一段 SELECT、实表、普通连接，没有派生表、合并、窗口函数）时说， 只说四类——底层表上的时间列不同、一边多一个只涉及一张表的列和常量比的筛选条件（另一边对这些列没有任何条件、不是 被蕴含的、按取值逐段算过不是恒为真）、顶层聚合函数或去重不同、关联的表或关联类型不同（后面没有内连接引用可空一侧）； 每句先确认真会影响结果（条件恒为假、结果看不见行、参数在组里定死、只取一行、表结构的键 / 外键说明不起作用时不说）， 别的一律兜底。 - 回归语料：第 3 轮补充之后的复验报的全部 blocker / major 收进 sql_pairs（_DIFF_R4、_SAME_HARD_R4、_SAME_SCHEMA_R4 执行；REGRESSIONS_R4、DIALECT_SAME_R4、CONSTRAINT_TRAPS_R4 只查结论，约束陷阱另造小库执行），执行比对复验者列的 9 个 改松后拦不住的反例也收进来；旧的具体说法测试按新规矩改写。 - 模块说明照实写：等价怎么判、不靠约束、保真守卫、只给兜底的情况、已知做不到的。 认出等价的比例（给表结构）：169 对里 163 → 157（96% → 93%），少的 6 对都是要靠约束才成立的；不给表结构 148 / 156 不变。	2026-10-05 17:35:51 +08:00
ThearchyHelios	08f75d4002	SQL 差异说明重做（第 3 轮）：堵上第 2 轮复验报的不保持语义的规范化，认出复验指出的等价改写，具体说法只说真会影响结果的不同 ... 为什么：第 2 轮复验报了 14 个 blocker（判了等价、结果却不同）和 11 个 major（意思一样，却说了具体的不同；说法 自相矛盾）。等价判定的框架（两边各自规范化、语法树一字不差才算等价）不变，这一轮逐个查清是哪一步不保持语义、 哪一处说法没先确认「真的不同」，按类堵上，并在执行比对语料里收进全部反例。 等价判定（backend/app/data/sql_semantics.py）： - 外连接改内连接（_rejects）分「一定是空值」和「一定不成立」两种：NOT 只能套前者，NOT IN 子查询、NOT IN ()、 x op ALL (…)、NOT (x = ANY …)（含解析成函数的 ALL (ARRAY[…])）、PostgreSQL 的 || 都留得下没关联上的行。 - 改列别名、EXISTS 写成 SELECT 1、去掉列名、CTE 的列改名之前，先看本段的 WHERE、ON、相关子查询还按名字引用不引用 这些别名（_alias_refs，SQLite 的 WHERE、ON、相关子查询都认列别名，真实的 SQLite 上试过）；qualify 遇到子查询引用 外层列别名时不走认列那一级。 - USING 的列和列别名同名不改写（ORDER BY 先认别名）；派生来源的列同名不走认列那一级（SQLite 认第一个）；没有 GROUP BY、别处也没有聚合的 HAVING TRUE 留着（PostgreSQL 里只出一行）。 - RANDOM() 这类不确定的函数轻量一级也不走；SQLite 双引号里的名字只看这条语句里看得见的表（_column_in_scope）； 子查询的别名遮住外层、又认不准是哪一个的不走规范化（SQLite 里层找不到列就往外层找）。 - MySQL：/*! … */ 会执行、! 比比较结合得紧，不在语法树上判等价；-- 后面不跟空白是两个减号，先拆开再解析； BETWEEN 上下界类型不同或不是常量时不改写。 - 函数节点记下原文写的名字（_mark_surfaces）：SQLite 的 MOD() 和 %、PostgreSQL 的 LOG10(x) 和 LOG(10, x) 解析成 同一个节点，记下名字就不会判等价；同义写法按方言文档列在 _SAFE_RESPELLINGS。 - 自己压测找到的老问题：结果看行出来先后的一段（GROUP_CONCAT 等）按 WHERE 把 LEFT JOIN 改成内连接，SQLite 的 扫描先后真的会变（EXPLAIN QUERY PLAN 一个先扫 refunds、一个先扫 orders），这样的一段不再改写。 认出复验指出的等价改写（每一步都写了为什么保持语义，执行比对守门）： - EXISTS 里的去重、分组、UNION / UNION ALL，IN 里不影响取值集合的 GROUP BY、DISTINCT、UNION；分组后 COUNT(*) >= 1。 - 不分组、只取可空一侧跳过空值的聚合时 LEFT JOIN 写成内连接（COALESCE(SUM(r.amount), 0) 等）；ON 之外没用到、 结果不怕重复的行的 LEFT JOIN 去掉；同一组 AND 里已经保证、或表结构里确定不为空（nullable、主键）的 IS NOT NULL 去掉；给了表结构、类型一样时按关联条件相等的两列换成同一列（分组、排序、选出来的列）。 - 一模一样的分组键、排序键；SQLite 的负数 LIMIT、PostgreSQL 的 LIMIT NULL、LIMIT 的整数算式。 具体说法：被关联条件定成相等的列、IN / EXISTS 里的去重分组、只取可空一侧的聚合、没用到又不怕重复的 LEFT JOIN、 各支自己已经去重的 UNION ALL、只出一行时的排序、自己关联自己的关联条件，都不再说成具体的不同（只给兜底）； <>、NOT IN、NOT LIKE 照实说「和 X 为空的行」也筛掉了，NOT 套几个条件的说「只保留 NOT (…) 的行」。 normalize_sql：解析时会丢掉写法的（会执行的注释、!、MOD() 这类重新生成换了名字的函数）改按原文逐词规范化， 会执行的注释里的代码算结构；只改字面量的照旧同一个模板（补了测试）。 测试：fixtures/sql_pairs.py 收进第 3 轮的反例（执行的 _DIFF_R3 / _SAME_R3 / _SAME_TYPED_R3 / _SAME_SCHEMA_R3 / _SAME_HARD_R3，只查结论的 REGRESSIONS_R3 / DIALECT_SAME_R3），schema_cache 带上 nullable 和 primary_key（和探查 出来的一样）；专挑写法差异的那组数据加了 'State'。	2026-10-05 14:19:55 +08:00
ThearchyHelios	f16860f704	SQL 差异说明重做（第 2 轮）：规范化只留能讲清为什么保持语义的几步，结果看行出来先后的一段不动来源；具体说法先确认两边真的不同、另一边真的没有，其余给兜底 ... 为什么：第 2 轮复验抓到第 1 版规范化里一批不保持语义的改写（15 个 blocker），说明里一批假话、矛盾话（10 多个 major）。根子是借用了 sqlglot simplify 等现成改写、又把「相等」当成「一样」、没管结果看行出来先后的查询；说明这边 是先改名再比、只看这一段有没有那个条件。这一轮把改写收窄到每一步都讲得清为什么保持语义，说明这边每句话都先验证。 规范化（backend/app/data/sql_semantics.py）： - 去掉 sqlglot 的 simplify（Decimal 折叠 0.1 + 0.2、-(-x) 化成 x、三项加乘拍平合常量、BETWEEN SYMMETRIC 丢了 SYMMETRIC）、pushdown_projections、HAVING 挪进 WHERE（MySQL 不分大小写时同组的值各不一样）、只有一列的 IN 列表 写成 =（SQLite 里 a IN (b) 是 a = +b）。只留自己写的几步：AND / OR、比较两边、一个节点的加乘两边排序，NOT 套 比较翻过来，BETWEEN 拆开，IN 常量列表去重排序，COUNT(1)、MIN/MAX(DISTINCT)、IIF / IF 写成 CASE、CASE ELSE NULL、 恒真的 1 = 1 去掉，IS NOT NULL / NOT LIKE 各方言统一成 NOT (…)。 - 新增 _Sensitivity：取行（含有 ORDER BY 并列）、DISTINCT ON、窗口函数、GROUP_CONCAT 这类聚合、聚合里的散列、当成标量 的子查询，以及去重、分组、MIN/MAX 留下的值「相等却不一样」（MySQL 字符串、PG numeric、算出来的表达式）的一段， 连同给它供行的子查询、CTE，都不调换来源、不排 GROUP BY 键、不改 DISTINCT、不并子查询。SQLite 的逗号连接和 CROSS JOIN 按原文分开（SQLite 不调换 CROSS JOIN 两边）。 - 列名表（CTE、子查询）写进里面那段的别名，实表别名带列名、递归 CTE（含 SQLite 不写 RECURSIVE、CTE 引用自己或后面的）、 BETWEEN SYMMETRIC、FETCH WITH TIES 不走规范化；FETCH FIRST 写成 LIMIT；USING 只在简单写法下写成 ON。 - EXISTS 改写前先查聚合（含 ORDER BY 里的）和 OFFSET；合并只调换最外层不取行的 UNION ALL（PG/MySQL 另加按位置排序、 各支列名一样的嵌套）；后面有 RIGHT / FULL JOIN 时内连接不挪进 WHERE、开头的来源不调换。 - 子查询并进外层自己写（_merge_derived：只并内连接一侧、只筛行选列的），引用多次的简单 CTE 每处写回一份后整条语句 的别名重新改成互不相同的（压测撞到的：同一个 CTE 并进外层和相关子查询两处，里层别名遮住外层）；外层 WHERE 只挪进 分组子查询的 HAVING（同一个值）。几个来源的 SELECT * 先写成各来源的 t.*（sqlglot 展开 * 时把实表排在子查询前面）。 - 解析丢了写法的不在语法树上判等价：0x10 和 x'10' 这类字面量、换了名字的类型名（SQLite 的 STRING 是数值亲和）； SQLite 不带表名、带双引号、表结构里没有的列名保留大小写和引号（找不到这一列时被当成字符串）。 差异说明： - 换了表的一边照它自己的表说（以前把 B 改名成 A 的表，中文名、detail 归错表）。 - 新增 _Range：同一个对象只和常量比的条件按取值逐段算，留下的行一样的不说（IN 和 OR、冗余 IS NOT NULL、拆成两段的 时间、COUNT(*) > 1 和 >= 2）；关联条件比相等关系的分组；聚合只在参数是列时说。 - 新增 _Usage：说「另一边没有这个条件 / 没有按时间筛选」之前，看另一边整条语句（含相关子查询、CTE、CASE、判空时连 聚合参数）是否用这一列筛选；条件子查询里不带表名的列没给表结构时不拿来说具体的。 - 子查询要外面写法一模一样（含 NOT、IN 左边的列）才配对，位置照实说「id NOT IN 的子查询」；EXCEPT 按先后逐支比； order 只在最外层、没取行、没 DISTINCT ON / 窗口函数时说；LEFT 对 INNER 只在最外层、可空一侧没进 WHERE、结果不只是 可空一侧的聚合时说；DISTINCT 对同列 GROUP BY、MySQL 表名只差大小写不说成不同；互相矛盾的一对不说。 测试：tests/fixtures/sql_pairs.py 加 nums 表和一组专挑写法差异的数据（0.1 + 0.2、像数字的文本、'SH' / 'sh'）， 第 2 轮反例收进语料（_SAME_HARD 20 对、_SAME_R2 11 对、_DIFF_R2 36 对进执行比对；REGRESSIONS_R2 21 对、 DIALECT_SAME_R2 6 对、KNOWN_UNRECOGNIZED 4 对各方言只查结论）；执行比对共 7 组数据、372 对，标 same 而没认出的 不许有具体说法；test_sql_semantics.py 补第 2 轮的说法用例和 normalize_sql「只改参数」的用例。这些新用例在上一版 上有 109 处失败。 验证：test_sql_semantics + test_verify_agent + test_sql_equivalence 973 passed；全量 -n 8：7853 passed、11 skipped。 等价改写 124 对认出 120 对（97%），不给表结构 117 对（94%）。复验者的脚本：vsprobe 变异压测 6 个种子约 4.3 万对无 误判等价；在私起的 PostgreSQL 18、MySQL 8.0 上重跑 vsadv 全部语料无 blocker；advfp 的 180 对等价对上具体说法 0 条； 自己的压测 3 个种子各约 1.5 万条可执行，规范形式相同的组执行结果全一致。	2026-10-05 12:01:08 +08:00
ThearchyHelios	c55b1983f6	SQL 差异说明重做（第 1 轮）：先判等价、再说差在哪——规范形式一字不差才算等价，具体说法只说有把握的，其余给兜底并附规范化后不同的行；等价结论拿 SQLite 执行比对守门 ... 为什么重做：过去五轮按方面归纳任意 SQL，每轮修好一批又冒出一批（第 5 轮还回退过「只在 IN / EXISTS / 标量子查询里用到的 CTE 里的不同」），收不拢。改成先判两条 SQL 是不是一回事，不是的话只说有把握的不同。 做了什么（backend/app/data/sql_semantics.py）： - 新增 explain_sql_diff(a, b, dialect=None, *, schema=None, names=None, labels=("A", "B")) -> SqlDiff （equivalent、items、fallback、text_diff、level）。两边各自规范化，每一步只做保持语义的变换；同一级的两个 规范形式语法树逐节点一样才算等价（不比生成的 SQL：sqlglot 生成 SQLite 时把 CAST(x AS DATE) 写成 DATE(x)）， 否则一律不等价、条目一定不为空。三级：optimizer（sqlglot 的 qualify、eliminate_subqueries、merge_subqueries、 eliminate_ctes、pushdown_projections、simplify，给了数据源的 schema_cache 就按它认列、展开 SELECT *）、 light（不认列）、parsed（只统一大小写、空白、引号）。 - 不用的 sqlglot 规则：unnest_subqueries（OR 里的标量子查询改成 CROSS JOIN，子查询没有行时整条都没了）、 canonicalize（日期比较加 CAST，SQLite 里 CAST(… AS DATE) 取的是数字）、normalize（合取范式人读不懂）； simplify 去掉同一列上比较的合并、字符串常量比较、等式移项、DATE_TRUNC 改区间（取决于列类型、排序规则、方言）； merge_subqueries 不并外连接可空一侧算出来的列。 - 本模块自己的几步：去括号、ASC、OFFSET 0，COUNT(1)→COUNT(*)，IN 列表去重排序，EXISTS 写成 SELECT 1， DISTINCT↔GROUP BY，原样透列的子查询换掉，RIGHT JOIN→LEFT JOIN，WHERE 筛掉了没关联上的行的外连接写成内连接， 内连接写成逗号连接，起规范的名字（CTE 叫 cte1…、CTE 的列叫 c1…、别名按表名和层数，同名来源排列着试）， 交换律成立的地方排序。 - 具体说法的门槛：两段读的来源对得上（一样，或只差一处说得清的）才逐项比时间列、筛选条件、聚合与去重计数、 选出来的列、分组键、HAVING、取行和排序、UNION 还是 UNION ALL；条件里的子查询两边各一个、外面一样的往里比 （第 5 轮回退的 IN-CTE 反例在这里说出来）；原文是 LEFT / RIGHT JOIN、规范化成内连接或调了方向的照原文说； 牵涉 CTE 算出来的列、自己关联自己、说不准的子查询的不说具体的；两边给人看一样的不说。 - 兜底：一条具体说法都没有时给 aspect="other"「两条 SQL 的写法不同，未能归纳成具体差异，请对照原文」，只覆盖 一部分时追加「另有未能归纳的差异，请对照原文」，fallback 为真；text_diff 是 difflib 比两边 sqlglot pretty 的输出，最多 40 行。 - diff_facets 签名不变，交给 explain_sql_diff 比两份 facets 记下的原文，返回它的 items。normalize_sql 判 「只有参数不同」不变，补了测试。 守门（tests/test_sql_equivalence.py、tests/fixtures/sql_pairs.py）：虚构库（users、stores、orders、 orders_archive、order_items、refunds、payments、shipments）上 5 组固定种子的数据加 1 组极端数据（空值、重复、 边界值、悬空外键、空表）。305 对 SQL（113 对已知等价、192 对不许判等价，含复验者以前造的、在这几组数据上结果 不同的 91 对）在不给和给表结构两种情况下各判一次：结果不同的绝不判等价，标 diff 的不判等价，换个先后问结论 一样。旧测试五轮复核里报过不同的 234 对、意思一样的 56 对（SQLite / PostgreSQL / MySQL）原样收进来只查结论。 压测（变异 + 等价改写，每个种子约 1.87 万条）时找到、已经堵上的不保持语义的改写： - merge_subqueries 把外连接可空一侧的常量列并进外层；merge 时同一个 CTE 并进外层和相关子查询两处互相遮住； - 没给表结构时 qualify 把 WHERE / GROUP BY / HAVING 里和列别名同名的名字当成别名（SQLite 先认列），把 SELECT 列表里和前面别名同名的名字展开（库里不认 SELECT 列表里的别名）：这时不出 optimizer 这一级； - UNION（去重）、INTERSECT 调换各支：去重留先出现的值（SQLite 里 2 和 2.0、MySQL 不分大小写时 'SH' 和 'sh'）； UNION ALL 带 LIMIT、按名字 ORDER BY 的也要看哪支在前，SQLite 合并结果的排序规则取最左一支：现在只在调换 不改变结果时排；SQLite 从子查询读 UNION 的类型亲和； - 一元加号在 SQLite 里去掉类型亲和、解析时却丢了；ORDER BY 别名换成表达式后撞上另一个别名； - 没有 ORDER BY 的 LIMIT、聚合里既不分组也不聚合的列：调换来源、DISTINCT 写成 GROUP BY、RIGHT 写成 LEFT 都会改变实际取到的行，这样的一段不做；两边都写了 COLLATE 的比较不对调。 验证：tests/test_sql_semantics.py + tests/test_verify_agent.py 519 passed，tests/test_sql_equivalence.py 307 passed，全量 -n 8：7706 passed、11 skipped。已知等价的 113 对认出 111 对（98%），不给表结构时 109 对 （96%）。压测 4 个种子各约 1.5 万条可执行：规范形式相同的组执行结果全一致，能执行的规范形式结果和原文一致 （带 CAST 的不比：生成 SQLite 时写法变了），生成的等价改写认出 2113/2115；复验者留下的 1201 对里可执行的 440 对没有误判等价，结果相同的 302 对认出 276 对。 仍做不到的（只给兜底或认不出等价）见模块说明：IN 子查询和 EXISTS 互换、窗口函数前后按分区键筛、三项以上的 加乘换结合、和方言有关的同义写法、SQLite 里套一层子查询的 UNION、去重 UNION 调换各支、LATERAL、递归 CTE、 没给表结构时别名和列同名的。假设列没有声明非默认的排序规则（SQLite 比较两列取左边那列的，表结构里看不到）。	2026-10-05 09:28:08 +08:00