Bảng vừa nạp 1 triệu hàng chưa ANALYZE: planner ước lượng WHERE v<10 là 333350 hàng, thực tế 10000 — lệch 33 lần. Tôi suýt trách planner ngu. Chạy ANALYZE, ước lượng về 9872, khớp. Thống kê bảng là nguồn của mọi ước lượng, và một planner mù thống kê buộc phải đoán bằng hằng số mặc định.
Đo dung lượng bằng bảng một cột: int, bigint, numeric, text đều ra 35 MB y hệt — tôi suýt kết luận kiểu chẳng ảnh hưởng. Header hàng 23 byte đã trùm mất khác biệt. Cho cột thành phần lớn của hàng thì bigint 89MB so int 57MB, numeric chậm 2,7 lần, và text so số sai ('10' < '9'). Chọn kiểu là chuyện dung lượng, tốc độ, và tính đúng.
Đo một khoảng thời gian bằng đồng hồ treo tường rồi bị NTP giật lùi 10 giây giữa chừng: kết quả ra -10 giây, một khoảng ÂM không thể tồn tại. Monotonic thì cho +3 micro giây đúng đắn, không bao giờ nhảy. Chọn nhầm đồng hồ là bug timing kín đáo nhất. Đo thật.
Đọc cùng một hàng hai lần trong một giao dịch: ở mặc định READ COMMITTED được 100 rồi 200; REPEATABLE READ giữ 100; SERIALIZABLE có thể hủy giao dịch bắt bạn retry. Tôi tưởng 'đọc lại thì y nguyên chứ' — hóa ra mặc định KHÔNG phải mức chặt nhất, và mức cô lập là biến ẩn quyết định bạn thấy gì.
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.
Chuyển 500 mà lỗi giữa hai UPDATE: không giao dịch làm tổng tụt từ 2000 còn 1500 (mất 500 trong không khí); bọc BEGIN...COMMIT thì ROLLBACK giữ nguyên 2000. Mặc định là autocommit — mỗi lệnh tự commit, nên hai lệnh liên tiếp KHÔNG tự thành một đơn vị. Tính nguyên tử đo bằng một bất biến: tổng tiền.