Chạy thử là root, mở file cấm-mọi-quyền vẫn thành công — root bỏ qua mọi bit, kiểm bảo mật khi là root là kiểm không gì cả. Hạ xuống user thường mới ra EACCES. Và nhân kiểm quyền MỘT LẦN lúc open: chmod 000 không thu hồi được fd đang mở, chỉ chặn open mới.
Trên hai cột trùng nhau, planner đoán 99 hàng còn thực tế 10000 — lệch 100 lần. 'rows' của EXPLAIN là ước lượng (không chạy), 'actual rows' của EXPLAIN ANALYZE mới là đo thật (có chạy). Chính khoảng cách giữa hai con số tố cáo planner đang đoán mù — và EXPLAIN ANALYZE chạy thật cả UPDATE/DELETE.
Ép malloc về một arena chỉ làm 8 luồng chậm từ 556 xuống 434 triệu op/s — tưởng arena vô dụng. Nhưng có một biến ẩn đang gánh thay nó: tắt luôn tcache thì thông lượng sập còn 23. Hai lớp chống tranh khóa, mỗi lớp che hiệu ứng của lớp kia. Đo thật.
Lần đọc đầu là shared read (nạp trang), lần sau thành shared hit (từ RAM). Nhưng một seq scan bảng lớn KHÔNG vào cache dù bảng nhỏ hơn shared_buffers — vì ring buffer cố ý bảo vệ cache khỏi bị một lần quét lớn xóa sạch. Tôi tưởng 'chạy lại luôn nhanh hơn', hóa ra đó không phải luật tự nhiên.
Tưởng CPU luôn chạy theo thứ tự mình viết, còn reorder bộ nhớ chỉ là lý thuyết trong sách? Tôi đo litmus store-buffer trên ARM: reorder xảy ra thật (11 ca trong 60 triệu vòng), rào dmb ish dập được về 0. Nhưng nó hiếm tới ~1 trên 5,5 triệu vòng — nên code sai vẫn qua sạch mọi test rồi nổ ở production.
Cùng một đoạn code, cùng những con số, chỉ khác mảng được sắp trước hay chưa: bản chưa sắp chạy 660 ms, bản đã sắp 379 ms — chênh 1,7 lần. Không phải ít phép tính hơn, không phải cache. Thủ phạm là dự đoán nhánh của CPU, thứ big-O không hề thấy. Viết không nhánh xóa hẳn (183 ms). Tôi đo.