SQL 格式化 / 优化分析器 / 结构可视化

免费在线 SQL 工具三合一：① 14 种方言美化与压缩；② 35+ 条 SQL 性能规则实时检测（无 WHERE 的 UPDATE/DELETE、LIKE 前导通配、ORDER BY RAND、隐式类型转换、笛卡尔积、N+1 子查询、复合索引建议等）；③ AST 结构可视化——把 SELECT 列、JOIN 链、WHERE 条件树、GROUP/ORDER 子句直观拆解。所有处理在浏览器本地完成

Usage & overall rating
NaNToday Remaining
NaNConverted
NaNTotal Helped
Rating(undefined users)
SQL（通用）
Indent
Keywords
UPPER
AND/OR
AND/OR before
SQL Input182 bytes
SELECT * FROM users u WHERE DATE(u.created_at) = '2025-01-01' AND u.name LIKE '%john%' AND u.id IN (SELECT user_id FROM orders WHERE total > 100) ORDER BY RAND() LIMIT 10000, 20;
Formatted227 bytes (+45) 
SELECT
  *
FROM
  users u
WHERE
  DATE(u.created_at) = '2025-01-01'
  AND u.name LIKE '%john%'
  AND u.id IN (
    SELECT
      user_id
    FROM
      orders
    WHERE
      total > 100
  )
ORDER BY
  RAND ()
LIMIT
  10000, 20;

Optimization Analysis

● HIGH: 4 ● MID: 21 stmts · 7 lines
HIGHLeading-wildcard LIKE '%xxx' — index killer

A pattern starting with % cannot use a B-tree index, forcing a full table scan.

Suggestion: Use trailing wildcard "xxx%" if possible; for fuzzy full-text search use a fulltext index or Elasticsearch.

  • L4:LIKE '%john%' AND u.id IN (SELECT user
HIGHORDER BY RAND() — severe perf issue

RAND() forces a full scan + full sort with random keys. Slow at any meaningful table size.

Suggestion: Pick a random offset upfront or pre-compute random IDs at the application layer.

  • L6:ORDER BY RAND() LIMIT 10000, 20;
HIGHFunction wrapping a column in WHERE

WHERE DATE(created_at) = ... defeats the index on created_at — every row gets evaluated.

Suggestion: Rewrite as a range: WHERE created_at >= ... AND created_at < ...; or add a generated column / functional index.

  • L3:WHERE DATE(u.created_at) = '2025-01-01' AND u.name LIKE '%
HIGHLarge OFFSET (deep pagination)

LIMIT 10000, 20 still scans+skips the first 10000 rows. Slows down linearly with depth.

Suggestion: Switch to cursor pagination: WHERE id > <last_seen_id> LIMIT 20 — constant cost regardless of page.

  • L7:LIMIT 10000, 20
MIDSELECT *

Fetching every column adds I/O and network cost, prevents covering-index optimizations, and couples callers to schema changes.

Suggestion: Spell out only the columns you need: SELECT id, name, email FROM users.

  • L1:SELECT * FROM users u WHERE DATE(u.created_at) = '2025-01-01
MIDIN (SELECT ...) subquery

Some engines plan IN-subqueries as semi-joins, but older versions fall back to per-row execution.

Suggestion: Rewrite as JOIN: SELECT a.* FROM a JOIN b ON a.id = b.a_id — gives the planner more freedom.

  • L5:IN (SELECT user_id FROM orders WHERE total > 100) ORDER BY R
User Guide
✨ Features
• Supports 14 SQL dialects: MySQL / PostgreSQL / Oracle / SQL Server / SQLite / Hive / Spark / BigQuery / Snowflake / Redshift / DB2 / N1QL / Trino • Bidirectional beautify + minify; tunable indent, keyword case, AND/OR newline placement • 30+ realtime SQL optimization rules: critical (UPDATE/DELETE without WHERE), perf anti-patterns (leading-wildcard LIKE, ORDER BY RAND, deep pagination), index-killing patterns (WHERE function, implicit cast), style/maintainability • 5 severity tiers (critical/high/mid/low/info), each with detailed explanation and rewrite suggestion • Smart-skips comments and string literals to avoid false positives • Syntax highlighting + byte-count diff; 4 built-in samples to demo each pattern • All processing local in your browser — SQL never leaves your device
📖 How to Use
Step 1
Type or paste SQL on the left (analysis runs live)
Step 2
Use the toolbar to tune dialect, indent, keyword case, etc.
Step 3
Right pane shows the beautified output; toggle 'Minify' for one-line form
Step 4
The Optimization Analysis section below lists all rule findings sorted by severity
Step 5
Click each finding to expand for full explanation, rewrite suggestion, and match locations

Rate this tool (optional)

Could not load your rating. You can still use the tool. Please retry.

Feedback List