10 bài viết được gắn thẻ "Backend"

Index là một cấu trúc sắp xếp theo giá trị của cột. Khi bạn bọc một hàm quanh cột — date_part('year', tao_luc), LOWER(email), CAST(...) — thì thứ bạn đang so sánh không còn là giá trị đã được sắp xếp nữa, nên database không dùng index được và phải quét toàn bảng. Điều kiện dùng được index gọi là sargable. Đo trên PostgreSQL 16 với 200.000 dòng: bản bọc hàm chạy 29,6 ms với Seq Scan, bản viết lại thành khoảng chạy 5,4 ms với Bitmap Index Scan — nhanh hơn ~5,4 lần và trả về cùng 37.518 dòng.

LEFT JOIN giữ lại mọi dòng của bảng bên trái và điền NULL cho phần không khớp. Nhưng WHERE chạy sau phép join, nên bất kỳ điều kiện nào đặt lên cột của bảng bên phải sẽ loại luôn những dòng NULL ấy — và LEFT JOIN biến thành INNER JOIN mà không có cảnh báo nào. Chạy thật trên PostgreSQL 16: LEFT JOIN thuần cho 4 dòng, thêm WHERE còn 2 dòng, nhưng đưa đúng điều kiện đó vào ON thì được 3 dòng — mới là con số đúng.

NULL trong SQL không phải một giá trị mà là ký hiệu cho "không biết". Mọi phép so sánh với nó đều cho ra UNKNOWN, và WHERE chỉ giữ lại dòng nào cho ra TRUE — nên UNKNOWN bị loại y như FALSE. Hệ quả nghiêm trọng nhất nằm ở NOT IN: chỉ cần subquery chứa một NULL là toàn bộ câu truy vấn trả về 0 dòng, kể cả khi dữ liệu rõ ràng có. Tôi chạy thử trên PostgreSQL 16: cùng một ý định, NOT IN cho 0 dòng còn NOT EXISTS cho 3 dòng. Câu lệnh không báo lỗi, không cảnh báo, chỉ lặng lẽ trả về sai.

Vòng lặp copy mọi header từ request đi vào sang request đi ra là một anti-pattern, và nó hỏng theo ba hướng khác nhau: sai về tính đúng đắn (một giá trị non-ASCII làm HttpClient ném exception), sai về bảo mật (bạn tin và chuyển tiếp dữ liệu do client tự đặt), và sai về kiến trúc (header do hạ tầng chèn trở thành một phần hợp đồng của ứng dụng). Cách sửa là allowlist — khai tường minh danh sách header được phép đi qua — đặt trong một DelegatingHandler dùng chung. Khi viết handler đó, cẩn thận một cái bẫy: nó không sống trong scope của request.

DbContext của EF Core đã là một Unit of Work sẵn: nó gom thay đổi trong change tracker rồi đẩy xuống database trong một transaction khi gọi SaveChanges. Vì vậy tự viết thêm một IUnitOfWork chỉ để gọi SaveChanges thường là thừa. ABP thì khác hẳn: Unit of Work ở đây là ambient, tự mở theo mỗi request, và SaveChangesAsync bên trong một UoW không commit transaction — chỉ CompleteAsync mới commit. Hiểu sai chỗ này là nguồn gốc của phần lớn bug "dữ liệu lúc có lúc không".