Backend

Biểu đồ log-log: đường ngoại suy chấm chấm kết thúc gần 10 ms, hai đường đo thật không index bỏ xa nó (MariaDB 10.11 ở 968 ms và 13.0 ở 148 ms tại 1M dòng), vạch gạch 300 ms, và một đường phẳng dưới 1 ms cho trường hợp có index

Tôi viết ngưỡng thêm index thành con số, rồi tự đo lại và thấy nó lệch 15 đến 100 lần

Bạn đã từng ký duyệt một tài liệu thiết kế. Trong đó thế nào cũng có một câu kiểu “khi vượt X thì làm Y”. Có ai từng sinh thử đúng X dòng để xem con số đó có đúng như nó nói không? Cuối tháng trước, tôi duyệt một thiết kế cho phép tra cứu trên một cột không có index. Bảng chứa cột đó không thuộc team tôi. Tôi viết điều kiện để sửa lại thành một câu có hai con số: “khi bảng vượt khoảng 1.000.000 dòng, hoặc p95 của truy vấn lọc theo voucher vượt 300 ms, thì gửi yêu cầu thêm index non-unique cho team sở hữu.” Câu đó có đúng một nhiệm vụ: đưa phương án “ship mà không thêm index” qua vòng review thiết kế. Nó biến lời hứa “sẽ thêm sau” thành một điều kiện mà người review có thể ký. Và nó đã hoàn thành nhiệm vụ đó. ...

Thanh 200 đơn vị chia thành 110 đã phân bổ và 90 kho tổng, 10 đơn vị đã bán từ quota tô đỏ bên trong khối 110, và hai phép trừ bên dưới: đọc nghĩa đen ra 80, màn hình production ra 90

Công thức trong ticket trừ hai lần, và chỉ hai ảnh chụp cùng một phút mới bác được nó

Một mã hàng. Tổng nhập kho 200 đơn vị. Ba chương trình khuyến mãi được cấp quota lần lượt 10, 88 và 12, và đã bán ra từ quota đó 1, 9 và 0. Còn bao nhiêu đơn vị khả dụng để bán? Ticket viết: tồn khả dụng = tổng nhập − tổng đã phân bổ − tổng đã bán. Thay số vào thì ra 200 − 110 − 10 = 80. Màn hình production của đúng mã hàng đó, cùng thời điểm, hiện 90. ...

Hai bảng có id auto-increment trùng nhau, file import trỏ vào bảng này còn code đọc bảng kia

Import sửa nhầm dòng suốt nhiều năm vì hai bảng có id trùng nhau

Tính năng import điều chỉnh quota chương trình khuyến mãi từ file bảng tính đã chạy trên production nhiều năm. Lần kiểm thử thủ công nào cũng giống nhau: tải một file lên, mở chương trình ra, thấy một quota đã đổi, đóng ticket. Handler này không có một test tự động nào. Nó đang sửa nhầm dòng. Không phải thỉnh thoảng, mà về cấu trúc: lần chạy nào mà hai id trùng nhau thì lần đó sửa sai, và trên staging thì chúng trùng thật. Trong những năm đó nó đã đụng vào bao nhiêu dòng trên production, tôi chưa đo và sẽ không đoán ở đây. Thứ tôi chỉ ra được là cơ chế, vì sao ba lớp bảo vệ khác nhau đều để nó đi qua, và một test duy nhất mà nếu có từ ngày đầu thì đã bắt được. ...

Một dòng mồ côi vẫn bị tính vào kho dùng chung, mà không có màn hình nào giải phóng được

Quota ma: thiếu một foreign key âm thầm hạ trần bán

Bảng campaign_product_variants không có foreign key (khóa ngoại), không ON DELETE CASCADE, cũng không có deleted_at. Trước khi có kho dùng chung, đó chỉ là vấn đề thẩm mỹ: vài dòng trỏ tới một SKU đã không còn tồn tại làm báo cáo hiện ra con số nhỏ hơn thực tế một chút. Tôi không thấy ai coi đó là bug, và tôi cũng không lật lại ticket cũ để kiểm cho chắc. ...

UUIDv7 Structure and B-Tree Performance Analysis

UUIDv7: Phân tích Kiến trúc Định danh và Hiệu suất Index trong Hệ thống Hiện đại

Trong quá trình thiết kế hệ thống có quy mô lớn (Scale-up), việc lựa chọn Khóa chính (Primary Key) thường là một trong những quyết định kỹ thuật quan trọng nhất nhưng lại ít được thảo luận chuyên sâu. Một lựa chọn sai lầm ở bước này có thể dẫn đến rủi ro bảo mật (Insecure Direct Object Reference) hoặc suy giảm hiệu suất ghi nghiêm trọng khi dữ liệu đạt ngưỡng hàng triệu bản ghi. ...