Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
Phân vùng không phải luôn nhanh hơn. Đo thật: cùng 3 triệu dòng, truy vấn khớp khóa phân vùng nhanh gấp 5 lần, nhưng truy vấn point lookup theo cột khác lại chậm gấp 20 lần (phải dò index của cả 50 vùng) cộng planning đắt gấp 7 lần. Khi nào phân vùng đáng, khi nào chỉ thêm phức tạp. PostgreSQL 16.
PostgreSQL có ba kiểu phân vùng: RANGE theo khoảng (ngày, số) cho dữ liệu thời gian, LIST theo giá trị rời rạc (miền, loại), HASH chia đều theo băm khóa. Đo thật: dòng tự định tuyến vào đúng vùng (RANGE 100k mỗi năm, HASH cân bằng ~100k mỗi vùng), và một truy vấn chỉ quét đúng partition liên quan. Khi nào dùng kiểu nào. PostgreSQL 16.
Cùng một kế hoạch có thể nhanh hay chậm tuỳ dữ liệu nằm trong cache hay trên đĩa. Tuỳ chọn BUFFERS của EXPLAIN cho bạn thấy số trang shared hit so với read, chìa khoá hiểu cache lạnh và nóng — đo thật trên PostgreSQL 16.
Trước khi tối ưu phải có mốc đo tin cậy. Cách dùng pgbench sinh dữ liệu lớn và đo TPS/latency thật, phân biệt tải đọc và đọc-ghi, và những nguyên tắc để con số không bị nhiễu bởi cache lạnh hay dữ liệu tí hon.
Planner quy mọi kế hoạch về một con số cost để so sánh. Hiểu công thức từ seq_page_cost, cpu_tuple_cost, và tự tay tính lại đúng cost một Seq Scan — rồi thấy planner luôn chọn phương án cost thấp nhất.
TRUNCATE vứt cả tệp dữ liệu nên gần như tức thời và trả chỗ ngay; DELETE quét từng dòng, để lại dead tuple và bảng không nhỏ lại. Đo thật: làm rỗng bảng 3 triệu dòng mất 678 ms với DELETE so với 20 ms với TRUNCATE. Cùng khác biệt về giao dịch, sequence và trigger. PostgreSQL 16.