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.
REINDEX co index bloat 172 MB về 21 MB, nhưng nó khóa ghi cả bảng. REINDEX CONCURRENTLY dùng lock nhẹ hơn cho ghi chạy song song. Đo thật lock mode, thời gian, và cách dọn index INVALID trên PostgreSQL 16.
B-tree cần một trục để sắp; điểm hai chiều và khoảng thời gian thì không có. GiST là cây của các hộp bao, cho phép tìm láng giềng gần nhất (KNN) và overlap khoảng. Đo thật: KNN nhanh gấp 578 lần, range overlap gấp 15 lần trên PostgreSQL 16.
Hash index chỉ trả lời được câu hỏi 'khoá này bằng X?' — không range, không ORDER BY, không LIKE. Đổi lại, với khoá dài nó nhỏ hơn B-tree nhiều lần. Đo thật trên bảng 5 triệu phiên, token 101 ký tự, PostgreSQL 16.
Mỗi UPDATE cột có index để lại mục chết; VACUUM dọn chúng nhưng không trả dung lượng về hệ điều hành. Đo thật: index phình từ 21 MB lên 172 MB sau 10 lần update, và vì sao chỉ REINDEX mới co lại được. PostgreSQL 16 với pgstattuple.
PostgreSQL chọn kiểu quét theo số dòng truy vấn trả về, không phải theo việc có index hay không. Đo thật ba kiểu trên bảng 3 triệu dòng, và chứng minh vì sao ép dùng index cho truy vấn lấy nửa bảng chậm gấp 9 lần. PostgreSQL 16.
OR không tự động giết index — nó chỉ nhanh bằng nhánh chậm nhất. Đo thật: OR trên hai cột có index cho BitmapOr 0,09 ms, nhưng chỉ một nhánh thiếu index kéo cả câu thành Seq Scan toàn bảng 48 ms. Và vì sao index gộp phục vụ AND mà không phục vụ OR. PostgreSQL 16.