Snowflake Optima Planning: cross-query performance

Snowflake · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bài của nhà cung cấp về một tính năng; mọi nhận định và số liệu là theo Snowflake. Không có chi tiết về cách chống "khái quát quá đà" ngoài việc nói là có.

Bối cảnh

• Optimizer của Snowflake dựa trên chi phí: ước lượng số dòng của từng operator rồi chọn plan rẻ nhất. Ước lượng sai thì chọn sai thứ tự join hay sai bên build, có khi sinh hàng tỉ dòng trung gian không cần. Tương quan giữa nhiều bảng (ví dụ nhà hàng hạng cao dùng nguyên liệu cao cấp, nguyên liệu đó đến từ nhà cung cấp thủ công) thì thống kê theo từng bảng không bắt được.
• Optima Planning đã học từ chính truy vấn đó chạy lần trước: query (hoặc biến thể của nó) đã chạy chưa, thì dùng số dòng thật để lập plan cho lần sau. Truy vấn mới hoàn toàn thì vẫn lập plan "lạnh".

Thay đổi chính

• Học xuyên truy vấn: sau khi compile, tính hash cho từng plan fragment và từng operator (ví dụ một join cụ thể) trên kết quả của optimizer, không trên chữ SQL. Truy vấn khác về sau chứa fragment/operator cùng hash thì dùng feedback thực thi của truy vấn trước cho phần đó, kể cả khi phần còn lại hoàn toàn mới.
• Khớp chỉ là ứng viên: hệ theo dõi xem đem bằng chứng từ ngữ cảnh này sang ngữ cảnh kia có khái quát quá đà không; nếu có thì không áp.
• Hai cơ chế nối nhau: khớp theo fragment giúp lần chạy đầu của một truy vấn mới; từ lần thứ hai, truy vấn có danh tính riêng và feedback theo truy vấn tiếp quản.
• Ca có ích: view phổ biến được thêm một join mới; một join hay dùng xuất hiện trong báo cáo mới; hai công cụ BI viết cùng một join theo thứ tự bảng khác nhau (hiện vẫn bị coi là hai truy vấn khác); SQL do BI hay LLM sinh ra.

Kết quả (theo Snowflake)

• Ví dụ tổng hợp: truy vấn mới chưa từng chạy từ khoảng 13 giây xuống khoảng 0,5 giây (khoảng 26 lần) nhờ ước lượng số dòng mượn từ truy vấn tương tự.
• Production (một công ty công nghệ y tế lớn ở Mỹ): truy vấn 19 join có predicate tương quan từ gần hai giờ xuống 30 giây.
• Khách thấy qua Query Profile và view QUERY_INSIGHTS, nhưng chưa phân biệt được khớp theo fragment với khớp theo truy vấn.

Vì sao

• Thống kê tĩnh không thấy tương quan giữa bảng; số dòng thật đo được lúc chạy thì thấy. Khoá theo cấu trúc plan thay vì theo chữ SQL làm cho bằng chứng dùng lại được giữa các truy vấn khác nhau (Query planner và hiệu năng truy vấn).

Bài học cho SWE

• Khi planner sai vì tương quan, nguồn sửa tốt nhất là số liệu thực thi, không phải thêm thống kê theo bảng.
• Khoá cache/feedback theo dạng chuẩn hoá của plan bền hơn theo văn bản truy vấn.
• Cơ chế dùng lại bằng chứng cần cửa chặn khi ngữ cảnh khác (khái quát quá đà).

Liên quan

• Snowflake 2026 · GoCardless 2019 (planner sai do thống kê) · Render 2024 (thống kê mở rộng cho cột tương quan)
• Query planner và hiệu năng truy vấn