Postgres: Tối ưu hóa truy vấn theo datetime

Question

Tôi có một bảng có trường datetime là "updated_at". Rất nhiều truy vấn của tôi sẽ được truy vấn trên trường này bằng cách sử dụng các truy vấn phạm vi như các hàng đã cập nhật_at> một ngày nhất định.

Tôi đã thêm chỉ mục vào updated_at, nhưng hầu hết các truy vấn của tôi vẫn còn rất chậm, ngay cả khi tôi có giới hạn về số hàng trả về.

Tôi có thể làm gì khác để tối ưu hóa các truy vấn truy vấn trên trường ngày giờ?

Answer 1

Thông thường, trình tối ưu hóa cơ sở dữ liệu sẽ không chọn sử dụng chỉ mục cho các phạm vi kết thúc mở, chẳng hạn như updated_at > somedate.

Nhưng trong nhiều trường hợp cột datatime sẽ không vượt quá "bây giờ", vì vậy bạn có thể giữ gìn ngữ nghĩa của > somedate bằng cách chuyển đổi các điều kiện để một loạt bằng cách sử dụng between như thế này:

where updated_at between somedate and current_timestamp 

Một vị từ between có nhiều khả năng khiến trình tối ưu hóa chọn sử dụng chỉ mục.

---

Vui lòng đăng cách tiếp cận này cải thiện hiệu suất của mỏ đá.

Answer 2

Giả sử rằng các chỉ số đang được sử dụng nhưng hiệu suất vẫn còn nghèo, biện pháp khắc phục duy nhất tôi có thể nghĩ đến là cụm bảng bằng chỉ số: http://www.postgresql.org/docs/9.1/static/sql-cluster.html

này sẽ di chuyển các hàng với giá trị update_at cùng là đồng vị trí vật lý, cải thiện hiệu suất truy vấn truy cập bảng đó thông qua chỉ mục, đặc biệt đối với các lần quét phạm vi rộng.

Chú ý đến các cảnh báo trong tài liệu mặc dù và lưu ý rằng khi các hàng được cập nhật thì việc phân cụm không được giữ nguyên.

Ngoài ra:

Khi một bảng đã được nhóm, một TRUY CẬP khóa ĐỘC QUYỀN được mua lại trên đó. Điều này ngăn cản bất kỳ hoạt động cơ sở dữ liệu khác (cả đọc và viết) từ hoạt động trên bảng cho đến khi CLUSTER kết thúc.

Dựa trên những hạn chế này, nó có thể không phải là giải pháp khả thi cho trường hợp của bạn, nhưng có thể hữu ích cho người khác.

Answer 3

Đối với bất kỳ truy vấn cụ thể, việc sử dụng một chỉ số phụ thuộc vào chi phí của việc sử dụng chỉ số so sánh với một quét tuần tự

thường các nhà phát triển nghĩ rằng vì có một chỉ số, một truy vấn nên chạy nhanh hơn, và nếu truy vấn chạy chậm, chỉ mục là giải pháp. Điều này thường xảy ra khi truy vấn sẽ trả về một vài bộ dữ liệu. Nhưng khi số lượng bộ dữ liệu trong kết quả tăng lên, chi phí sử dụng chỉ mục có thể tăng lên.

Bạn đang sử dụng postgres. Postgres không hỗ trợ phân cụm quanh một thuộc tính đã cho. Điều đó có nghĩa là postgres, khi đối mặt với một truy vấn phạm vi (thuộc loại att> a và att < b) cần tính toán số lượng bộ dữ liệu trong kết quả (đảm bảo bạn hút cơ sở dữ liệu thường xuyên) và chi phí sử dụng chỉ số so với quét tuần tự. sau đó nó sẽ quyết định sử dụng phương pháp nào.

bạn có thể kiểm tra quyết định này bằng cách chạy

EXPLAIN ANALYZE <query>; 

trong psql. Nó sẽ cho bạn biết nếu nó sử dụng một chỉ mục hay không. Nếu bạn thực sự, thực sự muốn sử dụng các chỉ mục thay vì quét tuần tự (đôi khi cần) và bạn thực sự biết bạn đang làm gì, bạn có thể thay đổi chi phí quét tuần tự trong hằng số kế hoạch hoặc vô hiệu hóa quét tuần tự có lợi cho bất kỳ phương pháp nào khác. Xem trang này để các chi tiết:

http://www.postgresql.org/docs/9.1/static/runtime-config-query.html

Hãy chắc chắn rằng bạn duyệt phiên bản đúng của tài liệu.

--dmg