SQL vs MySQL: What Is the Difference?

SQL is the language: a published standard describing SELECT, INSERT, UPDATE, DELETE, CREATE TABLE and the rest, ratified by ISO and ANSI. MySQL is an engine: one particular implementation of that language, plus its own storage format, its own server process, its own replication and its own dialect quirks. People conflate them because MySQL is by far the most widely deployed engine, but Oracle, PostgreSQL, SQL Server, SQLite and MariaDB all speak SQL too, and their dialects diverge.

-- Portable ANSI SQL: this runs unchanged on MySQL, PostgreSQL, SQLite and SQL Server.
CREATE TABLE customers (
  id INTEGER PRIMARY KEY,
  name VARCHAR(120) NOT NULL
);

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL,
  amount DECIMAL(10, 2) NOT NULL
);

INSERT INTO customers (id, name) VALUES (1, 'Ada Lovelace'), (2, 'Grace Hopper');
INSERT INTO orders (id, customer_id, amount) VALUES (1, 1, 120.00), (2, 1, 340.50), (3, 2, 75.25);

SELECT c.id, c.name, COUNT(o.id) AS order_count, ROUND(AVG(o.amount), 2) AS avg_order
FROM customers AS c
LEFT JOIN orders AS o ON o.customer_id = c.id
GROUP BY c.id, c.name
ORDER BY avg_order DESC NULLS LAST
LIMIT 10;

Day to day, the difference rarely bites: joins, filters, aggregation, window functions and CTEs are essentially identical everywhere. It bites at the edges. MySQL wants backticks around identifiers (or double quotes in ANSI mode), implements UPSERT as ON DUPLICATE KEY UPDATE rather than the standard ON CONFLICT, and has no FETCH FIRST syntax — it uses LIMIT. PostgreSQL distinguishes types far more strictly and offers RETURNING on DML, which MySQL only added for some statements.

The practical advice: write ANSI SQL by default, learn the dialect of the engine you are actually deploying on, and never assume a query you wrote against SQLite will run unchanged on MySQL — that is where the real interview follow-up lives.

The portable core is small: ANSI CREATE TABLE with explicit column types, and INSERT INTO ... VALUES with a column list. Avoid engine-specific pieces — no AUTO_INCREMENT (that is MySQL and MariaDB; the standard equivalent is GENERATED ALWAYS AS IDENTITY), no ENGINE=InnoDB table option, no ON UPDATE CURRENT_TIMESTAMP column clause.

CREATE TABLE authors (
  id INTEGER PRIMARY KEY,
  name VARCHAR(120) NOT NULL,
  country VARCHAR(60) NOT NULL,
  born INTEGER NOT NULL
);

INSERT INTO authors (id, name, country, born) VALUES
  (1, 'Ursula K. Le Guin', 'United States', 1929),
  (2, 'Italo Calvino', 'Italy', 1923);

SELECT id, name, country FROM authors WHERE born < 1930 ORDER BY born;

The SELECT returns two rows: Italo Calvino (born 1923) and Ursula K. Le Guin (born 1929), ordered by birth year. Because the column list is spelled out, the statement is immune to a later column reordering in the table definition — a real hazard when a script is replayed months later against a migrated schema.

One MySQL note worth mentioning in an interview: the same script runs there without modification, but if you later need the key to fill itself, MySQL wants id INT AUTO_INCREMENT PRIMARY KEY while the standard spelling is id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY. SQLite accepts the identity syntax from version 3.31 onward, which is why it is used here.