SQL与测试数据
让较长 SQL 的条件和 JOIN 更易阅读
使用工具
日志出现长 SQL 时，先问它想取什么。不断横滚容易漏看括号与 JOIN 条件。格式化让结构清楚，便于按顺序阅读，但易读不等于正确；工具不连接数据库，也不执行 SQL。
按子句拆开虚构订单查询
选 PostgreSQL 格式化示例，可更容易找到大写的 SELECT、FROM、LEFT JOIN、WHERE、ORDER BY。按返回字段、起点表、连接表、保留行、排序依次阅读。这是虚构表，不必在真实数据库执行。
select o.id,o.total,c.name from orders o left join customers c on c.id=o.customer_id where o.status='paid' and (o.total>=1000 or o.priority=true) order by o.id;保留原 SQL 对比。大写和换行不是修正逻辑，表列存在、权限、结果行数需要数据库上下文。格式化成功不代表语义验证或可执行。
确认 AND、OR 的作用范围
示例要求 paid，且金额至少 1000 或 priority 为 true。去括号后按通常优先级，priority 订单可不论是否 paid 都被包含。格式化能显分组但不知道业务意图，可用小额已付、大额未付、优先未付等虚构行推演。
JOIN 的 ON 与 WHERE 要分别读。WHERE 要求右表值时可能过滤掉 LEFT JOIN 未匹配行，不能只凭名字认定左行全保留。移动条件可能改变含义，应作为 SQL 修改审核而非格式化。
选择方言不等于迁移 SQL
应选择输入来源的 PostgreSQL、MySQL 或 SQLite 方言。把 MySQL 当 PostgreSQL 格式化不会翻译函数、类型、引用和日期行为。遇到不支持语法，先核对原方言，不要只为了成功而随便切换。
日志可能附时间、标识和耗时，应先确认 SQL 正文范围，勿把字面值中的换行或引号当装饰删掉。参数单独记录时，先核对映射，不要急着手拼一个看似完整的语句。
同名参数出现两次时
占位符转换可分别输入 SQL 与参数 JSON。两个 :id 转 PostgreSQL 时都是 $1；问号形式按每次出现需要参数，因此映射值重复两次。不能只复制 SQL 却沿用旧参数顺序。
SELECT * FROM users WHERE id = :id OR manager_id = :id
Arguments: {"id":7}
PostgreSQL: id = $1 OR manager_id = $1
Question: id = ? OR manager_id = ? → [7, 7]转换器会区分普通字符串、注释与参数，但不是完整方言解析器。PostgreSQL 的 ? 也可作运算符，因此问号输入受限。复杂特有语法还应核对数据库和驱动官方文档。
读懂后决定下一步检查
行数过多查条件和连接，值不对查参数与 NULL，慢则需执行计划和数据上下文。格式化不测耗时、索引或锁，也不证明变快，只提供更易调查的文本。
共享时将个人或秘密数据换成虚构值，同时保持相关结构。数据库执行是另一项需授权的步骤。先读子句和括号，再核对参数，能在考虑执行前明确问题。
SQL 易读之后，再思考结果行数
JOIN 清楚后应问每个订单对应另一表几行。键不唯一时所谓单个顾客可能放大行数。整形不读表结构数据，不能验证基数。先查哪里增行，不要直接加 DISTINCT 隐藏；整形只是让调查更容易。
LEFT JOIN 可空侧列上的 WHERE 条件可能删掉未匹配行，ON 与 WHERE 之间移动不是外观变化。利用清晰结构，用少量虚构数据先写预期结果。工具不会搬条件或执行，数据库验证仍是另行限定权限的工作。
可读不等于更快，因为未提供索引、行数、统计与计划。应分开报告格式化与保持结果的已验证优化，后者需目标数据库计划和实测。大写关键字或换行不是性能证据。