Bài mở đầu sê-ri tối ưu PostgreSQL. Vì sao 'đo trước, đoán sau' là nguyên tắc số một, và cách EXPLAIN (ANALYZE, BUFFERS) cho bạn con số thật thay vì niềm tin — minh hoạ trên bảng 1 triệu dòng, đo trước và sau.
PostgreSQL không có join mặc định — với mỗi truy vấn nó ước lượng số dòng rồi tính chi phí từng kiểu join và chọn cái rẻ nhất. Đo thật: cùng câu JOIN, đổi bộ lọc WHERE khiến planner chuyển từ Nested Loop sang Hash Join. PostgreSQL 16.
Merge Join nối hai luồng đã sắp bằng cách chạy song song hai con trỏ — không cần bảng băm khổng lồ. Đo thật: trên join 3 triệu × 3 triệu, nó nhanh hơn Hash Join khi dữ liệu đã có index, nhưng chậm lại nếu phải Sort trước. PostgreSQL 16.
Autovacuum chạy khi dead tuple vượt threshold cộng scale_factor nhân số dòng sống. Đo thật: scale_factor mặc định 0.2 khiến bảng 100 triệu dòng phải tích 20 triệu dead tuple mới chạy — bloat khổng lồ. Cách chỉnh per-table và theo dõi qua pg_stat_user_tables. PostgreSQL 16.
Mỗi index phải cập nhật theo từng dòng chèn, nên nạp khối lượng lớn vào bảng đã đầy index rất chậm. Đo thật: nạp 3 triệu dòng với 4 index sẵn mất 12,6 giây; bỏ index thứ cấp rồi tạo lại sau khi nạp chỉ 7 giây và bảng còn nhỏ hơn. Và một điểm bất ngờ về maintenance_work_mem. PostgreSQL 16.
Một giao dịch mở lâu giữ xmin horizon, khiến VACUUM không xóa được dead tuple mới hơn nó — kể cả dead tuple do giao dịch khác tạo. Đo thật: bảng phình từ 3,5 MB lên 14 MB với 300k dead tuple không dọn được trong khi một giao dịch REPEATABLE READ còn mở; đóng nó thì VACUUM dọn sạch ngay. Cách tìm thủ phạm và phòng tránh. PostgreSQL 16.