# Top MySQL SQL Review and Lint Tools in 2026 > MySQL SQL review tools compared: SQLFluff for style, Skeema for schema-design linting, SOAR for query anti-patterns, and where Bytebase fits as the approval layer. Adela | 2026-08-21 | Source: https://www.bytebase.com/blog/top-mysql-sql-review-tools/ --- > **Note:** This post is maintained by Bytebase, an open-source database governance platform. We update the post periodically. 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](https://sqlfluff.com/) 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](https://www.skeema.io/) 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](https://www.skeema.io/docs/options/), 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](https://github.com/XiaoMi/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](https://docs.percona.com/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](https://www.red-gate.com/products/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](https://www.bytebase.com/sql-review/) 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 | Tool | Layer | Scope | Status (2026) | License | | ------------------------ | ------------------------ | -------------------- | --------------------------------- | ------------------------------ | | SQLFluff | Style | SQL text | Active, monthly releases | Open source (MIT) | | Skeema | Schema design | `CREATE TABLE` files | Active, v1.14.1 (Jul 2026) | Community Apache-2.0 / Premium | | SOAR | Query anti-patterns | Individual queries | Stalled since Dec 2023 | Open source (Apache-2.0) | | pt-duplicate-key-checker | Index audit | Live schema | Active (Percona Toolkit v3.7.1) | Open source (GPL) | | Flyway | Style + limited safety | Migration files | Active; checks require Enterprise | Commercial (Enterprise) | | Bytebase | Lint + policy + approval | Change workflow | Active | Free (Community) / paid tiers | 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](/blog/sql-review-tool-for-devs/). If you run Postgres alongside MySQL, the equivalent list for that engine is [Top Postgres SQL Review Tools](/blog/top-postgres-sql-review-tools/). ## Related reading - [Top Postgres SQL Review Tools in 2026](https://www.bytebase.com/blog/top-postgres-sql-review-tools/) - [SQL Review: From Linting to Governance](https://www.bytebase.com/blog/sql-review-tool-for-devs/) - [How to Integrate Automatic SQL Review into GitHub](https://www.bytebase.com/blog/integrate-sql-review-into-github/) - [Top Open Source MySQL Migration Tools in 2026](https://www.bytebase.com/blog/top-open-source-mysql-migration-tools/)