SQL 相关工具合集
SQL 工具合集：整理 SQL 格式化、关键字检索与语句速查，覆盖 SELECT 各子句的执行顺序、JOIN 类型的选择、聚合与窗口函数的差异，以及 WHERE 与 HAVING 的阶段差异，并附 SQL 美化、文本替换与正则调试入口。适合写复杂查询前确认语法、统一团队代码风格与排查拼接错误。
SQL（结构化查询语言）是与数据库交互的标准语言，语法细节繁多且各数据库方言存在差异。
常见方案对照
| 维度 | WHERE | HAVING |
|---|---|---|
| 执行时机 | GROUP BY 之前 | GROUP BY 之后 |
| 能否用 SELECT 别名 | 不能 | 能 |
| 能否聚合 | 不能 | 能 |
| 作用于 | 原始明细行 | 分组后的结果集 |
| 索引使用 | 能用索引 | 通常不能用 |
| 典型用途 | 过滤明细行 | 过滤聚合结果（如总数 > 100） |
| 常见错误 | 在这里写聚合条件 | 误用来代替 WHERE |
| NULL 语义 | IS NULL 才能匹配空值 | 同左 |
边界条件
- WHERE 后加聚合条件会报「非聚合列出现在 GROUP BY 中」——因为它作用于分组前的行。
- HAVING 可以用 SELECT 的别名，WHERE 不能，这是执行顺序的直接后果。
- LEFT JOIN 在 WHERE 里过滤右表字段会退化为 INNER JOIN，条件应写在 ON 里。
- COUNT(*) 统计行数，COUNT(列) 跳过 NULL，两者结果可能差很多。
常见坑
- 用 WHERE 过滤聚合结果，报错后才改用 HAVING，其实条件放错了阶段。
- LEFT JOIN 的 ON 里写左表条件，等于没过滤，把 JOIN 变成了笛卡尔积。
- 认为 HAVING 能替代 WHERE，在聚合前就把明细行丢掉了。
- NOT IN 遇到含 NULL 的子查询会返回空结果，应改用 NOT EXISTS 或先过滤 NULL。
相关工具
- SQL 格式化基于正则的 SQL 格式化器，自动缩进并把关键字大写，适合整理慢查询日志、Code Review 时让嵌套子查询更易读，提升可维护性。自动把关键字统一为大写，并按子句换行缩进，让嵌套查询层次清晰。支持常见方言的语法习惯，只调整版式不改动语义。适合整理慢查询日志与提交前的代码走查。
- 文本替换工具在文本中执行批量查找替换，支持正则表达式、大小写敏感选项与全局替换预览。支持普通文本与正则两种查找方式，可选择大小写敏感与全局替换。替换前会列出所有命中位置与预览结果，避免误改。支持普通文本与正则表达式两种查找方式，可勾选大小写敏感与全词匹配。替换前会列出所有命中位置并预览结果。
- 大小写格式转换器在 camelCase、snake_case、kebab-case 与 PascalCase 等命名风格间互转。也能生成全大写下划线常量名与标题式写法，切换时无需手动改字。转换会保留数字与已有缩写，避免把 API 变成 aPI。转换前可预览每一行结果，确认无误再复制。可一次转换整列字段名与变量名。
- 正则表达式测试器在线测试 JavaScript 正则表达式，支持 g/i/m/s/u/y 标志位与命名捕获分组高亮，实时显示匹配结果。支持全局、忽略大小写、多行、点号匹配换行与 Unicode 等标志位组合。高亮显示每个匹配项与命名捕获分组的内容，并列出全部匹配位置。适合调试表单校验规则与日志提取表达式。
常见问题
SQL 里 SELECT 的执行顺序是什么？
书写顺序是 SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT，但**执行顺序**不同：FROM（含 JOIN）→ WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT。这个差异解释了为什么 WHERE 里不能用 SELECT 的别名（WHERE 先于 SELECT 执行），而 HAVING 可以。写复杂查询时按执行顺序思考，能避免大部分「为什么这里报错」。
JOIN 该用 INNER 还是 LEFT？
看**你要不要保留右表没有匹配的行**。INNER JOIN 只保留两边都匹配上的；LEFT JOIN 保留左表全部行，右表无匹配时补 NULL。常见错误是用 INNER JOIN 做「左表全量查询」，结果默默丢掉了未匹配的行。更隐蔽的是 WHERE 里对右表字段加条件会把 LEFT JOIN 降级成 INNER JOIN —— 条件要放在 ON 里才能保留左表全量。