<p>かなり複雑なデータセットを取得する symfony リポジトリ メソッドがあり、エクスポート マネージャー クラスによって CSV ファイルに配置されます。エクスポート ジョブを処理するコード全体を記載するつもりはありませんが、クエリが遅くなるポイントを正確に特定することができたので、私の質問はコード自体ではなく、クエリを高速化するための他の代替手段についてです。 したがって、取得されるデータは、複数の「メンバーシップ」と「ユーザー」を含む「サイト」データです。したがって、問題は、クエリがユーザー情報をサイトに接続しようとすると、実行が遅くなるということです。次のようになります:</p> <pre class="brush:php;toolbar:false;">$qb->leftJoin('s.memberships', 'ex_sm', 'WITH', 'ex_sm.revokedAt IS NULL'); $qb->leftJoin('ex_sm.user', 'ex_jappr', 'WITH', 'ex_sm.approverJobReactiveWeight IS NOT NULL');</pre> <p>いくつか言及すべきこと (私が試したこと、または役に立つかもしれないと思ったこと): </p>

<li>テーブルを確認したところ、リンクされているすべての列にはインデックスがあり、それらはすべて同じ int データ型です。 </li> <li>DQL のパフォーマンスの問題に関する記事を書きました。その記事では、DQL Left Join 呼び出しを使いすぎると、同じエンティティ オブジェクトが何度も再マップされるため、パフォーマンスが低下する可能性があると述べられていました。考えられる解決策の 1 つは、メイン データセットを取得し、フィールドのエンティティ クラスから直接各要素に追加 (接続されたデータ フィールド) を追加してコレクションをループすることです。これは機能するかもしれません (どの程度の影響があるかはわかりません)。問題は、私が持っているのは非常に複雑な従来のコードであり、あまりにも多くのテストが必要になるため、エクスポートマネージャーのロジックには触れたくないことです。エクスポート マネージャーにはクエリ ビルダー クラスが必要なので、クエリ自体で解決策を見つける必要があります。 </li> <li>この問題は、WITH 句や追加の条件ではなく、明らかに結合によって発生します。通常の leftJoin 呼び出しを使用してクエリを呼び出してみましたが、同じ結果が得られました。 </li> <li>leftJoin メソッドの呼び出しは相互に連鎖できることはわかっています。呼び出しの一部が if ステートメントで使用されているため、コードは次のようになります。 </li> <li>私は 2 日間かけて、ここや他のサイトで見つけたものすべてを試しました。 </li> </ul> <p>6 つの異なるユーザー タイプがあります。ここでは、スクリプトを呼び出して上記のユーザー タイプを取得するだけで、データを返すのに 33 分かかりました。これは 512 のサイトについて話していますが、これは膨大なデータのコレクションではありません。そこで私の質問は次のとおりです。このような複雑なクエリでの leftJoins の呼び出し数を簡素化または削減し、何らかの方法でパフォーマンスを向上させる別の DQL または Doctrine の方法はありますか? </p> <p>更新: 問題はインデックスにあると考えたので、その関係についていくつか詳しく説明しました。 「memberships」エンティティは「access」という名前のテーブルから取得され、そのモデル内のユーザーとの関係は次のとおりです。 <pre class="brush:php;toolbar:false;">/*** このメンバーシップがカプセル化するユーザー。 * * @ORM\ManyToOne(targetEntity="User", inversedBy="siteMemberships", cascade={"persist"}) * @ORM\JoinColumn(name="security_identity_id"、referencedColumnName="id") * * @var ユーザー*/ protected $user;</pre> <p>これは、「security_identity_id」列に割り当てられたインデックスのスクリーンショットです。 </p> <p>関連ユーザーは、メンバーシップを指す関係を持つ Users テーブルから取得されます</p> <pre class="brush:php;toolbar:false;">/*** @ORM\OneToMany(targetEntity="SiteMembership"、mappedBy="user"、cascade={"persist"}、fetch="EXTRA_LAZY")*/ protected $siteMemberships;</pre> <p>主キーはエンティティ内の「id」です。これにより、物事がより良い視点で捉えられるようになることを願っています。私は SQL の専門家ではありませんが、見つけたものはすべて試してみたので、これまでのところ理解できます。 </p> <p>更新: これは実行されたクエリです: </p> <pre class="brush:php;toolbar:false;">SELECT s0_.name AS name_0, s0_.id AS id_1, GROUP_CONCAT(DISTINCT u1_.name SEPARATOR ', ') AS sclr_2 FROM site s0_ LEFT JOIN アクセス a2_ ON s0_.id = a2_.entity_id AND a2_.type IN ('site_member') AND (a2_.revoked_at は NULL) LEFT JOIN ユーザー u1_ ON a2_.security_identity_id = u1_.id AND (a2_.approver_job_reactive_weight IS NOT NULL)</pre> <p>これにより、最初のサイト レコードがそのメンバーシップとユーザー権限とともに返されます。しかし、この列でも2分以上かかります。 </p> <p>(メンバエンティティ)テーブルにアクセスするためのテーブル作成情報です</p> <pre class="brush:php;toolbar:false;">'CREATE TABLE `access` ( `id` int(11) NOT NULL AUTO_INCREMENT、 `buddy_id` int(11) デフォルト NULL、 `security_identity_id` int(11) デフォルト NULL、 `revoked_at` datetime DEFAULT NULL、 `created_at` 日時が NULL ではありません。 `updated_at` 日時が NULL ではありません。 `type` varchar(255) COLLATE utf8_unicode_ci NOT NULL、 `approver_job_reactive_weight` int(11) DEFAULT NULL, `entity_id` int(11) デフォルト NULL、 主キー (`id`)、 一意のキー `access_idx` (`type`、`security_identity_id`、`entity_id`、`buddy_id`)、 キー `IDX_6692B54395CE8D6` (`buddy_id`)、 KEY `IDX_6692B54DF9183C9` (`security_identity_id`)、 KEY `IDX_6692B5481257D5D` (`entity_id`)、 KEY `idx_revoked_id_approver_type` (`revoked_at`、`entity_id`、`approver_job_reactive_weight`、`approver_job_planned_weight`、`type`)、 KEY `idx_user_site_access` (`revoked_at`、`security_identity_id`、`buddy_id`、`type`)、 KEY `idx_user` (`security_identity_id`)、 KEY `idx_user_id` (`security_identity_id`)、 制約 `FK_6692B54DF9183C9` 外部キー (`security_identity_id`) 参照 `user` (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=262441 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci'</pre> <p>関係のない列をいくつか削除しました。 </p>