SELECT — projection + alias, vì sao SELECT * chậm gấp 17 lần

Cùng query trên bảng tasks 100k row của TaskFlow — SELECT * FROM tasks WHERE id=42 mất 200ms. SELECT id, title FROM tasks WHERE id=42 mất 12ms. Cùng một row được trả về, khác ở chỗ query chọn bao nhiêu column — chênh nhau 17 lần. Nếu disk I/O không phải nguyên nhân (cả hai query đều tìm đúng một row bằng primary key index), thì vì sao?

Bài này giải thích cơ chế projection diễn ra ở executor layer, cost thực sự nằm ở network và serialization, cú pháp đầy đủ của SELECT (column list, expression, alias), và vì sao mọi ORM — Prisma, Spring Data JPA, SQLAlchemy — đều đặt explicit column là best practice.

1. Analogy — Lấy hàng từ kho

Hình dung kho hàng với mỗi sản phẩm được đóng trong thùng lớn gồm 50 ngăn. Bạn chỉ cần lấy 2 món: nhãn sản phẩm và giá. Có hai cách:

Cách A: Lấy cả thùng ra xe tải, chở về kho phân phối, mở ra, lấy 2 món cần, bỏ 48 món còn lại.

Cách B: Mở thùng tại chỗ, lấy đúng 2 món, để lại 48 món trong kho.

Cách A tốn xe tải to hơn, tốn thời gian bốc dỡ, tốn không gian tạm chứa — dù kết quả cuối cùng giống nhau.

2. Cơ chế projection — diễn ra ở đâu

PostgreSQL executor xử lý query theo pipeline. Với SELECT id, title FROM tasks WHERE id=42:

flowchart LR
  A["Heap scan / Index scan\n(đọc row từ disk)"] --> B["WHERE filter\n(id = 42)"]
  B --> C["Project\n(chỉ giữ id, title)"]
  C --> D["Serialize → wire\n(binary protocol gửi về client)"]

Projection diễn ra ở bước 3 — sau khi scan và filter xong. Vì vậy:

• SELECT * và SELECT id, title đọc cùng lượng disk I/O để tìm row (cùng index lookup trên id).
• Sự khác biệt nằm ở bước 3 và 4: project giữ bao nhiêu column → serialize bao nhiêu byte → gửi bao nhiêu qua network.

Với bảng tasks có 12 column (bao gồm description TEXT có thể chứa vài KB), SELECT * có thể trả về row nặng hơn SELECT id, title hàng chục lần. Multiply với 100k row trong một batch query — chênh lệch rõ ràng.

Xem số liệu thực tế qua EXPLAIN ANALYZE:

-- Xem "width" -- so byte moi row duoc tra ve
EXPLAIN ANALYZE SELECT * FROM tasks WHERE id = 42;
-- Output: ... (width=312) ...

EXPLAIN ANALYZE SELECT id, title FROM tasks WHERE id = 42;
-- Output: ... (width=28) ...

Cột width trong output EXPLAIN là số byte trung bình mỗi row. Bài Module 7 của khoá này sẽ đi sâu vào đọc EXPLAIN plan.

3. Cú pháp đầy đủ

-- 1. Column list explicit (best practice cho app code)
SELECT id, title, status FROM tasks;

-- 2. Toan bo column -- dung cho exploration, khong dung trong app code
SELECT * FROM tasks;

-- 3. Expression trong SELECT -- tinh toan gia tri tu column
SELECT
    id,
    UPPER(title)                                        AS title_upper,
    EXTRACT(EPOCH FROM (now() - created_at))::int       AS age_seconds,
    (status = 'done')::int                              AS is_done_int
FROM tasks;

-- 4. Alias -- doi ten column trong output
SELECT
    id          AS task_id,
    title       AS "Tieu de"   -- quote khi alias co space hoac trung keyword
FROM tasks;

-- 5. SELECT khong tu table -- constant query, ham utility
SELECT 1 + 1 AS sum, now() AS current_time, version() AS pg_version;

Column trong SELECT list có thể là:

• Tên column trực tiếp: id, title
• Expression: UPPER(title), salary * 12, (status = 'done')::int
• Constant: 1, 'hello', true
• Function call: now(), version(), COALESCE(assignee_id, 0)

4. Alias — quy tắc và pitfall

Alias với AS:

SELECT
    id          AS task_id,          -- doi ten column trong output
    title       AS task_title,
    status      AS current_status
FROM tasks;

AS là optional — SELECT id task_id cũng hoạt động — nhưng nên viết explicit để code dễ đọc.

Quote alias khi cần:

SELECT
    title       AS "Tieu de cong viec",  -- co space -> phai quote
    status      AS "order"               -- 'order' la keyword -> nen quote
FROM tasks;

Alias không được quote: PostgreSQL tự lowercase (TaskId thành taskid). Alias được quote: preserve case chính xác.

Alias không dùng được trong WHERE cùng query:

-- SAI: alias annual_salary chua ton tai khi WHERE duoc tinh
SELECT salary * 12 AS annual_salary
FROM employees
WHERE annual_salary > 100000;
-- ERROR: column "annual_salary" does not exist

Lý do: thứ tự xử lý của SQL engine là FROM → WHERE → SELECT → ORDER BY. Alias trong SELECT chỉ tồn tại sau khi SELECT clause được evaluate — tức là sau khi WHERE đã chạy xong. Hai cách fix:

-- Fix 1: lap lai expression trong WHERE
SELECT salary * 12 AS annual_salary
FROM employees
WHERE salary * 12 > 100000;

-- Fix 2: wrap subquery (hoac CTE -- Module 8 cua khoa nay)
SELECT *
FROM (
    SELECT *, salary * 12 AS annual_salary FROM employees
) sub
WHERE annual_salary > 100000;

5. Vì sao SELECT * có hại trong production

Bốn lý do thực tế:

1. Schema fragile:

-- Schema hom nay: users(id, email, name, created_at)
SELECT * FROM users;  -- tra ve 4 column

-- Sau khi DBA them column: users(id, email, name, created_at, last_login_at, is_active, ...)
SELECT * FROM users;  -- dot nhien tra ve 7 column
-- App code parse theo thu tu column truoc -> parse sai hoac broken

Explicit column list không bị ảnh hưởng khi schema thêm column — chỉ trả về đúng những gì đã khai báo.

2. N+1 amplification:

Với lazy load ORM + SELECT *, mỗi entity fetch 50 column thay vì 5 column cần dùng. Multiply với 1000 entity trong một request — memory và network sử dụng gấp 10 lần không cần thiết.

3. Covering index miss:

Khi tất cả column cần thiết đã có trong index (covering index), PostgreSQL có thể trả về kết quả từ index mà không cần đọc heap. SELECT * phá vỡ optimization này vì index không bao giờ chứa mọi column — database phải hit heap mỗi row. Module 5 của khoá này sẽ phân tích covering index chi tiết.

4. Sensitive data leak:

6. Khi nào SELECT * vẫn ổn

SELECT * không phải lúc nào cũng sai — context quyết định:

Pattern ngắn gọn: production app code = explicit column. CLI/migration/exploration = SELECT * ổn.

7. Applied — ORM convention

Lý do explicit column là best practice lan rộng sang mọi ORM:

Prisma:

// KHONG tot -- tuong duong SELECT *
const tasks = await prisma.task.findMany();

// Tot -- explicit column, type-safe, generated types match
const tasks = await prisma.task.findMany({
  select: {
    id: true,
    title: true,
    status: true,
  },
});
// tasks co kieu: { id: bigint; title: string; status: string }[]

Prisma select generate type narrowed — TypeScript biết chính xác những field nào có trong kết quả. Thêm select: { passwordHash: true } thì type tự xuất hiện — không thêm thì không có trong type, không thể truy cập nhầm.

Spring Data JPA:

// JPQL explicit column -- DTO projection
@Query("SELECT u.id, u.email FROM User u WHERE u.isActive = true")
List<Object[]> findActiveUserProjection();

// Hoac dung DTO projection interface (Spring Data 2.x+)
public interface UserSummary {
    Long getId();
    String getEmail();
}
List<UserSummary> findByIsActive(boolean isActive);

node-postgres (stack trong project TaskFlow):

// Explicit column -- an toan va ro rang ve intent
const { rows } = await pool.query(
  'SELECT id, title, status FROM tasks WHERE assignee_id = $1',
  [userId]
);

SQLAlchemy:

# Explicit column projection
results = session.query(User.id, User.email).filter(User.is_active == True).all()
# Khong: session.query(User).all()  -- equivalent SELECT *

Cross-link: khoá Spring Data JPA của OLHub — Module 4 phân tích DTO projection pattern và interface-based projection theo cùng tư duy explicit column này.

8. Deep Dive — SELECT execution

9. Tóm tắt

• Projection chạy ở executor layer — sau scan và WHERE filter, trước serialize/network.
• Cost chính nằm ở network và serialization, không phải disk I/O — lý do SELECT * vs SELECT id, title chênh nhiều dù cùng row.
• Cú pháp SELECT: column list, expression (UPPER, EXTRACT, cast), alias với AS (quote khi có space hoặc reserved word).
• Alias không dùng được trong WHERE cùng query — alias chưa tồn tại khi WHERE được evaluate. Fix: lặp lại expression hoặc dùng subquery/CTE.
• SELECT * có 4 vấn đề production: schema fragile, N+1 amplification, covering index miss, sensitive data leak.
• SELECT * ổn trong: psql exploration, migration script, backup, view definition — không phải app code.
• Mọi ORM đều reflect tư duy này: Prisma select:{}, Spring DTO projection, SQLAlchemy query(Model.col).
• Forward links: Module 5 (covering index) + Module 7 (EXPLAIN ANALYZE) + Module 8 (subquery/CTE) của khoá này.

10. Tự kiểm tra

SELECT salary * 12 AS annual_salary
FROM employees
WHERE salary * 12 > 100000;

SELECT * FROM (
SELECT *, salary * 12 AS annual_salary
FROM employees
) sub
WHERE annual_salary > 100000;

Bài tiếp theo: WHERE + NULL three-valued logic