クエリを単純化する必要があります。これにより、実行時間が短縮されます。クエリをテストすることはできませんが、ここにいくつかのポインタがあります：
- count（）の実行中は並べ替えを行わないでください
- orderBy（'p.id'、'DESC'）で並べ替えることができます 、インデックスが使用されます
- leftJoin（）の代わりに join（）を使用できます 結合されたテーブルに少なくとも1つのレコードが常に存在する場合。それ以外の場合、そのレコードはスキップされます。
- KNP / PaginatorはDISTINCT（）を使用して個別のレコードのみを読み取りますが、ディスクtmpテーブルを使用する可能性があります
- $ query-> getArrayResult（）は配列隠蔽モードを使用します。このモードは多次元配列を返し、大きな結果セットのオブジェクト隠蔽よりもはるかに高速です
- 部分的なselect（'部分的なp。{id、その他の使用済みフィールド}'）を使用できます 、この方法では、必要なフィールドのみをロードし、オブジェクトのハイドレーションを使用する場合は、不要な関係をスキップする可能性があります
- ドクトリンセクションの下の特定のクエリでSFプロファイラーEXPLAINを確認します。インデックスが使用されていない可能性があります
- p.hashtagsとp.likesは1行のみを返すか、oneToManyであり、結果を乗算しますか
- おそらくいくつかの投稿のデザインが変更され、いくつかの結合が削除されます：
- p.hashtagsフィールドを@ORM\ Column（type ="array"）として定義します タグの文字列値を保存しています。後で、シリアル化された配列で全文検索を使用する可能性があります。
- p.likesCountフィールドを@ORM\ Column（type ="integer"）として定義します いいねの数があります
KnpLabs /KnpPaginatorBundle を使用しています また、複雑なクエリでは速度の問題が発生する可能性があります。
通常、LIMIT x、zの使用は、データセット全体でCOUNTを実行するため、DBでは低速です。インデックスを使用しないと、非常に遅くなります。
別のアプローチを使用して、IDの進行によってカスタムのページ付けを行うこともできますが、それではアプローチが複雑になります。私はこれをSYSLOGテーブルのような大きなデータセットで使用しました。ただし、並べ替えと合計レコード数の機能は失われます。