VACUUM là gì và tại sao nó quan trọng?

Question

Accepted Answer

**`VACUUM`** là tiến trình bảo trì của PostgreSQL giúp thu hồi không gian lưu trữ từ các **dead tuple** (các phiên bản hàng lỗi thời do MVCC để lại) và cập nhật thống kê. Vì MVCC của Postgres tạo ra dead tuple ở mỗi lần UPDATE/DELETE, VACUUM là cần thiết để ngăn **bloat** và giữ cho cơ sở dữ liệu khỏe mạnh. **Autovacuum** tự động hóa việc này.

## Vì sao dead tuple tồn tại (mối liên hệ với MVCC)

```text
MVCC: một UPDATE/DELETE không ghi đè lên hàng — nó đánh dấu phiên bản cũ là lỗi thời
(một "dead tuple") và có thể tạo ra một phiên bản mới. Dead tuple tích lũy theo thời gian.
→ Nếu không dọn dẹp, dead tuple gây ra BLOAT: lãng phí dung lượng đĩa, quét chậm hơn
  (nhiều dữ liệu phải đọc hơn), hiệu năng giảm sút.
VACUUM thu hồi không gian dead này → giữ bảng gọn gàng và truy vấn nhanh.
```

## VACUUM làm gì

```sql
VACUUM users;                  -- thu hồi không gian dead-tuple (tái sử dụng được, nhưng không thu nhỏ file)
VACUUM FULL users;             -- ghi lại bảng → thu hồi không gian về OS, nhưng KHÓA
                               -- bảng (tránh dùng trong production / dùng hạn chế)
VACUUM ANALYZE users;          -- vacuum + cập nhật thống kê (cho query planner)
ANALYZE users;                 -- chỉ cập nhật thống kê (giúp planner chọn kế hoạch tốt)
```

```text
VACUUM      → đánh dấu không gian dead-tuple có thể tái sử dụng (không khóa độc quyền — bảo trì bình thường)
VACUUM FULL → thu hồi hoàn toàn không gian về OS nhưng ghi lại + KHÓA bảng (nặng)
ANALYZE     → cập nhật thống kê bảng để planner ra quyết định tốt
```

## Autovacuum — bảo trì tự động

```text
AUTOVACUUM chạy tự động trong nền, vacuum/analyze các bảng khi
đủ nhiều hàng đã thay đổi → xử lý bảo trì định kỳ mà không cần can thiệp thủ công.
→ Thường nên để BẬT. Tinh chỉnh cài đặt cho các bảng ghi nhiều cần vacuum
  thường xuyên hơn (nếu không nó sẽ tụt lại → bloat tích tụ).
```

## Triệu chứng của vấn đề vacuum

```text
✗ Bảng/index BLOAT (lớn hơn nhiều so với dữ liệu thực tế) → truy vấn chậm, lãng phí không gian
✗ Thống kê lỗi thời → planner chọn kế hoạch truy vấn tệ
✗ Nguy cơ transaction ID wraparound (nếu vacuum bị bỏ bê nghiêm trọng — một vấn đề nghiêm trọng)
→ Giám sát bằng pg_stat_user_tables (số lượng dead tuple, thời điểm vacuum gần nhất)
```

## Tại sao điều này quan trọng

Hiểu VACUUM là quan trọng để **vận hành PostgreSQL** đúng cách, vì nó là hệ quả trực tiếp của kiến trúc MVCC của Postgres và thiết yếu cho sức khỏe cơ sở dữ liệu — bỏ bê nó gây ra các vấn đề hiệu năng và vận hành thực sự, nghiêm trọng.

Mối liên hệ cơ bản là **MVCC tạo ra dead tuple** (các phiên bản hàng lỗi thời) ở mỗi lần UPDATE và DELETE, và chúng tích lũy thành **bloat** (lãng phí không gian, quét chậm hơn, hiệu năng giảm) trừ khi được dọn dẹp — VACUUM chính là việc dọn dẹp đó, thu hồi không gian dead-tuple và giữ bảng gọn gàng, truy vấn nhanh.

Hiểu các biến thể — `VACUUM` thông thường (thu hồi không gian để tái sử dụng, bảo trì bình thường, không khóa nặng), `VACUUM FULL` (thu hồi hoàn toàn không gian về OS nhưng ghi lại và khóa bảng, nên dùng hạn chế), và `ANALYZE` (cập nhật thống kê để query planner ra quyết định tốt) — là quan trọng cho công tác bảo trì.

Biết về **autovacuum** (tiến trình nền tự động xử lý vacuum định kỳ, thường để bật nhưng có thể cần *tinh chỉnh* cho các bảng ghi nhiều để nó không tụt lại) là kiến thức vận hành then chốt.

Nhận diện được **triệu chứng của vấn đề vacuum** (bloat bảng/index, thống kê lỗi thời gây kế hoạch truy vấn tệ, và nguy cơ nghiêm trọng của transaction ID wraparound nếu vacuum bị bỏ bê nghiêm trọng) cùng cách giám sát chúng là quan trọng để giữ cơ sở dữ liệu production khỏe mạnh.

Vì VACUUM là một nhu cầu vận hành đặc thù của Postgres (bắt nguồn trực tiếp từ MVCC), và vì bỏ bê nó gây bloat, truy vấn chậm, kế hoạch tệ, thậm chí cả vấn đề wraparound nghiêm trọng, nên hiểu VACUUM — tại sao cần nó (dead tuple của MVCC), các biến thể làm gì, autovacuum, và triệu chứng của vấn đề — là kiến thức cấp senior quan trọng để vận hành PostgreSQL một cách đáng tin cậy, một mối quan tâm bảo trì thường xuyên gặp, phân biệt những người có thể chạy Postgres trong production với những người gặp phải tình trạng suy giảm hiệu năng đáng lẽ tránh được.