SQL flavor map — Postgres khác MySQL ở 8 chỗ phải nhớ

Bạn copy một query từ Stack Overflow — câu trả lời có 500 upvote, tag MySQL — và chạy thử trên Postgres. Kết quả trả về ngay: ERROR: syntax error at or near "AUTO_INCREMENT". Cùng là SQL, cùng là SELECT/INSERT, nhưng dialect khác nhau khiến syntax hợp lệ ở vendor này thành lỗi compile ở vendor kia.

Bài này map 8 chỗ chính các vendor khác biệt — đủ để 80 bài còn lại của khoá học bạn chỉ cần đọc callout "MySQL khác:" ở đúng chỗ thực sự khác. Phần lớn syntax PG/MySQL/SQLite portable khoảng 90% — 10% còn lại mới cần flag.

1. Analogy — 4 dialect tiếng Anh

Hãy nghĩ SQL như tiếng Anh: cùng một ngôn ngữ, nhưng British English, American English, Australian English và Singapore English có những từ và cách nói riêng. Người nói dialect nào cũng giao tiếp được với nhau — nhưng một số cụm dùng ở Anh sẽ khiến người Mỹ nhìn chằm chằm.

2. ANSI SQL standard — 90% giống nhau

SQL có lịch sử chuẩn hoá dài: ANSI SQL 1986 là phiên bản đầu tiên, theo sau là SQL-92 (bổ sung lớn — JOIN, subquery), SQL:1999 (recursive CTE, trigger), SQL:2003 (window function, sequence), SQL:2008, SQL:2011 (temporal), SQL:2016 (JSON path), SQL:2023 (property graph, JSON). Mọi vendor implement một subset của standard này, cộng thêm extension riêng.

Hệ quả thực tế: query cơ bản — SELECT/WHERE/JOIN/GROUP BY/ORDER BY/LIMIT — gần như portable giữa PG, MySQL, và SQLite. Sự khác biệt nằm ở extension vendor-specific và một số quyết định thiết kế sớm trước khi standard được định nghĩa rõ.

Tham khảo: Wikipedia — SQL Standardization history — overview lịch sử các phiên bản standard.

3. 8 chỗ khác biệt — bảng tổng hợp

Bảng dưới map 8 case thực tế hay gặp. Đọc một lần để có mental map — không cần học thuộc, bài sau sẽ flag lại ở đúng chỗ cần.

3.1 Chi tiết — Identifier quoting

PG tuân thủ ANSI SQL: identifier không phải keyword thì không cần quote; nếu muốn preserve case hoặc dùng reserved word làm tên, dùng double quote. MySQL chọn backtick — style này không ANSI, nhưng tránh conflict với string literal.

-- PostgreSQL: double quote de preserve case
SELECT "firstName", "lastName" FROM users;

-- MySQL: backtick
SELECT `firstName`, `lastName` FROM users;

-- Khong quote (an toan nhat, lowercase identifier): portable giua PG va MySQL
SELECT first_name, last_name FROM users;

3.2 Chi tiết — Auto-increment PK

Đây là case hay gặp nhất khi copy Stack Overflow:

-- MySQL syntax -- KHONG chay tren PG
CREATE TABLE products (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(255)
);

-- PostgreSQL equivalent -- BIGSERIAL la shorthand cho sequence
CREATE TABLE products (
  id BIGSERIAL PRIMARY KEY,
  name TEXT
);

-- PG 10+: IDENTITY (ANSI SQL:2003 compliant, prefer over SERIAL)
CREATE TABLE products (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name TEXT
);

-- SQLite: INTEGER PRIMARY KEY tu dong la alias cua rowid
CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  name TEXT
);

3.3 Chi tiết — Pagination

-- PostgreSQL va SQLite: LIMIT n OFFSET m (ANSI-ish)
SELECT * FROM products ORDER BY id LIMIT 10 OFFSET 20;

-- MySQL: ho tro ca hai, nhung co syntax rieng (m, n thay vi n OFFSET m)
SELECT * FROM products ORDER BY id LIMIT 20, 10;  -- MySQL: offset truoc, limit sau
SELECT * FROM products ORDER BY id LIMIT 10 OFFSET 20;  -- cung chay tren MySQL

-- MSSQL: ANSI SQL:2008 syntax (verbose hon)
SELECT * FROM products ORDER BY id
OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;

4. Top 3 khác biệt thực sự gây bug khi port code

Trong 8 case trên, 3 case dễ gây bug im lặng (silent bug) nhất khi chuyển code từ vendor này sang vendor kia:

4.1 Identifier case (case 6) — deploy lên Linux thì vỡ

MySQL trên macOS và Windows so sánh tên bảng/tên cột không phân biệt hoa thường (case-insensitive). Trên Linux, MySQL thường mặc định case-sensitive (lower_case_table_names=0) — nhưng một số bản cài qua package manager (Ubuntu apt, một số image MySQL 8) có thể set khác, nên kiểm tra SHOW VARIABLES LIKE 'lower_case_table_names' trên server thực tế. PostgreSQL luôn lowercase unquoted identifier — users, Users, USERS đều thành users — nhưng nếu table tạo với quoted identifier "Users", thì chỉ "Users" match.

-- MySQL macOS: ca hai chay OK
SELECT * FROM Users;
SELECT * FROM users;

-- MySQL Linux: phu thuoc bien he thong lower_case_table_names
-- Neu lower_case_table_names=0 (default Linux): "Users" != "users" -> loi

-- PostgreSQL: unquoted identifier luon lowercase
-- Table tao bang: CREATE TABLE users (...)
-- SELECT * FROM Users;  -> PostgreSQL convert "Users" thanh "users" -> OK
-- SELECT * FROM "Users"; -> tim "Users" (preserve case) -> relation does not exist

Hệ quả: code chạy OK trên macOS dev (MySQL), deploy Linux production → Table 'mydb.Users' doesn't exist. Fix: convention luôn dùng snake_case lowercase, không quote identifier.

4.2 Boolean (case 5) — port sang PG cần migrate column

MySQL không có native boolean — BOOL là alias của TINYINT(1), lưu giá trị 0 hoặc 1. Khi port sang PG, cần migrate column type và cả application code nếu code đang so sánh = 1 thay vì = true.

-- MySQL: BOOL la TINYINT(1)
CREATE TABLE tasks (
  id INT AUTO_INCREMENT PRIMARY KEY,
  is_done BOOL  -- luu 0 hoac 1
);

-- Query MySQL app code co the dung:
SELECT * FROM tasks WHERE is_done = 1;

-- PostgreSQL: BOOLEAN native
CREATE TABLE tasks (
  id BIGSERIAL PRIMARY KEY,
  is_done BOOLEAN  -- true hoac false
);

-- PG khong chap nhan WHERE is_done = 1 (type mismatch)
-- Phai viet:
SELECT * FROM tasks WHERE is_done = true;
SELECT * FROM tasks WHERE is_done;  -- shorthand

4.3 String compare với trailing space (case 8) — silent data mismatch

Đây là case nguy hiểm nhất vì không gây lỗi — chỉ trả về kết quả sai.

-- MySQL: padding compare, 'AB' = 'AB ' tra ve true
SELECT 'AB' = 'AB ';  -- MySQL: 1 (true)

-- PostgreSQL: no padding, 'AB' = 'AB ' tra ve false
SELECT 'AB' = 'AB ';  -- PG: false

-- Scenario: data trong MySQL co the chua row voi code = 'AB '
-- Port sang PG, query WHERE code = 'AB' dot nhien khong match row do
-- Silent bug: khong bao gio biet data o do, chi thay count giam

Fix: luôn TRIM() data trước khi lưu, hoặc dùng constraint để chuẩn hoá dữ liệu.

5. PG-specific extension — forward links các Module sau

PG không chỉ implement ANSI SQL tốt hơn — nó còn có nhiều extension mà MySQL không hỗ trợ native. Đây là lý do PG đang chiếm thị phần trong dev community.

Theo Stack Overflow Developer Survey 2025, PostgreSQL đạt 55.6% — lần đầu vượt MySQL (39.6%) trong database phổ biến nhất với developer. Xu hướng này bắt đầu từ khoảng 2020 khi ecosystem extension của PG trở nên đặc biệt mạnh cho workload hiện đại.

5 extension đáng chú ý sẽ học trong khoá này:

• JSONB (Module 9 của khoá này) — JSON binary indexable, query JSON như relational data
• pgvector (Module 9 của khoá này) — vector similarity search cho AI/ML workload
• pg_trgm (Module 9 của khoá này) — trigram similarity cho fuzzy text search
• Window functions nâng cao (Module 8 của khoá này) — DISTINCT ON, NTILE, frame specification chi tiết
• Row-Level Security (Module 10 của khoá này) — policy-based access control tại mức database row

6. Cách khoá học này xử lý multi-engine

Khoá này baseline PostgreSQL. 90% syntax và behavior của bài học áp dụng nguyên vẹn cho MySQL và SQLite. Khi syntax hoặc behavior thực sự khác giữa PG và MySQL, sẽ có callout:

<Callout type="info" title="MySQL khác:">
MySQL không hỗ trợ DISTINCT ON. Workaround: subquery với GROUP BY + JOIN.
</Callout>

Mọi bài còn lại assume PG syntax trừ khi có callout rõ ràng. SQLite và MSSQL chỉ flag khi behavior cực kỳ khác và quan trọng với người học.

7. Pitfall — 3 trap khi học SQL multi-vendor

8. Applied — đọc docs vendor mình đang dùng

Mỗi vendor có official documentation riêng, cập nhật theo phiên bản. Nếu code production trên PG, bookmark postgresql.org/docs/current — đây là source of truth cho mọi tính năng PG.

Nguyên tắc: 5 phút đọc docs chính thức tiết kiệm hơn 30 phút debug syntax error. Khi không chắc một tính năng có portable không, kiểm tra docs của vendor bạn đang dùng trước khi thử.

ORM và behavior khác biệt:

ORM (Prisma, JPA, SQLAlchemy, ActiveRecord) abstract được phần lớn syntax khác biệt — bạn viết code ORM, ORM generate SQL phù hợp từng vendor. Nhưng ORM không abstract được behavior khác biệt:

• Case sensitivity của identifier: ORM generate tên bảng đúng, nhưng nếu database và OS config khác nhau, vẫn có thể fail
• Boolean semantics: ORM map Bool field sang đúng column type, nhưng raw query bypass ORM vẫn cần cẩn thận
• String padding compare: ORM không tự TRIM() — data đã có trailing space vẫn gây mismatch

Khi đổi vendor production (dù có ORM), vẫn cần kiểm tra 8 điểm trên bằng integration test thực sự.

9. Deep Dive — SQL standards và vendor differences

10. Tóm tắt

• ANSI SQL standard (1986 → 2023) là chuẩn — mọi vendor implement subset + extension riêng; 90% query cơ bản portable
• 8 chỗ khác biệt chính: identifier quoting, string concat, auto-increment, LIMIT pagination, boolean type, identifier case, UPSERT syntax, string padding compare
• 3 trap thực sự gây bug khi port code: identifier case (macOS OK, Linux fail), boolean type mismatch, string trailing-space compare silent mismatch
• PG ecosystem extension là lý do dominance từ 2020: JSONB, pgvector, pg_trgm, window functions nâng cao, Row-Level Security
• ORM abstract syntax khác biệt nhưng không abstract behavior khác biệt — vẫn cần biết flavor differences khi đổi vendor
• Khoá học flag bằng <Callout title="MySQL khác:"> chỉ ở chỗ thực sự khác — phần còn lại assume PG
• Forward links: Module 9 (JSONB/pgvector/pg_trgm) và Module 10 (Row-Level Security) của khoá này

11. Tự kiểm tra

Bài tiếp theo: Module 2 — Truy vấn cơ bản — SELECT, WHERE, NULL three-valued logic