Code không đổi, nhưng nếu DB đổi cách xử lý cùng một query (kế hoạch thực thi), query hôm qua mất 2 ms thì hôm nay mất vài trăm ms.
Vì sao Thống kê tự động cập nhật, DB khởi động lại hoặc phân bố dữ liệu thay đổi khiến DB lập lại kế hoạch thực thi → Dẫn đến Kế hoạch không dùng index được chọn, cùng một query chậm đi vài chục đến vài trăm lần, kết nối DB bị giữ → Trên màn hình Không hề có triển khai mà một tính năng đột nhiên tải chậm, các yêu cầu khác cũng phải chờ
Phụ trách chính Hạ tầng DB (Đội hạ tầng) · Phối hợp Phát triển server (Đội phát triển game)
Việc cần làm (Đội phát triển game)
Với query có số kết quả chênh lệch lớn tùy giá trị, tách ra dùng riêng hoặc cân nhắc hint cho kế hoạch, thiết kế query chắc chắn dùng index.
Việc cần làm (Đội hạ tầng)
Theo dõi query chậm và lịch sử kế hoạch thực thi, cố định kế hoạch tốt (Query Store của SQL Server, v.v.), quản lý thời điểm cập nhật thống kê.
Trên đồ thị
Tăng như bậc thang từ một thời điểm · Thời gian chạy trung bình theo từng query
Chỗ cần xem
Định kỳ thu thập thời gian trung bình của các query cùng dạng để xem xu hướng. MySQL: AVG_TIMER_WAIT trong events_statements_summary_by_digest; PostgreSQL: mean_exec_time trong pg_stat_statements (12 trở xuống là mean_time). So sánh kế hoạch thực thi trước và sau khi chậm bằng EXPLAIN hoặc auto_explain của PostgreSQL; SQL Server dùng màn hình Regressed Queries (query bị suy giảm hiệu năng) trong Query Store
Đúng nếu
vào lúc không có triển khai, thời gian trung bình của một query tăng mấy chục lần theo dạng bậc thang, thời điểm đó trùng với lúc cập nhật thống kê hoặc DB khởi động lại, và kế hoạch thực thi đã thay đổi
Loại trừ nếu
kế hoạch thực thi vẫn vậy mà chậm đi → dữ liệu tăng, chờ khóa (db-hot-row) hoặc ổ đĩa
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm
SQL Server dùng lại kế hoạch đã lập theo giá trị được truyền vào lần đầu (parameter sniffing). Nếu kế hoạch lập cho một nhân vật mới chỉ có vài vật phẩm lại được dùng cho nhân vật lâu năm có hàng chục nghìn vật phẩm thì chậm đi rất nhiều, và trường hợp ngược lại cũng thường gặp. Khởi động lại xóa kế hoạch nên có khi hệ thống trở lại bình thường rồi lại tệ đi.
Nguồn
Query Processing Architecture GuideMicrosoft SQL Server Parameter sniffing: lập kế hoạch thực thi theo giá trị tham số được truyền vào lúc biên dịch hoặc biên dịch lại
Parameter Sensitive Plan OptimizationMicrosoft SQL Server Khi phân bố dữ liệu không đều, một kế hoạch đã cache không phù hợp với mọi giá trị tham số
Monitor performance by using the Query StoreMicrosoft SQL Server Kế hoạch thay đổi do thống kê, schema, index thay đổi, còn plan cache chỉ giữ kế hoạch mới nhất; cố định kế hoạch tốt bằng plan forcing của Query Store; so sánh query bị chậm đi và kế hoạch của nó bằng màn hình Regressed Queries
Statement Summary TablesMySQL events_statements_summary_by_digest: COUNT_STAR và AVG_TIMER_WAIT (thời gian trung bình) theo từng dạng query