Top MySQL SQL Review and Lint Tools in 2026

MySQL's SQL review tooling is thinner and more scattered than Postgres's. There is no single dominant migration-safety linter the way Squawk is for Postgres, and the ecosystem leans on tools built for MySQL operations first, review second: a schema-management CLI with lint rules bolted on, a query rewriter out of the TiDB/MySQL-protocol world, a toolkit built for DBAs auditing a live server. Most MySQL-native tools were not designed as a complete review layer, so teams end up combining two or three of them rather than picking one.

What are the criteria? Every pick here is:

• MySQL-aware - targets MySQL specifically, or (SQLFluff) has real MySQL dialect coverage rather than treating it as a generic SQL variant.
• Actively maintained, or the gap disclosed if not - checked against its own commit history, not just a rules page. SOAR fails the "actively maintained" half outright (last commit December 2023) and is included anyway, with that status stated plainly rather than glossed over. Two other tools that show up in almost every "MySQL lint" search fail the check with nothing to offset it, and are named below as failures, not recommendations.
• Adoptable on its own - no pick requires the others to be useful.

SQLFluff (MySQL dialect)#

SQLFluff is a style linter, not a safety linter. It parses SQL against a chosen dialect and flags casing, indentation, and formatting violations. The MySQL dialect knows MySQL's actual quoting rules (backticks for identifiers, single or double quotes for string literals), which a generic-SQL linter gets wrong often enough to be annoying in CI.

It has no idea that ALTER TABLE orders ADD COLUMN status VARCHAR(20) is a metadata-only change on MySQL 8.0.29 and later, was instant on 8.0.12 through 8.0.28 only when the column went last, and rebuilt the entire table on anything older. Nor that a table which has already absorbed the per-table limit of 64 instant ADD/DROP COLUMN operations rebuilds regardless of version. Style and safety are different layers, and SQLFluff only covers the first one.

Best for: enforcing one SQL style across a team, in CI, before it ever reaches a human reviewer.

Skeema#

Skeema is a declarative schema-management CLI first, and its lint command is a genuine schema-design linter second. It runs against the CREATE TABLE statements in your repo (not against migration files) and checks for design problems: tables with no primary key, redundant secondary indexes, columns using FLOAT/DOUBLE where exact arithmetic matters, disallowed character sets, and foreign keys your team may have banned for performance reasons. Each rule is independently configurable as an error, a warning, or off.

This is a different job from a migration-safety linter. Skeema's lint checks the schema you're about to have, not whether the specific ALTER statement getting you there will lock the table. Community edition manages tables and routines; Premium adds views, triggers, and events to what skeema lint and the rest of the toolchain can see.

Best for: catching schema-design mistakes (missing primary key, wrong numeric type, redundant index) before they ship, especially if your schema already lives in git as plain SQL.

SOAR#

SOAR (SQL Optimizer And Rewriter), from Xiaomi's database team, is a static analyzer for the MySQL protocol family (MySQL, MariaDB, and TiDB all parse cleanly). Point it at a query and it flags anti-patterns a human reviewer would also catch: SELECT *, a missing WHERE clause on an UPDATE or DELETE, implicit type conversion that silently defeats an index, subqueries that would run faster as a join. It also offers to rewrite the query.

Read this honestly before adopting it: SOAR's last commit was in December 2023. It still runs, the heuristics it already has are still valid, and its 8,700+ stars reflect real adoption in the MySQL/TiDB world. But there has been no new rule and no new engine-version support in over two and a half years, and there's no indication that will change.

Best for: a one-time or CI-gated pass that catches query-level anti-patterns, from a tool you should not expect new coverage from.

pt-duplicate-key-checker (Percona Toolkit)#

Percona Toolkit is a collection of command-line tools built for DBAs operating a live MySQL server, and one of them does real schema review: pt-duplicate-key-checker connects to a database and reports redundant or duplicate secondary indexes, the kind that silently double your write cost and rarely get noticed until someone audits the schema.

It is not a general linter. It answers one specific question about indexes on a database that already exists, which makes it a good periodic check rather than a pre-merge gate.

Best for: an audit pass on an existing MySQL server, particularly one that has accumulated indexes from several years of "just add an index" fixes.

Flyway#

Flyway ships SQL checks (SQLFluff rules plus Redgate's own set) across MySQL, PostgreSQL, Oracle, and SQL Server. Get the tier right before you plan around it: Redgate has stopped selling the Teams tier to new customers; its current lineup is Community and Enterprise. Code analysis and SQL checks now sit behind Flyway Enterprise; existing Teams customers can renew, but anyone evaluating Flyway today for this capability is looking at Enterprise pricing, not Teams.

Best for: shops already committed to Flyway Enterprise for migrations who want the same vendor covering SQL checks.

Bytebase#

Bytebase is where many teams end up putting the review itself, because one rule engine covers the ground the tools above split between them, and the result is attached to an approval rather than printed to a log.

For MySQL it ships 80+ engine-specific rules spanning most of the layers on this page (style/casing linting is the one gap — pair it with SQLFluff if that layer matters to you):

• Query anti-patterns: SELECT *, UPDATE/DELETE with no WHERE, leading-wildcard LIKE, a function wrapped around an indexed column, ORDER BY RAND() in an INSERT ... SELECT, affected-row and execution-time ceilings.
• Index hygiene: duplicate indexes, duplicate columns inside one index, index count and key-count limits, disallowed index types on BLOB.
• Schema design: require a primary key, require charset and collation, column type disallow lists (the mechanism that keeps FLOAT out of money columns), maximum VARCHAR length, NOT NULL defaults.
• Migration safety: required ALGORITHM/LOCK options on ALTER, compatibility checks for non-additive changes, online-migration handling, DML dry-run before execution.
• Naming conventions: tables, columns, indexes, foreign keys, unique keys, plus a keyword blocklist.

Rule levels attach to an environment or a project, with the project-level policy taking priority — the same rule can warn in dev and block in prod, or override the environment default entirely for one sensitive service. The differentiator over the tools above is where the check happens: inside the same change issue a DBA approves, not in a separate CI log the approver has to go find. It also runs as a GitHub check if you'd rather keep the gate in the pull request.

The honest trade-off is narrower than "use something else for the real review." Two specific things the tools above do that Bytebase does not: SOAR rewrites a query and hands you the optimized version, where Bytebase flags the pattern and leaves the rewrite to you; and pt-duplicate-key-checker audits a live server for what has already accumulated, where Bytebase's duplicate-index rule fires on changes moving through the workflow. On a legacy schema those are complementary: run the Percona tool once to clear the backlog, then let the rule keep it clean.

Best for: teams that want one rule engine across MySQL and their other engines, with the review and the approval in the same place.

Two tools you'll see recommended and shouldn't rely on#

MySQL Workbench does not have a rule-based SQL linter, despite showing up in almost every "MySQL SQL review tool" search result. What it actually has is a SQL parser for syntax checking and autocomplete, and a separate schema/EER-model validation feature that is Commercial-edition only and checks a data model, not arbitrary SQL statements. Neither is a substitute for a linter that flags anti-patterns in the SQL you're about to run.

MyTAP, the MySQL equivalent of pgTAP, exists and would fill the testing-framework gap this list otherwise has. It hasn't shipped a commit since October 2021 or a release since 2018. There is currently no actively-maintained MySQL-native equivalent to pgTAP's schema-assertion testing. That gap in the layer stack is real, not a pick we skipped.

Comparison#

Read the table by what's missing from your stack, not by which row has the most rules. A team running SQLFluff alone has style consistency and nothing else. A team running Skeema alone catches schema-design mistakes but ships whatever query patterns each developer writes. These tools overlap more than the table lets on — Skeema's schema-design lint and Bytebase's schema rules catch some of the same mistakes, SOAR and Bytebase both flag the same query anti-patterns, Skeema and pt-duplicate-key-checker can both surface the same redundant index — but each has a different center of gravity, and none of them cover the ground pgTAP covers for Postgres.

Picking one#

Start with SQLFluff if nothing here is in place yet, since it's close to free to turn on and ends the style arguments in code review. Add Skeema lint as soon as your schema lives in a repo, since missing primary keys and float-for-money columns are the kind of mistake a linter catches once and a human reviewer misses periodically forever.

SOAR and pt-duplicate-key-checker are narrower, operational picks: reach for SOAR when you want a suggested rewrite rather than just a flag, and knowing it won't gain new coverage; reach for the Percona tool when you're auditing indexes on a server that already exists, not gating a pre-merge check. Flyway's SQL checks generally make sense only if Enterprise pricing was already the plan for other reasons.

Bytebase is the option that collapses the stack: one rule engine covering query anti-patterns, index hygiene, schema design, migration safety, and naming conventions across MySQL and your other engines, with environment- or project-level policy and the approval attached. Plenty of teams run it as their only SQL review. The question it adds on top, which no MySQL-native tool in this list attempts, is who signed off before the change ran.

For the three-layer framework this list assumes (linting, semantic rules, policy), see SQL review: from linting to governance. If you run Postgres alongside MySQL, the equivalent list for that engine is Top Postgres SQL Review Tools.