Оптимизация запроса MySQL с внутренним соединением

Я обновил запрос, используя соединения вместо соединения в предложении WHERE. Также, взглянув на него, как разработчик, вы можете напрямую увидеть взаимосвязь между таблицами. А->В, А->D и D->С. Теперь в таблице B, где вам нужен самый высокий идентификатор на основе общего «ID = Index_ID» И RDD = 11305, не потребуется полный подзапрос. Однако это переместило «MAX ()» в верхнюю часть предложения выбора поля. Я бы удостоверился, что у вас есть индекс в tblB (index_id, rdd). Наконец, выполнение STRAIGHT_JOIN поможет обеспечить порядок выполнения запроса в зависимости от того, как конкретно указано.

-- РЕДАКТИРОВАТЬ ИЗ КОММЕНТАРИЯ --

Похоже, вы получаете нули из tblB. Обычно это указывает на действительную запись tblA, но не на запись tblB с тем же идентификатором, который имеет RDD = 11305. Тем не менее, похоже, что вас интересуют только те записи, которые связаны с 11305, поэтому я соответствующим образом корректирую запрос. Убедитесь, что у вас есть индекс в tblB на основе столбца «RDD» (по крайней мере, в первой позиции в случае индекса с несколькими столбцами)

Как вы можете видеть в этом, я предварительно запрашиваю из таблицы B только 11305 записей и предварительно группирую по index_ID (как связано с tblA). Это дает мне одну запись для каждого индекса, где они будут существовать... Из ЭТОГО результата я присоединяюсь обратно к A, затем снова обратно к B, но на основе этого самого высокого найденного идентификатора совпадения, затем D и C, как было раньше. Итак, СЕЙЧАС вы можете получить любой столбец из любой таблицы и получить соответствующую запись... В этом запросе не должно оставаться значений NULL.

Надеюсь, я объяснил, КАК я собираю кусочки для вас.

SELECT STRAIGHT_JOIN 
      PreQuery.HighestPerIndexID
      tblA.id, 
      tblA.AnotherAField,
      tblA.Etc,
      tblB.SomeOtherField,
      tblB.AnotherField,
      tblC.id, 
      tblD.id
   FROM 
      ( select PQ1.Index_ID,
               max( PQ1.ID ) as HighestPerIndexID
           from tblB PQ1
           where PQ1.RDD = 11305
           group by PQ1.Index_ID ) PreQuery

         JOIN tblA
            on PreQuery.Index_ID = tblA.ID

         join tblB
            on PreQuery.HighestPerIndexID = tblB.ID

         join tblD
            on tblA.s_Name = tblD.name

            join tblC
               on tblD.s_type = tblC.Name
    ORDER BY 
       tblA.s_Name

Если я неправильно понял предоставленную вами информацию, я считаю, что вы могли бы переписать приведенный выше запрос следующим образом.

EXPLAIN SELECT tblA.id, MAX(tblB.id), tblC.id, tblD.id
FROM tblA
LEFT JOIN tblD ON tblD.name = tblA.s_name
LEFT JOIN tblC ON tblC.name = tblD.s_type
LEFT JOIN tblB ON tblA.id = tblB.index_id
WHERE tblB.rdd = 11305
ORDER BY NULL;

Очевидно, я не могу объяснить это, поскольку объяснение зависит от данных в вашей базе данных. Было бы интересно увидеть объяснение этого запроса.

Очевидно, что объяснение только дает вам оценку того, что произойдет. Вы можете использовать SHOW SESSION STATUS, чтобы предоставить подробную информацию о том, что произошло при выполнении фактического запроса. Обязательно запустите его перед выполнением исследуемого запроса, чтобы у вас были чистые данные для чтения. Так что в этом случае вы бы бежали

FLUSH STATUS;

EXPLAIN SELECT tblA.id, MAX(tblB.id), tblC.id, tblD.id
FROM tblA
LEFT JOIN tblD ON tblD.name = tblA.s_name
LEFT JOIN tblC ON tblC.name = tblD.s_type
LEFT JOIN tblB ON tblA.id = tblB.index_id
WHERE tblB.rdd = 11305
ORDER BY NULL;

SHOW SESSION STATUS LIKE 'ha%';

Это дает вам ряд индикаторов, показывающих, что на самом деле произошло при выполнении запроса.

Handler_read_rnd_next - Number of requests to read next row in the data file
Handler_read_key - Number of requests to read a row based on a key
Handler_read_next - Number of requests to read the next row in key order

Используя эти значения, вы можете точно увидеть, что происходит под капотом.

К сожалению, не зная данных в таблицах, типа движка и типов данных, используемых в запросах, довольно сложно посоветовать, как можно оптимизировать.