SQL Checker Guide: Syntax, Complexity, and Validation SQL 检查器完整指南：安全验证语法、方言、复杂度、执行计划、业务逻辑与数据风险

Check SQL structure in your browser在线检查 SQL 结构与复杂度

Paste a sanitized query below. The checker runs only in this browser, does not connect to a database, and does not upload or save the SQL.

在下方粘贴已脱敏的 SQL。本检查器完全在当前浏览器中运行，不连接数据库，也不会上传或保存查询内容。

Quick answer: what an SQL checker can and cannot prove 快速答案：SQL 检查器能够与不能证明什么

Choose the tool from the question. “Will this parse in PostgreSQL?” needs a dialect-aware parser. “Why is this hard to maintain?” needs structural review. “Why is it slow on this data?” needs the target database's actual plan. “Is revenue correct?” needs data tests and reconciliation.

应从问题选择工具。“能否在 PostgreSQL 解析”需要方言解析器；“为何难维护”需要结构审查；“为何在这些数据上慢”需要目标数据库实际计划；“收入是否正确”需要数据测试与核对。

Separate syntax, structure, execution, and semantics 区分语法、结构、执行与语义

A mature workflow connects these layers instead of treating a green parser result as approval. Every finding should state its scope and required next evidence.

成熟流程会连接这些层级，而不是把解析器通过视为最终批准。每个发现都应说明适用范围和下一步所需证据。

Use a dialect-aware parser and schema context 使用方言感知解析器与表结构上下文

SQL dialects differ in quoting, date literals, limits, functions, QUALIFY, null ordering, aliases, and procedural extensions. Select the exact engine and version where possible. A generic parser may reject valid vendor syntax or accept a construct that the target engine interprets differently.

SQL 方言在引号、日期字面值、限制、函数、QUALIFY、NULL 排序、别名和过程扩展上不同。应尽量选择准确引擎与版本。通用解析器可能拒绝有效厂商语法，或接受目标引擎解释不同的结构。

Parsing without schema cannot confirm tables, columns, types, permissions, overloaded functions, or implicit casts. Use an approved development database or schema-aware validator for those checks. Never treat successful parsing as proof that the query can run safely.

没有表结构上下文的解析无法确认表、字段、类型、权限、重载函数或隐式转换。应使用批准的开发数据库或表结构感知验证器，并且不能把解析成功视为查询可安全运行的证明。

Use structural checks to guide review, not assign guilt 用结构检查指导评审，而不是简单定罪

Structural analysis can count joins, nested levels, CTEs, subqueries, window specifications, aggregates, repeated expressions, wide projections, and branching. High counts identify review effort and possible failure mechanisms, but a long query can be correct and efficient while a short query can produce a Cartesian product.

结构分析可以统计连接、嵌套层、CTE、子查询、窗口定义、聚合、重复表达式、宽投影和分支。高计数能提示评审成本与潜在机制，但长查询可以正确高效，短查询也可能产生笛卡尔积。

Convert each warning into a question: Does every join have an intended key and cardinality? Does nesting hide repeated work? Do windows share ordering? Is a complex stage named and testable? Complexity scores prioritize inspection; they do not automatically justify rewriting.

应把每个警告转换为问题：每个连接是否有预期键与基数？嵌套是否隐藏重复工作？窗口能否共享排序？复杂阶段是否命名且可测试？复杂度评分用于确定检查优先级，而不是自动证明需要重构。

Build an SQL review evidence ladder instead of trusting one green check建立 SQL 审查证据阶梯，不要依赖一次绿色检查

Each SQL check answers a different question. A parser can reject invalid grammar but cannot prove that a join returns the intended population. A structural checker can highlight nested layers and fan-out risk but does not know table sizes or indexes. An optimizer plan describes the target database's chosen operations, while result tests establish whether the query respects business rules. Record the evidence at every layer and stop treating one successful layer as approval for the next.

每种 SQL 检查回答的问题不同。解析器可以拒绝无效语法，却不能证明连接结果属于预期业务范围；结构检查器可以提示嵌套层级与扇出风险，却不了解真实表大小和索引；优化器计划说明目标数据库选择的操作，而结果测试用于判断查询是否满足业务规则。应分别记录每一层证据，不能把某一层成功当成下一层已经获批。

Use the target database for optimizer and runtime evidence 使用目标数据库获取优化器与运行证据

Only the target engine knows its catalog statistics, indexes, partitions, constraints, parameter values, memory, parallelism, and physical storage. Estimated EXPLAIN shows planned operators and estimates; an actual plan adds runtime rows, loops, time, spills, and sometimes reads. Running an actual plan can execute side effects, so use safe statements and approved environments.

只有目标引擎了解其目录统计、索引、分区、约束、参数、内存、并行和物理存储。估算 EXPLAIN 显示计划算子与估算，实际计划增加运行行数、循环、时间、溢写和部分读取。实际计划可能执行副作用，因此只能在安全语句和批准环境中使用。

A checker that never connects to the database cannot know the actual plan. It can still reveal structural questions worth taking to the plan, such as repeated correlated layers, multiple sorts, or many-to-many risks.

不连接数据库的检查器无法知道实际计划，但仍可揭示值得在计划中核实的结构问题，例如重复相关层、多次排序或多对多风险。

Prove business correctness with invariants and edge cases 使用不变量与边界案例证明业务正确性

A syntax-valid query can silently lose unmatched entities, multiply measures, choose nondeterministic rows, confuse NULL with zero, or apply the wrong time basis. Define one-row meaning, preserved population, metric formulas, permitted exclusions, and expected totals. Then test zero, one, and many matches, null keys, duplicates, ties, empty groups, late data, and threshold boundaries.

语法有效的查询仍可能静默丢失未匹配实体、放大指标、选择不确定记录、混淆 NULL 与零或使用错误时间口径。应定义单行含义、保留总体、指标公式、允许排除和预期总量，再测试零/一/多匹配、空键、重复、并列、空组、延迟数据与阈值边界。

Compare row-level differences by stable keys plus aggregate controls. Two wrong queries can share the same total, and two correct queries can order rows differently. Match the comparison method to the contract.

应按稳定键比较记录级差异，同时使用汇总控制。两个错误查询可能总量相同，两个正确查询也可能只在顺序上不同，因此比较方法必须符合契约。

Sanitize SQL before using an online checker 使用在线检查器前对 SQL 脱敏

Remove credentials, connection strings, tokens, secrets, personal data, customer identifiers, sensitive literal values, proprietary comments, and unnecessary object names. Replace them with consistent placeholders that preserve structure. Confirm the tool's retention, training, access, region, and deletion policies and use only approved services.

移除凭据、连接字符串、令牌、密钥、个人数据、客户标识、敏感字面值、专有注释和不必要对象名，并用保持结构一致的占位符替换。确认工具的保留、训练、访问、区域与删除政策，只使用批准服务。

Prefer offline or controlled tools for regulated or confidential workloads. An SQL checker does not need production data to review text structure. If execution is required, use a sandbox with least privilege, read-only access where possible, bounded resources, and synthetic or approved test data.

受监管或机密负载应优先使用离线或受控工具。文本结构审查不需要生产数据；必须执行时，使用最小权限沙箱，尽量只读、限制资源，并采用合成或批准测试数据。

Use a seven-step SQL checking workflow 使用七步 SQL 检查流程

1. Define intent. State output grain, population, and metrics.
2. Sanitize. Remove secrets and sensitive literals.
3. Parse. Use the correct dialect and version.
4. Inspect structure. Review joins, nesting, windows, aggregation, and repetition.
5. Validate data. Run edge cases and reconcile results in an approved environment.
6. Inspect execution. Read the actual plan and resource evidence.
7. Record decisions. Save findings, fixes, limits, owner, and regression tests.

1. 定义意图。 说明输出粒度、总体与指标。
2. 脱敏。 移除密钥与敏感字面值。
3. 解析。 使用正确方言与版本。
4. 检查结构。 评审连接、嵌套、窗口、聚合与重复。
5. 验证数据。 在批准环境运行边界案例并核对结果。
6. 检查执行。 阅读实际计划与资源证据。
7. 记录决策。 保存发现、修复、限制、负责人和回归测试。

Know what a green result still leaves open 明确绿色结果仍未解决什么

• Confirm exact engine, version, and checker capability.
• Verify SQL has been sanitized and tool use is approved.
• Review every join key, cardinality, group, window, and filter boundary.
• Run schema-aware checks for objects, types, and permissions.
• Test adversarial data and compare stable business keys.
• Use actual plans for real data and representative parameters.
• Record unresolved assumptions rather than treating warnings as proof.

• 确认准确引擎、版本和检查器能力。
• 确认 SQL 已脱敏且工具使用获得批准。
• 评审每个连接键、基数、分组、窗口与过滤边界。
• 使用表结构感知检查验证对象、类型与权限。
• 运行对抗数据并比较稳定业务键。
• 使用实际计划检查真实数据与代表参数。
• 记录未解决假设，不把警告当作证明。

Work through an SQL join that passes syntax but doubles a total逐步检查一条语法通过却把总额翻倍的 SQL

The query below joins two one-to-many child tables before aggregating. One order with two items and two payment records creates four joined rows, so both amounts can be counted more than once. A parser reports valid syntax; the business defect appears only when the reviewer models cardinality and reconciles an order-level invariant.

下面的查询在聚合之前连接两个一对多子表。一笔订单如果包含两个商品行和两条支付记录，连接后会产生四行，因此商品金额和支付金额都可能被重复累计。解析器会报告语法有效；只有审查者分析基数并对账订单级不变量时，才会发现业务缺陷。

SELECT o.order_id,
       SUM(i.line_amount) AS item_total,
       SUM(p.amount)      AS paid_total
FROM orders o
JOIN order_items i ON i.order_id = o.order_id
JOIN payments p    ON p.order_id = o.order_id
GROUP BY o.order_id;

Aggregate each child relation to the intended grain before joining, then verify the result against independent order totals. This pattern is not automatically correct for every refund, split-payment, currency, or status rule; those definitions still need explicit tests.

可以先把每个子关系聚合到预期粒度，再进行连接，并使用独立订单总额核对结果。该模式并不会自动处理所有退款、拆分支付、币种或状态规则，这些定义仍需显式测试。

WITH item_totals AS (
  SELECT order_id, SUM(line_amount) AS item_total
  FROM order_items
  GROUP BY order_id
), payment_totals AS (
  SELECT order_id, SUM(amount) AS paid_total
  FROM payments
  WHERE status = 'settled'
  GROUP BY order_id
)
SELECT o.order_id,
       COALESCE(i.item_total, 0) AS item_total,
       COALESCE(p.paid_total, 0) AS paid_total
FROM orders o
LEFT JOIN item_totals i    ON i.order_id = o.order_id
LEFT JOIN payment_totals p ON p.order_id = o.order_id;

Archive the sanitized query version, dialect, schema assumptions, test fixtures, expected results, plan evidence, reviewer, and date. Do not record secrets or production row values. A reproducible review explains why the query was accepted, not merely that a checker displayed a low-risk label.

应归档脱敏查询版本、方言、表结构假设、测试数据、预期结果、执行计划证据、审查人和日期，但不要记录秘密或生产行值。可复现审查需要说明查询为什么被接受，而不是只保存“检查器显示低风险”的结论。

Diagnose a query that passes syntax but doubles revenue 诊断语法通过却收入翻倍的查询

Suppose a checker reports valid syntax, yet a report doubles revenue. Orders were joined to both items and payments, creating item-payment combinations before SUM. A parser cannot know the intended grain. Profile matches per order, compare distinct fact keys, pre-aggregate independent branches, and reconcile to the ledger. The checker succeeded within its scope; the workflow failed by treating scope as completeness.

假设检查器报告语法有效，但报表收入翻倍。订单同时连接明细和付款，在 SUM 前形成“明细—付款”组合。解析器无法知道预期粒度。应分析每单匹配数、比较不同事实键、预聚合独立分支并与总账核对。检查器在自身范围内成功，失败的是把范围误认为完整性的流程。

SQL checker frequently asked questions SQL 检查器常见问题

Continue with a related guide 继续阅读相关指南

Use these closely related guides to verify the next layer of the workflow without mixing separate troubleshooting or decision intents. 可继续阅读以下紧密相关的指南，验证工作流的下一层，同时避免混淆不同的排障或决策意图。

• Complex SQL queries 复杂 SQL 查询
• SQL query optimization SQL 查询优化
• SQL joins SQL 连接