Đáp án Quiz PostgreSQL — 76 câu hỏi có giải thích

Đáp án: C

So sánh có thứ tự: =, <, <=, >, >=, BETWEEN, IN, và cả ORDER BY trên cột đó. Vì B-tree lưu giá trị đã sắp xếp nên vừa tra điểm, vừa quét khoảng, vừa trả kết quả đúng thứ tự mà không cần sort thêm.

Đáp án: B

EXPLAIN chỉ hiện plan với ước lượng (cost, rows dự đoán) mà không chạy truy vấn. EXPLAIN ANALYZE thực thi thật rồi in kèm số đo thực tế: actual time, số dòng thật, số lần loop. So sánh rows ước lượng với rows thực tế là cách chẩn đoán plan kém phổ biến nhất.

Đáp án: A

Vì đó là lựa chọn rẻ hơn thật. Bảng vài trăm dòng chỉ chiếm vài page; Seq Scan đọc thẳng chúng, còn Index Scan phải đọc index rồi quay lại heap lấy dòng — nhiều bước hơn cho cùng kết quả. Seq Scan không phải dấu hiệu xấu; nó chỉ xấu khi xuất hiện trên bảng lớn với điều kiện lọc chọn lọc cao.

Đáp án: B

Không cần. PostgreSQL thi hành UNIQUE constraint bằng cách tự tạo một B-tree unique index trên cột đó — và index này phục vụ tra cứu WHERE email = ... như mọi index thường. Tạo thêm index trên cùng cột chỉ tốn gấp đôi chi phí ghi và đĩa mà không nhanh thêm chút nào.

Đáp án: C

Cả hai chạy song song. MVCC (Multi-Version Concurrency Control) giữ nhiều phiên bản của mỗi row: reader đọc phiên bản đã commit theo snapshot của mình, writer tạo phiên bản mới. Vì vậy trong Postgres, đọc không chặn ghi và ghi không chặn đọc — chỉ hai writer trên cùng một row mới phải chờ nhau.

Đáp án: B

Postgres không sửa row tại chỗ: UPDATE tạo một phiên bản row mới, còn phiên bản cũ chỉ bị đánh dấu hết hạn và trở thành dead tuple — chiếm chỗ trên đĩa tới khi VACUUM dọn. DELETE cũng vậy: row chỉ bị đánh dấu, chưa biến mất.

Đáp án: A

VACUUM dọn dead tuples — các phiên bản row cũ do UPDATE/DELETE để lại — để chỗ trống được tái sử dụng cho lần ghi sau, đồng thời cập nhật visibility map và bảo vệ hệ thống khỏi transaction ID wraparound. Autovacuum là tiến trình nền tự chạy việc này; bình thường không cần chạy VACUUM tay.

Đáp án: A

JSONB lưu dạng nhị phân đã phân tích sẵn, JSON lưu nguyên chuỗi văn bản. Vì thế JSONB ghi chậm hơn một chút (phải parse) nhưng đọc và lọc nhanh hơn nhiều, hỗ trợ GIN index và các toán tử chứa (@>). Hầu hết trường hợp thực tế nên chọn JSONB.

Đáp án: B

-> trả về giá trị kiểu jsonb, ->> trả về text. Mẫu thường gặp: dùng -> để đi qua các cấp trung gian, và ->> ở bước cuối khi cần so sánh hoặc hiển thị dưới dạng chuỗi.

Đáp án: D

Dùng timestamptz. Nó lưu một mốc tuyệt đối (chuẩn hoá về UTC) và hiển thị theo TimeZone của phiên, nên phép so sánh và sắp xếp luôn đúng. timestamp không có múi giờ chỉ hợp cho thời gian mang tính địa phương thuần tuý như giờ mở cửa cửa hàng.

Đáp án: C

Mặc định UNIQUE cho phép nhiều dòng NULL, vì trong SQL hai NULL không bằng nhau. Từ PostgreSQL 15 có thể đổi hành vi bằng UNIQUE NULLS NOT DISTINCT để chỉ cho phép đúng một dòng NULL.

Đáp án: C

Index là đánh đổi đọc nhanh hơn — ghi chậm hơn: mỗi lần ghi phải cập nhật mọi index liên quan, và index chiếm thêm dung lượng cùng bộ nhớ đệm. Index không được truy vấn nào dùng chỉ có chi phí, không có lợi ích.

Đáp án: B

Dùng numeric(precision, scale). Kiểu này tính theo thập phân nên 0.1 + 0.2 cho đúng 0.3, không như float8. Cách khác cũng phổ biến là lưu số nguyên đơn vị nhỏ nhất (đồng, xu) bằng bigint — luôn chính xác, đổi lại phải tự quy đổi khi hiển thị.

Đáp án: C

Khi dòng cha bị xoá, mọi dòng con tham chiếu tới nó cũng bị xoá theo. Các lựa chọn khác: RESTRICT/NO ACTION chặn thao tác xoá, SET NULL và SET DEFAULT đổi giá trị cột khoá ngoại. Mặc định là NO ACTION.

Đáp án: D

WHERE lọc từng dòng trước khi gộp nhóm; HAVING lọc từng nhóm sau khi đã tính hàm tổng hợp. Vì vậy HAVING COUNT(*) > 5 hợp lệ còn WHERE COUNT(*) > 5 thì không. Điều kiện nào đặt được ở WHERE thì nên đặt ở đó vì rẻ hơn.

Đáp án: B

Dùng bảng tra cứu khi tập giá trị có thể thay đổi, cần đính kèm thuộc tính (nhãn hiển thị, thứ tự, màu), hoặc cần người vận hành tự thêm. Dùng enum khi tập giá trị gần như cố định và muốn ràng buộc ở tầng kiểu dữ liệu.

Đáp án: A

COUNT(*) đếm mọi dòng. COUNT(column) chỉ đếm dòng có giá trị khác NULL ở cột đó. Đây là cách gọn để đếm có điều kiện: COUNT(*) FILTER (WHERE status = 1) hoặc COUNT(NULLIF(status, 0)).

Đáp án: C

GENERATED ALWAYS AS IDENTITY là cú pháp chuẩn SQL và được khuyến nghị. serial chỉ là cách viết tắt tạo sequence rồi gán làm giá trị mặc định, nên sequence tồn tại tách rời và dễ gây rắc rối về quyền cũng như khi xoá cột.

Đáp án: C

Cả transaction chuyển sang trạng thái huỷ bỏ: mọi câu lệnh sau đó đều trả lỗi cho tới khi ROLLBACK. Muốn tiếp tục sau lỗi phải đặt SAVEPOINT trước và ROLLBACK TO SAVEPOINT khi lỗi xảy ra.

Đáp án: B

Dùng COPY — nhanh hơn INSERT từng dòng nhiều lần vì bỏ qua chi phí phân tích và lập kế hoạch cho từng câu lệnh. Với dữ liệu đến từ ứng dụng, hầu hết driver đều hỗ trợ COPY … FROM STDIN để đẩy theo luồng mà không cần file trung gian.

Đáp án: B

GIN (CREATE INDEX ... USING gin (attrs)). GIN tách jsonb thành các phần tử con và lập chỉ mục từng phần, nên các toán tử @>, ?, ?& tra được thẳng vào index. Cùng lý do đó, GIN cũng là lựa chọn cho array và full-text search.

Đáp án: C

BRIN (Block Range Index). BRIN chỉ lưu min/max của từng dải block thay vì từng dòng, nên với 500 triệu dòng nó chiếm cỡ vài MB trong khi B-tree tương đương chiếm hàng chục GB. Điều kiện tiên quyết: giá trị cột phải tương quan với thứ tự vật lý — bảng log append-only theo thời gian thoả điều kiện này một cách tự nhiên.

Đáp án: B

Chỉ truy vấn có điều kiện bao được mệnh đề WHERE của index — ở đây là status = 'pending'. Partial index hợp lý khi ứng dụng lặp đi lặp lại một tập con nhỏ: đơn chưa xử lý, user chưa xoá, job đang chờ. Index nhỏ hơn nhiều lần so với index cả bảng và không tốn chi phí ghi cho các dòng ngoài điều kiện.

Đáp án: C

Leftmost prefix rule: composite index (a, b) sắp xếp theo a trước, rồi mới tới b trong từng nhóm a. Truy vấn chỉ lọc b (created_at) không có điểm vào — giá trị created_at nằm rải rác khắp cây. Muốn lọc riêng created_at thì cần index riêng cho nó.

Đáp án: A

Index lập trên giá trị email gốc, còn truy vấn lọc theo lower(email) — hai thứ khác nhau, planner không tự suy ra được. Fix: CREATE INDEX ON users (lower(email)). Đây là lý do chung cho quy tắc "đừng bọc cột trong hàm ở mệnh đề WHERE" — mọi hàm bao ngoài cột (date_trunc, ép kiểu, phép toán) đều vô hiệu hoá index thường theo cùng cơ chế.

Đáp án: C

B-tree sắp chuỗi theo thứ tự từ ký tự đầu tiên. LIKE 'abc%' tương đương khoảng >= 'abc' AND < 'abd' — một dải liên tục trong cây. Còn '%abc' cần biết phần cuối chuỗi, thứ mà cây sắp theo đầu chuỗi không giúp gì được, nên phải quét toàn bộ.

Đáp án: C, D, E

Index là đánh đổi đọc-ghi: đọc nhanh hơn, đổi lại mỗi lần ghi phải cập nhật thêm mọi index của bảng, cộng dung lượng đĩa riêng cho từng index. Index thừa (không truy vấn nào dùng) là chi phí thuần — nên tìm và gỡ định kỳ qua pg_stat_user_indexes.

Đáp án: B

Chạy ANALYZE bảng_đó. Planner ước chi phí dựa trên thống kê mẫu trong pg_statistic (số dòng, phân bố giá trị, tương quan). Sau bulk load, thống kê vẫn mô tả bảng cũ nên ước lượng lệch hàng chục lần và planner chọn sai plan. Dấu hiệu nhận biết trong EXPLAIN ANALYZE: rows ước lượng chênh xa rows thực tế.

Đáp án: C

Ba giai đoạn: (1) dead tuples tích tụ → bảng và index phình, (2) query chậm dần vì scan phải lướt qua tuple chết, thống kê planner cũ dần, (3) khi transaction ID tiến gần giới hạn 32-bit, Postgres chạy vacuum khẩn cấp và nếu vẫn không kịp thì từ chối nhận ghi để chống wraparound. Tắt autovacuum là khoản nợ chắc chắn phải trả.

Đáp án: D

DELETE chỉ đánh dấu row thành dead tuple. VACUUM dọn chúng và giữ chỗ trống lại trong file để tái sử dụng — nó chỉ trả đĩa cho OS khi các page rỗng nằm liền ở cuối file. Chỗ trống rải rác giữa file thì ở nguyên đó: đây gọi là table bloat. Muốn co file thật sự cần VACUUM FULL hoặc pg_repack.

Đáp án: B

Postgres chấp nhận cú pháp nhưng đối xử y hệt READ COMMITTED — dirty read không bao giờ xảy ra trong Postgres vì MVCC chỉ cho thấy dữ liệu đã commit. Mặc định của Postgres là READ COMMITTED; hai mức còn lại là REPEATABLE READ và SERIALIZABLE.

Đáp án: C

100. Ở REPEATABLE READ, snapshot được chụp tại câu lệnh đầu tiên của transaction và dùng cho toàn bộ transaction — commit của B xảy ra sau thời điểm đó nên A không nhìn thấy. Nếu chạy ở READ COMMITTED (mặc định), mỗi câu lệnh lấy snapshot mới và SELECT thứ hai trả về 101.

Đáp án: C

SELECT ... FOR UPDATE khoá row ngay lúc đọc: transaction thứ hai chạm vào row đó phải chờ transaction đầu commit, rồi mới đọc — và đọc được giá trị mới. Chuỗi đọc-tính-ghi vì thế thành tuần tự trên từng row. Chỉ BEGIN...COMMIT không đủ, vì SELECT thường không khoá gì.

Đáp án: B

Nhìn vào số row bị ảnh hưởng của UPDATE: nếu là 0, nghĩa là ai đó đã tăng version trước, điều kiện version = 3 không khớp nữa — ứng dụng đọc lại dữ liệu mới và quyết định thử lại hay báo người dùng. Không có lỗi nào được ném; việc kiểm tra là trách nhiệm của ứng dụng.

Đáp án: A

Đây là deadlock: T1 giữ row 1 chờ row 2, T2 giữ row 2 chờ row 1 — chu trình chờ khép kín. Postgres tự phát hiện (kiểm tra sau deadlock_timeout, mặc định 1s) và abort một transaction với lỗi deadlock detected; transaction còn lại chạy tiếp. Ứng dụng phải bắt lỗi này và retry.

Đáp án: C, D, E

idle in transaction = đã BEGIN, đã chạy lệnh, rồi treo không commit. Ba tác hại: (1) giữ nguyên mọi lock đã lấy — chặn query khác và chặn cả migration; (2) chặn VACUUM dọn dead tuples cũ hơn snapshot của nó → bloat toàn cluster; (3) chiếm connection vô ích. Phòng bằng idle_in_transaction_session_timeout (mặc định tắt) và soát code quên commit.

Đáp án: C

Tách ra cột riêng khi field được lọc/join thường xuyên, cần ràng buộc (NOT NULL, foreign key, CHECK) hoặc cần planner có thống kê tốt. Giữ trong JSONB phần dữ liệu có cấu trúc thay đổi, ít truy vấn — hai cách này bổ sung nhau, không loại trừ nhau.

Đáp án: C

Partition pruning: điều kiện trên partition key (created_at) cho phép planner loại các partition tháng cũ khỏi plan — query chỉ chạm 1–2 partition thay vì toàn bộ dữ liệu lịch sử. Index cũng nhỏ hơn theo từng partition nên đường đọc nóng gọn hơn.

Đáp án: B

DROP partition các tháng cũ (hoặc DETACH trước nếu muốn giữ lại để archive). Đây là thao tác metadata gần như tức thời. DELETE cùng lượng dữ liệu sẽ tạo hàng triệu dead tuple, phình WAL, và cần vacuum dọn lại — chênh lệch từ hàng giờ xuống mili giây.

Đáp án: C

Streaming (physical): chép WAL ở mức byte, replica là bản sao y hệt toàn cluster, chỉ đọc, cùng major version. Logical: decode WAL thành các thay đổi INSERT/UPDATE/DELETE rồi phát tới subscriber theo bảng đã chọn (publication) — cho phép replicate một phần, khác version, và subscriber vẫn ghi được.

Đáp án: C

Đây là replication lag: với async replication, commit ở primary trả về không chờ replica nhận WAL, nên đọc ngay từ replica có thể ra dữ liệu cũ (stale read). Đây là hành vi bình thường của kiến trúc read replica, không phải bug — ứng dụng phải thiết kế quanh nó.

Đáp án: B

Postgres theo mô hình process-per-connection: mỗi connection fork một backend process riêng, tốn RAM và chi phí khởi tạo. Hàng nghìn function ngắn hạn mở/đóng connection sẽ làm server cạn tài nguyên dù đa số connection đang rỗi. Pooler giữ một nhóm nhỏ connection thật tới Postgres và cho nhiều client dùng chung.

Đáp án: D

UPSERT: xung đột trên unique constraint (user_id, day) kích hoạt nhánh DO UPDATE, cộng dồn views = 5 + 1 = 6. EXCLUDED là dòng định chèn nhưng bị từ chối; stats.views là giá trị hiện có trong bảng. Toàn bộ diễn ra nguyên tử trong một câu lệnh.

Đáp án: A

EXPLAIN chỉ hiển thị kế hoạch cùng ước lượng chi phí và số dòng. EXPLAIN ANALYZE thực thi truy vấn rồi báo thời gian và số dòng thật. Chênh lệch lớn giữa rows= ước lượng và actual rows= chính là manh mối chẩn đoán quan trọng nhất.

Đáp án: D

Không hiệu quả. Index B-tree nhiều cột sắp theo cột đầu trước, nên chỉ hữu ích khi điều kiện có cột dẫn đầu (hoặc tiền tố của danh sách cột). Lọc riêng created_at cần index riêng cho cột đó, hoặc đảo thứ tự thành (created_at, user_id) nếu mẫu truy vấn phổ biến là như vậy.

Đáp án: D

Tạo index biểu thức: CREATE INDEX ON users (lower(email)). Index B-tree lưu giá trị của cột, còn điều kiện lọc lại so sánh kết quả của một hàm — hai thứ này không khớp nhau nên index thường không dùng được.

Đáp án: C

Mặc định là Read Committed: mỗi câu lệnh nhìn thấy ảnh chụp dữ liệu tại thời điểm câu lệnh đó bắt đầu, nên không có dirty read. Nhưng non-repeatable read và phantom read vẫn có thể xảy ra giữa hai câu lệnh trong cùng một transaction.

Đáp án: D

PostgreSQL tự phát hiện deadlock: sau deadlock_timeout (mặc định 1 giây), nó dựng đồ thị chờ khoá, phát hiện chu trình và huỷ một transaction với lỗi deadlock detected. Transaction bị huỷ phải được ứng dụng thử lại.

Đáp án: A

json lưu nguyên văn bản (giữ khoảng trắng, thứ tự khoá, khoá trùng) và phải phân tích lại mỗi lần truy vấn. jsonb lưu dạng nhị phân đã phân tích: ghi chậm hơn chút, đọc nhanh hơn nhiều, và index GIN được. Gần như mọi trường hợp nên chọn jsonb.

Đáp án: A

Thường vì truy vấn trả về tỷ lệ dòng lớn: index scan phải nhảy ngẫu nhiên giữa index và bảng, còn seq scan đọc tuần tự nên nhanh hơn khi cần phần lớn dữ liệu. Các nguyên nhân khác: thống kê cũ, bảng nhỏ, hoặc kiểu dữ liệu không khớp làm điều kiện phải ép kiểu.

Đáp án: D

Vì MVCC không sửa dòng tại chỗ: UPDATE tạo phiên bản mới và đánh dấu phiên bản cũ là chết. VACUUM thu hồi không gian đó, cập nhật thống kê, và quan trọng nhất là đóng băng transaction id để tránh sự cố wraparound.

Đáp án: B

Đây là thao tác upsert: chèn mới, và nếu vi phạm ràng buộc duy nhất thì cập nhật dòng đang có. Ưu điểm so với "kiểm tra rồi ghi" ở tầng ứng dụng là tính nguyên tử — không có khoảng trống để một transaction khác chen vào giữa hai bước.

Đáp án: D

SELECT DISTINCT ON (user_id) * FROM logs ORDER BY user_id, created_at DESC — với index trên (user_id, created_at DESC) thì đây là cách gọn và nhanh nhất. Hai phương án chuẩn SQL tương đương: window function ROW_NUMBER(), hoặc LATERAL JOIN khi bảng người dùng nhỏ.

Đáp án: C

PostgreSQL cấp một tiến trình riêng cho mỗi kết nối, tốn vài megabyte bộ nhớ và chi phí thiết lập đáng kể. Pooler (PgBouncer, hoặc pooler tích hợp của nhà cung cấp) giữ sẵn một tập kết nối nhỏ và tái sử dụng, nên hàng nghìn client dùng chung vài chục kết nối thật.

Đáp án: D

bigint chiếm 8 byte, chèn tuần tự nên index gọn và ghi nhanh, nhưng lộ thứ tự và số lượng bản ghi. uuid chiếm 16 byte và sinh được ở client trước khi ghi — điểm quan trọng với hệ thống phân tán. UUID v7 giải quyết phần lớn nhược điểm hiệu năng nhờ tiền tố theo thời gian.

Đáp án: D

Từ PostgreSQL 12, CTE không đệ quy và chỉ được tham chiếu một lần sẽ được inline vào truy vấn chính, nên điều kiện lọc đẩy xuống được. Có thể ép hành vi bằng WITH … AS MATERIALIZED hoặc AS NOT MATERIALIZED.

Đáp án: C

GROUP BY gộp nhiều dòng thành một dòng cho mỗi nhóm. Window function tính trên một "cửa sổ" dòng nhưng giữ nguyên từng dòng, nên viết được các truy vấn kiểu "doanh thu dòng này và tổng doanh thu của tháng chứa nó" trong một lần quét.

Đáp án: D

Nó gộp các truy vấn theo dạng chuẩn hoá (bỏ giá trị tham số) và tổng hợp số lần gọi, tổng thời gian, thời gian trung bình, số dòng, số lần đọc từ cache và từ đĩa. Đây là công cụ đầu tiên nên dùng khi cần biết truy vấn nào đang chiếm tài nguyên.

Đáp án: C

Cột dẫn xuất được database tính từ các cột khác trong cùng dòng và lưu vật lý, nên luôn nhất quán và index được. Trường hợp dùng phổ biến: cột tsvector cho full-text search, giá trị đã chuẩn hoá để so khớp, và tổng thành tiền tính từ số lượng nhân đơn giá.

Đáp án: B

View thường chỉ là truy vấn được đặt tên — chạy lại mỗi lần đọc. Materialized view lưu kết quả vật lý: đọc nhanh và index được, nhưng dữ liệu là ảnh chụp tại lần làm mới gần nhất và phải gọi REFRESH MATERIALIZED VIEW.

Đáp án: A

Lợi ích rõ nhất là quản lý vòng đời dữ liệu: xoá dữ liệu cũ bằng DROP một partition thay vì DELETE hàng chục triệu dòng. Lợi ích thứ hai là partition pruning cho truy vấn lọc theo khoá phân mảnh. Ngưỡng thường được nhắc tới là khi bảng vượt vài chục gigabyte.

Đáp án: C

Đặt theo vai trò: vai trò phục vụ web dùng ngưỡng ngắn (vài giây), vai trò chạy báo cáo dùng ngưỡng dài. ALTER ROLE app_web SET statement_timeout = '5s'. Điểm quan trọng là timeout phải ở phía server — huỷ ở client không dừng được truy vấn đang chạy.

Đáp án: B

Đây là khoá do ứng dụng tự quy ước, định danh bằng một số nguyên và không gắn với bảng hay dòng nào. Trường hợp dùng điển hình: bảo đảm chỉ một tiến trình chạy một tác vụ định kỳ, hoặc chỉ một tiến trình chạy migration tại một thời điểm.

Đáp án: B

Dùng mảng khi các phần tử luôn đi cùng dòng cha và không cần truy vấn độc lập: danh sách nhãn, danh sách quyền, các giá trị cấu hình đơn giản. Cần join, ràng buộc khoá ngoại, hoặc gắn thêm thuộc tính cho từng phần tử thì phải tách thành bảng riêng.

Đáp án: B

pg_dump xuất ra dạng logic (câu lệnh SQL hoặc định dạng nén), khôi phục được sang phiên bản khác và chọn được từng bảng, nhưng chỉ là ảnh chụp tại thời điểm chạy. Sao lưu vật lý kèm lưu trữ WAL cho phép khôi phục về một thời điểm bất kỳ và nhanh hơn nhiều trên database lớn.

Đáp án: B

Dùng trigger cho các bất biến phải đúng bất kể ai ghi: nhật ký thay đổi phục vụ đối soát, cột updated_at, kiểm tra ràng buộc phức tạp giữa nhiều bảng. Không dùng cho logic nghiệp vụ hay thay đổi, và tuyệt đối không gọi dịch vụ bên ngoài từ trong trigger.

Đáp án: A

tsvector lưu văn bản đã tách từ và chuẩn hoá về dạng gốc kèm vị trí; tsquery biểu diễn truy vấn tìm kiếm. Toán tử @@ khớp hai bên, và ts_rank tính điểm liên quan để sắp xếp kết quả.

Đáp án: D

TOAST xử lý các giá trị vượt quá kích thước cho phép trong một trang 8KB: nén trước, và nếu vẫn lớn thì cắt thành đoạn lưu ở bảng phụ. Cơ chế này trong suốt với truy vấn, nhưng ảnh hưởng rõ tới hiệu năng khi bảng có cột văn bản hoặc jsonb lớn.

Đáp án: C

Dùng exclusion constraint với kiểu khoảng: EXCLUDE USING gist (room_id WITH =, during WITH &&). Toán tử && phát hiện chồng lấn, và vì ràng buộc do database cưỡng chế nên đúng cả khi nhiều transaction ghi cùng lúc.

Đáp án: C

CREATE STATISTICS stats_name (dependencies) ON city, country FROM addresses rồi chạy ANALYZE. Mặc định bộ tối ưu coi các cột là độc lập và nhân độ chọn lọc, nên với cột phụ thuộc chặt như thành phố và quốc gia, nó ước lượng thấp hơn thực tế nhiều lần.

Đáp án: C

Phù hợp cho báo hiệu nhẹ: thông báo cache cần làm mới, đánh thức worker khi có việc mới, đẩy cập nhật thời gian thực xuống giao diện. Thông điệp không bền vững — tiến trình không kết nối lúc phát sẽ mất thông báo đó.

Đáp án: D

Về hiệu năng, bộ tối ưu của PostgreSQL thường chuyển cả hai thành semi join nên tương đương. Khác biệt thật nằm ở NULL: NOT IN với tập con chứa NULL không bao giờ trả về dòng nào, còn NOT EXISTS hoạt động đúng như mong đợi.

Đáp án: A

Từ PostgreSQL 8.1, CREATE USER chỉ là bí danh của CREATE ROLE … LOGIN. Một role có thể chứa role khác, tạo nên mô hình phân quyền theo nhóm: cấp quyền cho role nghiệp vụ, rồi gán role đó cho từng tài khoản đăng nhập.

Đáp án: D

CREATE INDEX ON orders (created_at) WHERE status = 'pending' — partial index. Nó chỉ chứa 0,1% số dòng nên nhỏ hơn hàng nghìn lần, gần như luôn nằm trong bộ nhớ, và chỉ phải cập nhật khi dòng vào hoặc ra khỏi trạng thái đó.

Đáp án: C

Thêm connection pooler (PgBouncer ở chế độ transaction) và giới hạn kích thước pool ở từng dịch vụ. Tăng max_connections là phản xạ sai: mỗi kết nối là một tiến trình riêng, nên số lượng lớn làm tăng tiêu thụ bộ nhớ và chi phí chuyển ngữ cảnh mà thông lượng không tăng.

Đáp án: C

Chuyển sang phân trang theo con trỏ (keyset pagination): WHERE (created_at, id) < ($1, $2) ORDER BY created_at DESC, id DESC LIMIT 20. OFFSET 100000 buộc database duyệt và bỏ 100.000 dòng; điều kiện so sánh thì nhảy thẳng tới vị trí qua index.