Bạn nên đơn giản hóa truy vấn của mình. Điều đó sẽ làm giảm thời gian thực hiện. Tôi không thể kiểm tra truy vấn của bạn nhưng đây là một vài gợi ý:
- không sắp xếp trong khi thực hiện đếm ()
- bạn có thể sắp xếp theo orderBy ('p.id', 'DESC') , chỉ mục sẽ được sử dụng
- thay vì leftJoin () bạn có thể sử dụng join () nếu ít nhất một bản ghi luôn tồn tại trong bảng đã tham gia. Nếu không, bản ghi đó bị bỏ qua.
- KNP / Paginator sử dụng DISTINCT () để chỉ đọc các bản ghi riêng biệt, nhưng điều đó có thể dẫn đến việc sử dụng bảng tmp đĩa
- $ query-> getArrayResult () sử dụng chế độ ẩn mảng, trả về mảng nhiều thứ nguyên và nhanh hơn chế độ ẩn đối tượng cho tập kết quả lớn
- bạn có thể sử dụng một phần select ('một phần p. {id, các trường được sử dụng khác}') , theo cách này, bạn sẽ chỉ tải các trường cần thiết, có thể bỏ qua các quan hệ chưa được chỉnh sửa khi sử dụng tính năng hydrat hóa đối tượng
- kiểm tra trình mô tả SF GIẢI THÍCH về một truy vấn nhất định trong phần học thuyết, có thể các chỉ mục không được sử dụng
- p.hashtags và p.likes chỉ trả về một hàng hay là oneToMany, điều này sẽ nhân kết quả
- có thể một số thay đổi về thiết kế Bài đăng, điều này sẽ loại bỏ một số liên kết:
- có trường p.hashtags được xác định là @ORM \ Column (type ="array") và có các giá trị chuỗi được lưu trữ của các thẻ. Sau đó, có thể sử dụng tìm kiếm toàn văn trên mảng được tuần tự hóa.
- có trường p.likesCount được xác định là @ORM \ Column (type ="integer") sẽ có số lượt thích
Tôi sử dụng KnpLabs / KnpPaginatorBundle và cũng có thể gặp vấn đề về tốc độ đối với các truy vấn phức tạp.
Thường sử dụng LIMIT x, z là chậm đối với DB, vì nó chạy COUNT trên toàn bộ tập dữ liệu. Nếu các chỉ mục không được sử dụng, nó sẽ rất chậm.
Bạn có thể sử dụng cách tiếp cận khác và thực hiện một số phân trang tùy chỉnh theo tiến trình ID, nhưng điều đó sẽ làm phức tạp cách tiếp cận của bạn. Tôi đã sử dụng điều này với các tập dữ liệu lớn như bảng SYSLOG. Nhưng bạn không có chức năng sắp xếp và tổng số bản ghi.
