Bài học theo mô-đun (3/4)
Chỉ số tổng hợp và một phần
Trong các bài học trước chúng ta đã đề cập đến việc sử dụng chỉ mục cho các truy vấn DBMS tuyến tính (WHERE country = 'Italy'). Thế còn khi chúng ta tìm kiếm trên hai mặt trận kết hợp thì sao?
Ví dụ: trong thương mại điện tử thực, chúng ta có thể muốn tìm các đơn hàng thuộc một ID khách hàng cụ thể VÀ nằm trong một khoảng thời gian nhất định:
WHERE customer_id = 90 AND placed_at >= '2025-01-01'.
Nếu bạn chỉ có chỉ mục cơ sở trên customer_id, Postgres sẽ nhanh chóng tìm thấy 50 đơn hàng của khách hàng bằng cách sử dụng cây nhị phân, nhưng sau đó nó phải lặp qua tất cả 50 đơn hàng đó theo cách thủ công và tuần tự, lọc ngày một cách lười biếng bằng mắt.
Chỉ số tổng hợp
Chúng ta có thể yêu cầu DBMS sắp xếp các tệp "từ điển phân tích" không theo một chiều khóa duy nhất mà theo nhiều chiều.
CREATE INDEX idx_orders_customer_date ON orders(customer_id, placed_at);Chỉ mục "tổng hợp" coi thứ tự của các tham số của nó là rất quan trọng: ở đây các nút B-Tree nhóm lại và phân loại cứng nhắc customer_id trong một khối (khối phân biệt đối xử nhất để phân tách); bên trong chúng có cây con phân nhánh với các giá trị thời gian placed_at khác nhau theo thứ tự được sắp xếp hoàn hảo.
Cấu trúc này hủy bỏ một cách tàn nhẫn các mệnh đề WHERE với nhiều vị từ lồng nhau.
Chỉ mục một phần (Chỉ mục được lọc)
Mọi chỉ mục đều tiêu tốn dung lượng ổ đĩa và CPU trên luồng đầu vào của người dùng. Điều gì sẽ xảy ra nếu thương mại điện tử yêu cầu liên tục sắp xếp và truy xuất bộ lọc nhưng chỉ đối với một số ít bản ghi? (Ví dụ: bỏ phiếu nhanh chóng để kiểm tra thông báo chưa đọc.) Việc tạo chỉ mục "is_read" trên tất cả 10.000.000 thông báo là vô cùng tẻ nhạt nếu "Chưa đọc" chỉ đại diện cho 5 thông báo trong số đó.
CREATE INDEX idx_unread_notifs ON notifications(user_id)
WHERE is_read = false; -- Questa aggiuntiva è l'"Indice Parziale"Cơ sở dữ liệu sẽ xây dựng một Cây B nhanh như chớp để lưu trữ các khóa truy cập nhanh vào DB CHỈ nếu bản ghi Chưa đọc! Đĩa sẽ có chỉ mục gồm 5 hàng (3 byte) thay vì một hàng có 10 triệu. CHỌN nhanh được hưởng lợi đầy đủ:
SELECT * FROM notifications WHERE user_id = 2 AND is_read = false;
Đến lượt bạn
Chúng tôi muốn tối ưu hóa việc tra cứu mật khẩu tạm thời/mã thông báo đặt lại. Chúng tôi rất thường xuyên thực hiện lệnh gọi SELECT để tìm kiếm tất cả khách hàng đã đăng ký từ một quốc gia cụ thể kết hợp với một thành phố đã biết.\nTạo chỉ mục tổng hợp có tên 'idx_cust_loc' trên 'khách hàng'. Vượt qua trường 'quốc gia' trước (độc quyền hơn) và sau đó là trường 'thành phố'.
Hiển thị gợi ý
Cú pháp: TẠO tên INDEX TRÊN bảng(col1, col2);
Giải pháp khả dụng sau 3 lần thử
Khám phá các chỉ mục có điều kiện (Một phần)
Tối ưu hóa việc tra cứu người dùng mua sắm: người dùng đăng ký trước nhưng chúng tôi chỉ cần liệt kê họ theo thứ tự đăng ký theo trình tự thời gian của họ (tạo chỉ mục trên 'signed_up_on' trong 'khách hàng') nhưng CHỈ GIỚI HẠN đối với khách hàng từ 'thành phố' đầy đủ chuỗi chính xác: 'Milano'.
Hiển thị gợi ý
Nó được khai báo bình thường trên thuộc tính mục tiêu; ở cuối, bạn thêm từ khóa ma thuật WHERE city = 'Milano'.
Giải pháp khả dụng sau 3 lần thử