Most generated MySQL fails for reasons that have nothing to do with the question: a mode, a collation, or a feature the server version does not have.
Correct-looking SQL that a MySQL server rejects is the normal failure mode for tools that treat SQL as one language. Each of these is a server setting or a version fact rather than a question of skill.
MySQL gives you far fewer join strategies than Postgres, so the question "why is this slow" is nearly always "which index is missing, and why is the one that exists not being used". SQLore reads `EXPLAIN` output and answers exactly that: a full table scan where a composite index would serve, a leading-column mismatch that makes an existing index unusable, a function on a column that defeats it, a covering index that would avoid the row lookups entirely.
Introspection includes the index definitions, not just the keys. That means index awareness at generation time rather than only at diagnosis time — the generated query is shaped around what your tables can actually serve efficiently, instead of being written first and tuned afterwards.
Every statement is parsed and validated to a single read-only SELECT before execution and runs on a read-only connection under a timeout. It will write the `CREATE INDEX` it thinks you need; running it is a decision you make with knowledge of your write workload that the tool does not have.
More answers on the main FAQ, or ask us directly.
MySQL
PostgreSQL, in depth
For people who already write SQL
Every page in this section covers a different question about the same product. See all solutions.
Start free, upgrade when you are asking enough questions for it to matter.
