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

SQL Structure Visualization

SELECT
Columns 1
  • *
Tables & JOINs 1
usersas umain
WHERE
AND3
·DATE(u.created_at) = '2025-01-01'
·u.name LIKE '%john%'
·u.id IN ((子查询))
ORDER BYRAND()ASC
LIMIT20OFFSET10000
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
Like it? Rate it!

Feedback List