Migration an toàn khi AI sinh schema

By Better Wise

Bài trước bạn đã biết bọc nhiều thao tác ghi vào một transaction để không có trạng thái nửa vời. Migration cũng là ghi, nhưng là ghi vào cấu trúc bảng. Trên bảng vài chục triệu dòng, một câu ALTER TABLE do AI sinh ra có thể khóa bảng vài phút, làm app đứng hình, hoặc tệ hơn là làm mất dữ liệu mà không ai báo lỗi. Bài này dạy bạn mở file migration ra, đọc chậm từng dòng, rồi sắp lại thứ tự thay đổi.

Sau bài này, bạn sẽ:

• Rà được một file migration do AI tạo và chỉ ra dòng nào nguy hiểm.
• Biết thao tác nào khóa bảng, thao tác nào rewrite cả bảng.
• Sắp thứ tự thay đổi theo mẫu expand rồi contract để app cũ vẫn chạy trong lúc deploy.
• Biết cách backfill dữ liệu theo lô thay vì một câu UPDATE toàn bảng.

Mở file migration ra và đọc theo từng dòng

AI viết migration rất tự tin, câu nào cũng đúng cú pháp SQL. Vấn đề không phải cú pháp, mà là thời gian khóa và dữ liệu đang có. Bạn đọc theo ba câu hỏi, theo đúng thứ tự này:

1. Câu lệnh này có khóa bảng không, và khóa bao lâu?
2. Nó có làm mất dữ liệu hay làm mất khả năng đọc của app phiên bản cũ không?
3. Nếu sai, lùi lại bằng cách nào?

Ví dụ một migration AI sinh cho bạn, nghe rất hợp lý:

-- migration AI sinh: thêm trạng thái đơn hàng và đổi tên cột
ALTER TABLE orders ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'pending';
UPDATE orders SET status = 'pending' WHERE status IS NULL;
CREATE INDEX idx_orders_status ON orders(status);
ALTER TABLE orders RENAME COLUMN customer_id TO buyer_id;

Đọc chậm lại:

• ADD COLUMN ... NOT NULL DEFAULT có thể rewrite toàn bộ bảng. PostgreSQL 11+ thì nhẹ hơn, nhưng MySQL hoặc bản cũ vẫn copy bảng.
• UPDATE orders không có WHERE theo khóa chính là một câu ghi vào mọi dòng, giữ khóa lâu và làm phình WAL.
• CREATE INDEX thường chặn ghi trên bảng trong suốt thời gian build.
• RENAME COLUMN làm app phiên bản cũ đang chạy (vẫn ghi customer_id) chết ngay giữa lúc deploy.

This lesson is premium content. Sign in and purchase the course to view the full content. Sign in