Tưởng kiểm trùng email ở tầng ứng dụng là đủ — cho hai request chạy song song thì cả hai lọt, hai dòng trùng vào bảng. Chỉ UNIQUE ở CSDL mới chặn thật dưới đồng thời. Đo: vi phạm ràng buộc bị từ chối ngay với lỗi rõ, và khóa ngoại không đánh index bên con khiến xóa cha chậm 80 lần.
Tưởng prepared statement luôn nhanh hơn nhiều — đo query nhẹ chỉ nhanh 13%. Nguy hơn: sau 5 lần chạy PostgreSQL có thể đổi sang generic plan, và trên cột lệch nó quét cả bảng 13ms thay vì index scan 0,13ms — nhanh ở khâu parse nhưng chậm gấp trăm ở khâu thực thi. Vẫn phải luôn tham số hóa, vì lý do quan trọng hơn tốc độ.
Chạy VACUUM tưởng đã dọn sạch hàng chết, nhưng một phiên khác đang mở giao dịch dài giữ snapshot cũ, khiến VACUUM chạy không báo lỗi mà bảng vẫn chồng thêm 200k hàng chết mỗi vòng, phình lên gấp 3. Thủ phạm là một BEGIN bị quên commit. Đo bằng hai kịch bản y hệt, chỉ khác một giao dịch treo song song.
VACUUM bảng sau mỗi vòng, thấy bảng đứng yên 14 MB nên tưởng mọi thứ gọn sạch. Nhưng index kẹt ở 8792 kB, mật độ lá chỉ 45% — phình gấp đôi, và VACUUM không bao giờ sửa nổi. Chỉ REINDEX mới nén lại cây. Vì sao phải đo cả index chứ không chỉ bảng, và HOT update giảm phình ngay từ đầu.
Nạp 100.000 dòng bằng INSERT từng dòng mất 8,5 giây, suýt kết luận 'ghi vào CSDL vốn chậm'. Nhưng COPY nạp đúng 100.000 dòng đó chỉ 62ms — nhanh 137 lần, cùng dữ liệu, cùng độ bền. Cái chậm không phải việc ghi mà là mỗi dòng một commit và mỗi câu một lần parse. Đo bốn cách nạp, và tiền thời gian thật đi đâu.
Tôi tưởng một cột text 5KB làm mọi truy vấn trên bảng chậm. Đo: SUM(tag) chỉ 1,5ms vì giá trị lớn nằm ngoài bảng chính, ở TOAST; chỉ khi truy vấn chạm cột đó mới chậm (420ms, ~280 lần). Và nén quyết định tất cả: cùng 5KB×50k hàng, text lặp còn 6,8 MB, dữ liệu ngẫu nhiên phình thành 300 MB.