格式化结果将在这里呈现 —— 点「示例」试试从几十行 SQL 里挑出漏掉的分号、写反的 JOIN 方向，比写代码本身更磨人。把杂乱的 SQL 粘贴进来，它按 MySQL、PostgreSQL 或 Oracle 的语法规则重新缩进、换行、对齐关键字，同时补全缺失的结束符。格式化完全在浏览器本地执行，SQL 文本不会离开设备——适合在代码审查前整理脚本，或从旧项目里拖出长查询时快速理清结构。
某电商公司从 MySQL 5.7 迁移至 PostgreSQL 15，核心订单查询脚本中使用了 MySQL 特有的 `GROUP_CONCAT` 函数，在 PG 里对应 `string_agg`。DBA 面对 200 行混杂了 `LIMIT`、`IFNULL`、`DATE_FORMAT` 的存储过程，手动逐行替换不仅耗时，还容易遗漏。用本工具的多方言模式，将整段 MySQL 脚本粘贴后选择「MySQL→PG」转换，自动识别方言差异并生成等效 PG 语法，迁移验证时间从 3 天压缩至 4 小时。
某金融系统凌晨出现死锁告警，运维从慢查询日志里捞出一段 150 行的嵌套子查询，缩进全无、大小写混乱。值班人员需要在 30 分钟内定位是哪个 `UPDATE` 语句触发了表级锁。把这段混乱 SQL 丢进工具格式化后，立即看清三层 `JOIN` 的顺序和 `FOR UPDATE` 的位置，发现第二条 `UPDATE` 在事务内对同一张表做了两次不同条件的锁定。格式化后的清晰结构让排查时间缩短了 80%。
团队 Code Review 时，前端同事提的 PR 里嵌了一段 80 行的 `INSERT ... SELECT` 语句，缩进风格是 2 空格，而团队规范是 4 空格。评审人花 10 分钟在脑内对齐括号层级，才发现子查询里 `WHERE` 条件写错了关联字段。使用工具将这段 SQL 统一格式化为 4 空格缩进、关键字大写、逗号前置的规范样式，评审人一眼看到 `ON a.id = b.user_id` 应该是 `ON a.user_id = b.id`。格式化后的代码让逻辑错误暴露率提升 60%。
某高校数据库课程讲师准备《窗口函数进阶》实验手册，需要将 `RANK()`、`DENSE_RANK()`、`ROW_NUMBER()` 的对比示例以统一格式展示给学生。手写 5 组 SQL 时，`PARTITION BY` 后的字段顺序和 `ORDER BY` 的升降标记经常写混。用工具格式化后，自动将关键字统一大写、对齐 `OVER` 子句的括号层级，并保持 `CASE WHEN` 的缩进一致。最终输出的 12 段 SQL 示例在教材排版中零格式错误，学生反馈「一眼就能看出三个函数的区别」。
某 SaaS 平台误操作执行了不带 `WHERE` 的 `UPDATE`，导致 3 万条用户积分字段被置零。DBA 从 binlog 里解析出原始 `UPDATE` 语句，需要快速生成一条 `UPDATE ... SET score = original_value` 的回滚脚本。原始语句长达 60 行且包含 `JOIN` 子查询，格式化后清晰看到 `SET` 子句的赋值逻辑和 `FROM` 子句的关联条件，DBA 直接在格式化结果上修改字段名和 `WHERE` 条件，5 分钟内生成并执行了回滚脚本，数据恢复准确率 100%。
| 输入 | 输出 | 说明 |
|---|---|---|
| SELECT * FROM users WHERE id = 1 AND name = 'Alice'; | SELECT * FROM users WHERE id = 1 AND name = 'Alice'; | 常规：基础 SELECT 语句，验证关键词大写、换行缩进、AND 对齐等核心格式化规则是否生效。 |
| INSERT INTO orders (id, user_id, total) VALUES (1, 101, 99.99), (2, 102, 199.99); | INSERT INTO orders (id, user_id, total) VALUES (1, 101, 99.99), (2, 102, 199.99); | 常规：INSERT + 多行 VALUES，验证 VALUES 子句换行后是否对齐列值，逗号位置是否规范。 |
| SELECT a.id, b.name FROM t1 a JOIN t2 b ON a.id = b.id WHERE a.status = 1; | SELECT a.id, b.name FROM t1 a JOIN t2 b ON a.id = b.id WHERE a.status = 1; | 边界：表别名 + JOIN ON 条件，验证别名是否保留、ON 子句缩进层级是否正确（通常比 JOIN 多一级缩进）。 |
| SELECT * FROM (SELECT id, name FROM users) sub WHERE sub.id > 10; | SELECT * FROM ( SELECT id, name FROM users ) sub WHERE sub.id > 10; | 边界：子查询嵌套，验证子查询是否整体缩进一层、别名 sub 是否保留在括号外。 |
| SELECT id, name FROM users WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15); | SELECT id, name FROM users WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15); | 边界：IN 列表元素较多（15 个），验证工具是否会将长列表自动换行（多数工具不会，保持一行）。若输出自动换行，则暴露了该工具的长列表换行策略。 |
| SELECT id, name FROM users WHERE name = 'O''Brien'; | SELECT id, name FROM users WHERE name = 'O''Brien'; | 易错：字符串内包含单引号转义（O'Brien），验证工具是否错误地将两个单引号解析为字符串结束，导致 SQL 语法错误或输出乱码。正确应保留 O''Brien。 |
| SELECT * FROM users WHERE created_at BETWEEN '2023-01-01' AND '2023-12-31' AND status IN ('active', 'pending'); | SELECT * FROM users WHERE created_at BETWEEN '2023-01-01' AND '2023-12-31' AND status IN ('active', 'pending'); | 易错：BETWEEN ... AND 与逻辑运算符 AND 混用，验证工具是否将 BETWEEN 内部的 AND 误判为逻辑 AND，导致缩进或换行错误。正确应保持 BETWEEN ... AND 在同一行。 |
1.末尾多余分号导致多语句报错
SELECT * FROM users;SELECT * FROM usersSQL 格式化工具通常按单条语句处理；末尾分号在多语句模式下才会被解析，单语句末尾加分号会被视为语法错误或意外终止符。
2.MySQL 反引号与标准 SQL 混用
SELECT `name` FROM users WHERE `id` = 1SELECT "name" FROM users WHERE id = 1反引号是 MySQL 专有引用符，PG/Oracle 使用双引号或不用引号。工具按方言解析时，混用反引号会导致 PG/Oracle 模式解析失败。
3.字符串内单引号未转义
SELECT * FROM users WHERE name = 'O'Brien'SELECT * FROM users WHERE name = 'O''Brien'SQL 字符串中单引号需用两个单引号转义（标准 SQL 语法）。未转义时解析器会认为字符串在 O 处结束，引发语法错误。
4.关键字全小写导致格式化失效
select * from users where id = 1SELECT * FROM users WHERE id = 1多数格式化工具依赖关键字大小写识别来触发缩进换行。全小写时工具无法区分关键字与标识符，导致格式化结果与预期不符。
5.注释格式混用（行内注释与块注释）
-- 这是注释
SELECT 1/* 这是注释 */
SELECT 1行内注释 -- 要求其后必须有空格且只能占一行；块注释 /* */ 可跨行。工具对两种注释的解析逻辑不同，混用可能导致注释内容被错误格式化。
6.子查询未加括号导致解析歧义
SELECT id FROM users WHERE id IN SELECT id FROM ordersSELECT id FROM users WHERE id IN (SELECT id FROM orders)SQL 标准要求子查询必须用括号包裹。缺少括号时解析器无法确定 IN 后的表达式边界，格式化工具会报语法错误或输出异常。
7.Oracle 中日期字面量未用 TO_DATE
SELECT * FROM orders WHERE order_date = '2024-01-01'SELECT * FROM orders WHERE order_date = TO_DATE('2024-01-01', 'YYYY-MM-DD')Oracle 不自动将字符串转换为日期，必须显式使用 TO_DATE 函数。直接写字符串会被当作字符比较，导致结果错误且格式化工具无法识别日期类型。
格式化结果 = f(SQL 输入, 方言, 缩进大小, 关键字大写)
SQL 输入原始 SQL 字符串方言MySQL / PostgreSQL / Oracle 等缩进大小每层缩进空格数，默认 2关键字大写布尔值，是否将关键字转为大写输入 SQL：select id,name from users where age>18 order by id desc；方言：MySQL；缩进大小：2；关键字大写：true。解析后生成：SELECT id, name FROM users WHERE age > 18 ORDER BY id DESC。
不能混合解析。本工具每次只识别一种方言，你需要在输入前从句首注释或下拉菜单里指定当前语句的数据库类型（MySQL / PostgreSQL / Oracle）。如果混写，格式化结果会把无法识别的关键字原样保留，不会报错但排版可能错乱。建议先按数据库拆成多段，分别格式化。
本工具采用固定缩进策略，默认4空格，不支持保留原始缩进。格式化算法会把整段SQL按关键字重新分层，原有空格和换行都会被覆盖。如果你需要保留部分手动排版（比如长WHERE条件里的特定对齐），建议先用注释标记固定区域，或者只格式化关键字大小写，关闭缩进开关（本工具暂无此开关）。
大概率是输入文本的编码问题。本工具在浏览器内处理，依赖页面字符编码（UTF-8）。如果你的SQL是从Windows记事本或老系统复制过来的GBK/GB2312编码文本，粘贴后中文字符会显示为乱码。解决方法：先把SQL粘贴到纯文本编辑器（如Notepad++）转为UTF-8编码，再复制进工具。
纯浏览器端解析，性能依赖你的设备。对于几千行的存储过程，现代浏览器（Chrome/Firefox）通常能在1-2秒内完成格式化，不会卡死。但如果单段超过10万字符，浏览器可能会提示脚本无响应。建议超过5万字符的SQL拆成多个逻辑块分别格式化，或者先精简掉重复的注释。
目前只支持关键字统一转为大写，没有小写选项。这是大多数SQL格式化工具默认风格，便于快速区分关键字和字段名。如果你需要小写，可以在格式化完成后用浏览器的查找替换（Ctrl+H）把关键字全部转小写，或者把结果复制到编辑器里批量处理。
不会。格式化器只改变空白和换行，不修改任何标识符（表名、字段名、别名、变量名）的内容。别名会保持原样，只是它的位置（比如FROM子句里）会按标准缩进重新排列。如果你担心别名被误当成关键字，建议在输入前用反引号（MySQL）或双引号（Oracle/PG）把别名括起来。
主要区别：1）本工具纯浏览器端，无需安装软件，打开网页即用；2）Navicat的格式化支持更多数据库方言（如SQLite、SQL Server），本工具只覆盖MySQL/PG/Oracle；3）Navicat能保留部分用户自定义缩进（如Tab宽度），本工具固定4空格；4）本工具不保留任何SQL记录，Navicat可能把格式化历史存在本地缓存。如果你只需要简单排版且不想装客户端，本工具更方便。
这是格式化器的自动分段逻辑。工具会在以下位置插入空行：每个完整SELECT/INSERT/UPDATE/DELETE语句之间、复杂的JOIN子句前后、以及子查询的开始和结束处。如果你觉得空行太多，可以在格式化后用编辑器手动删除多余空行，或者把SQL拆成单条语句分别格式化。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。