Cơ sở dữ liệu 28/08/2026 11 phút

Hai giao dịch khoá hai dòng ngược thứ tự, cả hai đứng hình 2 giây — và một câu lệnh làm hàng đợi nhanh gấp 5,75 lần

Dựng lại deadlock có chủ đích trong PostgreSQL, đo thời gian phát hiện đúng bằng deadlock_timeout, và chỉ ra vì sao SKIP LOCKED làm hàng đợi công việc nhanh gấp 5,75 lần. Kèm cách chặn deadlock triệt để và cách tìm ai đang chặn ai.

Cơ sở dữ liệu 28/08/2026 11 phút

FOR UPDATE hứa 'mọi dòng tôi khoá đều khớp' — nhưng không hứa 'tôi khoá mọi dòng khớp', và cỡ lô đúng nhanh gấp 48 lần

Đo hàng đợi công việc trong PostgreSQL: FOR UPDATE đọc lại dòng sau khi chờ được khoá — và sự bất đối xứng của việc đọc lại đó là gốc của nhiều lỗi đua tranh. Kèm con số: cỡ lô 100 nhanh gấp 48 lần cỡ lô 1, chỉ mục một phần nhỏ hơn 375 lần, và một lời cảnh báo phổ biến tôi không dựng lại được.

Cơ sở dữ liệu 28/08/2026 10 phút

10 tiến trình cùng khởi động một cron, chỉ 1 chạy — nhưng hai cái bẫy khiến nó lặng lẽ ngừng hoạt động

Advisory lock là khoá không gắn với dòng nào: 10 bản sao ứng dụng cùng khởi động một công việc định kỳ, chỉ 1 chạy, không cần bảng phối hợp. Nó không rẻ hơn khoá hàng, và có hai cái bẫy — băm tên gây va chạm, và pool kết nối giữ khoá — mà cả hai đều hỏng trong im lặng.

Cơ sở dữ liệu 28/08/2026 11 phút

Bộ tối ưu có ba thuật toán nối đều đúng — và vẫn chọn sai 800 lần vì thống kê cũ

PostgreSQL có đúng ba cách nối hai bảng. Tôi ép chạy cả ba trên cùng truy vấn để xem chúng chênh nhau bao nhiêu, tìm ra một dải mà lựa chọn của bộ tối ưu không phải nhanh nhất, và một lần thiếu thống kê làm truy vấn chậm 800 lần mà không báo lỗi.

Cơ sở dữ liệu 28/08/2026 10 phút

Cùng một CTE: 226 ms trên PostgreSQL 11, 0,07 ms trên 16 — và bản 'sửa' đó lại làm vài mã cũ chậm đi

Nhiều năm liền, WITH của PostgreSQL là một hàng rào tối ưu không chuẩn SQL nào đòi hỏi: điều kiện lọc bên ngoài không được đẩy vào trong. PostgreSQL 12 đổi điều đó. Tôi dựng cả hai phiên bản với dữ liệu giống hệt để đo, và chỉ ra vì sao 'sửa' một hành vi tình cờ lại là một thay đổi phá vỡ.