Возможные решения для медленных левых соединений в сложном запросе доктрины

У меня есть метод репозитория Symfony, который извлекает довольно сложный набор данных, который затем будет помещен в файл CSV классом менеджера экспорта. Я не хочу размещать весь код обработки задания экспорта, но мне удалось выделить точку, в которой запрос замедляется, поэтому мой вопрос касается любой другой альтернативы для ускорения этого запроса, а не самого кода. Таким образом, полученные данные представляют собой некоторые данные «сайта», которые имеют несколько «членств», которые затем имеют «пользователя». Итак, проблема в том, что когда мой запрос пытается присоединить информацию о пользователе к сайту, это замедляет выполнение. Это выглядит так:

$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');  

Есть несколько вещей (я пробовал или думал, может помочь), чтобы упомянуть:

• Я проверил таблицы, все связанные столбцы имеют индекс и имеют один и тот же тип данных int.
• Я прочитал статью о проблемах с производительностью DQL, где упоминалось, что чрезмерное использование вызовов DQL Left Join может привести к снижению производительности, поскольку они повторно отображают один и тот же объект сущности снова и снова. Возможное решение, упомянутое там, заключалось в том, чтобы получить основной набор данных, а затем, прокручивая коллекцию, добавить дополнительные (объединяющие поля данных) к каждому элементу непосредственно из класса сущности поля. Это, возможно, могло бы сработать (не уверен, какое влияние это окажет), проблема в том, что у меня действительно сложный унаследованный код, и я не хочу касаться логики менеджера экспорта, потому что это потребует слишком много тестирования. Менеджер экспорта ожидает класс построителя запросов, поэтому мне нужно найти решение в самом запросе.
• Проблема определенно вызвана соединением, а не предложением «WITH» или дополнительными условиями. Я попытался вызвать запрос с помощью простого вызова leftJoin, тот же результат.
• Я знаю, что методы leftJoin можно вызывать в цепочке друг к другу, код выглядит так, потому что некоторые из этих вызовов используются в операторах if.
• Я провожу 2 дня, пробуя всевозможные вещи, найденные здесь и на других сайтах.

Существует 6 различных типов пользователей, на данный момент я только что вызвал скрипт, извлекающий тот, что указан выше, и возврат данных занял 33 минуты. Речь идет о 512 сайтах, что не является огромным набором данных. Итак, мой вопрос: существует ли другой способ DQL или Doctrine для упрощения или уменьшения количества вызовов leftJoins в таком сложном запросе и как-то улучшить производительность?

Обновлять: Я думаю, что проблема связана с индексами, поэтому я подробно расскажу об отношениях: Сущность «членство» происходит из таблицы с именем «доступ», отношение к пользователю в ее модели выглядит следующим образом:

/**
 * The user this membership encapsulates.
 *
 * @ORM\ManyToOne(targetEntity = "User", inversedBy = "siteMemberships", cascade = {"persist"})
 * @ORM\JoinColumn(name = "security_identity_id", referencedColumnName = "id")
 *
 * @var User
 */
protected $user; 

Вот скриншот индексов, присвоенных столбцам «security_identity_id».

И связанный пользователь происходит из таблицы «пользователь», имеющей это отношение, указывающее на членство

/**
 * @ORM\OneToMany(targetEntity = "SiteMembership", mappedBy = "user", cascade = {"persist"}, fetch = "EXTRA_LAZY")
 */
protected $siteMemberships;

Первичный ключ — это «id» в сущности. Надеюсь, это даст лучшее представление о проблеме. Я не эксперт по sql, но перепробовал все, что нашел и смог понять до сих пор.

Обновлять: Вот выполненный запрос:

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 access a2_ ON s0_.id = a2_.entity_id 
  AND a2_.type IN ('site_member') 
  AND (a2_.revoked_at IS NULL) 
  LEFT JOIN user u1_ ON a2_.security_identity_id = u1_.id 
  AND (a2_.approver_job_reactive_weight IS NOT NULL)

Это возвращает первую запись сайта с присоединенным к ней членством и пользовательскими правами. Но даже фетиш этого одного единственного ряда занимает более 2 минут.

Вот информация о создании таблицы таблицы доступа (членства).

'CREATE TABLE `access` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `buddy_id` int(11) DEFAULT NULL,
  `security_identity_id` int(11) DEFAULT NULL,
  `revoked_at` datetime DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  `type` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `approver_job_reactive_weight` int(11) DEFAULT NULL,
  `entity_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `access_idx` (`type`,`security_identity_id`,`entity_id`,`buddy_id`),
  KEY `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`),
  CONSTRAINT `FK_6692B54DF9183C9` FOREIGN KEY (`security_identity_id`) REFERENCES `user` (`id`)
)
ENGINE=InnoDB AUTO_INCREMENT=262441 DEFAULT CHARSET=utf8 
COLLATE=utf8_unicode_ci'

Я удалил некоторые столбцы, которые не имеют отношения к делу.