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.
Một bảng chậm dần theo thời gian có hai nguyên nhân rất khác nhau: bloat (phình do dead tuple) hay thiếu index. Bài này đo thật một bảng phình từ 21 lên 176 MB do UPDATE, cách phân biệt bằng dead tuple và kế hoạch, rồi chữa bằng VACUUM đúng loại. PostgreSQL 16.
Gộp mọi công cụ đã học vào một quy trình thực chiến: phát hiện, đọc kế hoạch, tìm nguyên nhân, sửa, xác nhận. Bài này chẩn đoán thật một truy vấn 49 mili giây quét cả 3 triệu đơn — tìm ra thiếu index, thêm index từng phần nhỏ 7,6 MB, còn 9,5 mili giây. PostgreSQL 16.
Giám sát chỉ có ích khi cảnh báo đúng thứ, đúng lúc. Bài này đo thật trên một database các chỉ số cần đặt ngưỡng báo động: nguy cơ wraparound transaction ID (cảnh báo số một), kết nối gần cạn, giao dịch dài, replication lag, và cache hit ratio. PostgreSQL 16.
pgBadger đọc log PostgreSQL và sinh báo cáo trực quan về truy vấn chậm, giờ cao điểm và lỗi. Bài này dựng thật: cấu hình log, sinh traffic, chạy pgBadger 13.2 trên log 31 MB — báo cáo thật thấy 192 nghìn query gom thành 9 dạng, peak 45 nghìn query mỗi giây, và top query tốn tổng thời gian. PostgreSQL 16.
pg_stat_statements gom mọi lần chạy cùng dạng truy vấn. Bài này đo thật một nghịch lý: một point-lookup 0,008 mili giây chạy 427 nghìn lần chiếm 92,5 phần trăm tổng thời gian database, còn một full scan 94 mili giây chỉ chiếm 7,5 phần trăm — sắp theo mean sẽ đuổi nhầm thủ phạm. PostgreSQL 16.
pg_stat_io là view mới của PG16 tách I/O theo ai gây ra, trên cái gì, và vì sao. Bài này đo thật: một seq scan lớn dùng ring buffer (6,9% hit, 96 nghìn reuses thay vì evictions), extends khi bảng lớn dần, và I/O của VACUUM tách riêng. PostgreSQL 16.