SQL Explain / SQL 优化在线工具 - 格式化、解释、索引建议

功能特点

• 美化 SELECT、JOIN、WHERE 等常见 SQL 查询结构
• 压缩 SQL 语句，便于放入配置、日志或代码片段
• 统一 SQL 关键字大小写，提升查询可读性
• AI 解释查询逻辑，定位 SELECT *、全表扫描、JOIN、排序和分页等潜在慢点
• 把 AI 索引建议转成可验证假设，并用目标数据库的 EXPLAIN 复核扫描、排序和行数

使用方法

1. 粘贴需要整理的 SQL 查询语句
2. 选择格式化、压缩或关键字大小写处理，并明确 MySQL、PostgreSQL 或 SQLite 等目标方言
3. 把查询逻辑和索引建议当作假设，用目标环境 EXPLAIN、数据量和监控结果验证后再修改数据库

示例输入

• 订单接口慢查询

  SELECT * FROM orders WHERE user_id = 42 ORDER BY created_at DESC LIMIT 20;

  适合分析过滤、排序、分页和 SELECT * 是否造成额外扫描或回表。 查询分析与索引建议是说明性的 AI 输出，会随数据库方言、上下文和模型响应变化。

• 多表 JOIN 审查

  SELECT u.id, COUNT(o.id) FROM users u LEFT JOIN orders o ON o.user_id = u.id GROUP BY u.id;

  适合检查 JOIN 条件、聚合、索引覆盖和数据量增长后的风险。 查询分析与索引建议是说明性的 AI 输出，会随数据库方言、上下文和模型响应变化。

• EXPLAIN 复核索引建议

  EXPLAIN SELECT id, created_at FROM orders WHERE user_id = 42 ORDER BY created_at DESC LIMIT 20;

  适合把 AI 的索引建议交给目标数据库验证，重点查看访问类型、扫描行数、排序和实际耗时。 查询分析与索引建议是说明性的 AI 输出，会随数据库方言、上下文和模型响应变化。

• 只合并空白的压缩

  SELECT  *
  FROM users
  WHERE id = 1;

  页面的 Minify 只 trim 并把连续空白合并为单个空格，不会解析 SQL、改写条件或优化执行计划。 查询分析与索引建议是说明性的 AI 输出，会随数据库方言、上下文和模型响应变化。

示例输出

• 订单接口慢查询

  建议验证 (user_id, created_at DESC) 复合索引，并只选择页面需要的列；用目标数据库 EXPLAIN 确认扫描与排序。

• 多表 JOIN 审查

  LEFT JOIN 保留无订单用户；先检查 orders.user_id 索引，再确认 GROUP BY 规则和 COUNT(o.id) 是否符合方言。

• EXPLAIN 复核索引建议

  示例计划：Index Scan on orders；Index Cond: user_id = 42；仍需在目标数据库确认实际行数、排序和耗时。

• 只合并空白的压缩

  SELECT * FROM users WHERE id = 1;（Minify 只合并空白，不改变 SQL 结构或执行计划）

常见错误

• 只看 SQL 文本就断言一定慢，实际耗时还取决于数据量、统计信息、执行计划和并发。
• 直接照搬 AI 生成的索引，可能产生重复索引、写入变慢或占用过多存储。
• 使用 EXPLAIN ANALYZE 前未确认数据库环境，可能真的执行 UPDATE、DELETE 或高成本查询。
• 把格式化结果当作性能优化结果，关键字大小写和换行不会自动改变执行计划。
• 没有 ORDER BY 的分页查询不保证结果顺序，不能只根据一次返回结果判断分页稳定。

适用场景

• SQL explain online
• SQL optimize online
• 慢查询排查
• 索引设计评审
• 数据库代码审查

实操检查

• 格式化不会连接数据库

  当前页面用 sql-formatter 调整缩进和关键字大小写，压缩操作只合并空白；它不会执行 SQL、读取表结构、验证权限或判断查询计划。

• AI 分析前先脱敏 SQL

  本地格式化不上传输入，只有主动点击 AI 分析才会外发 SQL 和上下文；提交前应移除账号、凭据、内部地址和不必要的业务数据，并把结果当作排查线索而非数据库事实。

页面专属核验

使用前与操作中

• 只需要排版或压缩时使用本地格式化，不要期待页面连接数据库或读取表结构。
• 提交 AI 分析前删除账号、凭据、内部地址和不必要的业务数据，并补充数据库类型和上下文。
• 准备采用索引或查询改写建议前，先记录真实执行计划、数据量和目标数据库版本。

结果出来后

• 格式化前后的关键字、字符串、注释、参数和语句边界是否保持一致？
• AI 给出的慢点、索引或风险建议是否能用目标数据库的 EXPLAIN 和测试数据复现？
• SQL 是否仍经过权限、参数绑定、事务和生产变更审批，而不是直接复制执行？

相关工具

• JSON 工具：统一处理 JSON 格式化、校验、树形查看、Schema、CSV 转换、AI 响应分析和 JSON 修复
• HTTP Headers 解析：解析 HTTP Headers，并用 AI 分析认证方式、风险和 API 调试线索
• 文本对比：按行对比文本、配置、日志和接口响应差异
• 代码格式化：统一格式化和轻量压缩 HTML、CSS、JavaScript 代码

工具边界

• 只根据 SQL 文本无法代替真实 EXPLAIN 和生产监控数据。
• AI 建议不执行数据库操作，也不能保证适配当前数据库方言。
• 不要粘贴生产数据、账号、连接串或完整敏感表结构。

与相似工具的区别

• 代码格式化：SQL 工具按查询结构和数据库方言分析；代码格式化器只整理语法排版，不会判断索引或执行计划。

安全与兼容性

• 普通 SQL 排版在本地完成；AI 解释会把已粘贴的查询发送给模型服务，因此应移除真实表数据与连接信息。
• 不要在生产库直接执行来源不明的建议，尤其是 EXPLAIN ANALYZE、DDL、UPDATE 或 DELETE。

下一步排查

1. 先格式化 SQL，并确认数据库方言和版本。
2. 把索引和慢点建议当作假设，在目标环境运行 EXPLAIN，记录扫描行数、排序和实际耗时。
3. 检查分页是否有稳定 ORDER BY，并结合接口 Headers、HTTP 状态或 AI 日志分析定位应用层问题。

常见问题