Как оптимизировать план выполнения запроса с несколькими внешними соединениями с огромными таблицами, предложениями group by и order by?

объяснение показывает, что вы делаете индекс-сканирование ("индекс" в type столбец) в таблице отслеживания. Сканирование индекса почти так же дорого, как сканирование таблицы, особенно когда сканируемый индекс является основным индексом.

The также показывает, что это сканирование индекса исследует строки > 355K (поскольку этот показатель является только приблизительной оценкой, он фактически изучает все строки 400K).

у вас есть индекс на t.manufacture? Я вижу два индекса, названных в possible keys что может включать этот столбец (я не могу быть уверен только на основе имени индекса), но по какой-то причине оптимизатор не использует их. Возможно, набор значений, который вы ищете, в любом случае соответствует каждой строке в таблице.

если список manufacture значения предназначены для соответствия подмножеству таблицы, тогда вам может потребоваться дать подсказку оптимизатору, чтобы он использовал лучший индекс. https://dev.mysql.com/doc/refman/5.6/en/index-hints.html

используя LIKE '%word%' сопоставление шаблонов никогда не может использовать индекс и должно оценивать соответствие шаблонов в каждой строке. Смотрите мою презентацию,Полнотекстовый Поиск Throwdown.

сколько элементов в вашем IN(...) список? MySQL иногда имеет проблемы с очень длинными списками. Смотри https://dev.mysql.com/doc/refman/5.6/en/range-optimization.html#equality-range-optimization

P. S.: Когда вы задаете вопрос оптимизации запросов, вы всегда должны включать SHOW CREATE TABLE вывод для каждой таблицы, на которую ссылается запрос, поэтому людям, которые отвечают, не нужно угадывать, какие индексы, типы данных, ограничения у вас есть в настоящее время.

прежде всего: ваш запрос делает предположения о содержимом строки, чего не должно быть. Что может!--3--> указать? Что-то вроде 'Sold in Europe only' может? Или Sold outside Europe only? Две возможные строки с противоречивыми значениями. Поэтому, если вы принимаете определенное значение, как только найдете europe в строке, то вы должны быть в состоянии ввести эти знания в базе данных - с флагом Европы или кодом региона, например.

в любом случае, вы показываете определенные треки с их Европой транспортный отсчет. Итак, выберите трекинги, выберите количество перевозок. Вы можете либо иметь подзапрос агрегации для подсчетов транспортировки в вашем SELECT пункт или в вашем FROM предложения.

вложенный запрос в SELECT статья:

select
  t.*,
  (
    select count(*)
    from tracking_items ti
    where ti.tracking_id = t.id
    and (tracking_type, tracking_object_id) in
    (
      select 1, car_id from cars where car_text like '%europe%'
      union all
      select 2, bike_id from bikes where bike_text like '%europe%'
      union all
      select 3, truck_id from trucks where truck_text like '%europe%'
    )
from tracking t
where manufacture in ('1256703406078', '9600048390403', '1533405067830')
order by date_last_activity, id;

вложенный запрос в FROM статья:

select
  t.*, agg.total
from tracking t
left join
(
  select tracking_id, count(*) as total
  from tracking_items ti
  and (tracking_type, tracking_object_id) in
  (
    select 1, car_id from cars where car_text like '%europe%'
    union all
    select 2, bike_id from bikes where bike_text like '%europe%'
    union all
    select 3, truck_id from trucks where truck_text like '%europe%'
  )
  group by tracking_id
) agg on agg.tracking_id = t.id
where manufacture in ('1256703406078', '9600048390403', '1533405067830')
order by date_last_activity, id;

указатели:

• отслеживание (производство, date_last_activity, id)
• tracking_items(tracking_id, tracking_type, tracking_object_id)
• автомобили(car_text, car_id)
• велосипеды(bike_text, bike_id)
• грузовики(truck_text, truck_id)

иногда MySQL сильнее на простых соединениях, чем на чем-либо еще, поэтому, возможно, стоит попробовать слепо присоединиться к транспортным записям и только позже увидеть, является ли это автомобилем, велосипедом или грузовиком:

select
  t.*, agg.total
from tracking t
left join
(
  select
    tracking_id,
    sum((ti.tracking_type = 1 and c.car_text like '%europe%')
        or
        (ti.tracking_type = 2 and b.bike_text like '%europe%')
        or
        (ti.tracking_type = 3 and t.truck_text like '%europe%')
       ) as total
  from tracking_items ti
  left join cars c on c.car_id = ti.tracking_object_id
  left join bikes b on c.bike_id = ti.tracking_object_id
  left join trucks t on t.truck_id = ti.tracking_object_id
  group by tracking_id
) agg on agg.tracking_id = t.id
where manufacture in ('1256703406078', '9600048390403', '1533405067830')
order by date_last_activity, id;

если моя догадка верна и cars, bikes и trucks независимы друг от друга (т. е. определенный заранее вычислить результат был только у одной из них). Возможно, вам лучше объединить три более простых подзапроса (по одному для каждого).

в то время как вы не можете сделать много индексов о подобных с участием ведущих подстановочных знаков; разделение его на Юнионированные запросы может позволить избежать оценки p.fb_message LIKE '%Europe%' OR p.fb_from_name LIKE '%Europe% для всех cars и bikes матчи, и c условия для всех b и t матчи, и так далее.

когда есть order by и group by предложения запрос выполняется очень медленно, например 10-15 секунд для завершения вышеуказанной конфигурации. Однако, если я опущу любое из этих предложений, запрос выполняется довольно быстро (~0,2 секунды).

Это интересно... как правило, лучший метод оптимизации, который я знаю, - это хорошее использование временных таблиц, и похоже, что здесь он будет работать очень хорошо. Таким образом, вы сначала создадите временное таблица:

create temporary table tracking_ungrouped (
    key (id)
)
select sql_no_cache `t`.*
from `tracking` as `t` 
inner join `tracking_items` as `ti` on (`ti`.`tracking_id` = `t`.`id`)
    left join `cars` as `c` on (`c`.`car_id` = `ti`.`tracking_object_id` AND `ti`.`tracking_type` = 1)
    left join `bikes` as `b` on (`b`.`bike_id` = `ti`.`tracking_object_id` AND `ti`.`tracking_type` = 2)    
    left join `trucks` as `tr` on (`tr`.`truck_id` = `ti`.`tracking_object_id` AND `ti`.`tracking_type` = 3)
where 
    (`t`.`manufacture` in('1256703406078', '9600048390403', '1533405067830')) and 
    (`c`.`car_text` like '%europe%' or `b`.`bike_text` like '%europe%' or `tr`.`truck_text` like '%europe%');

а затем запросить его для получения необходимых результатов:

select t.*, count(`t`.`id`) as `cnt_filtered_items`
from tracking_ungrouped t
group by `t`.`id` 
order by `t`.`date_last_activity` asc, `t`.`id` asc 
limit 15;

ALTER TABLE cars ADD FULLTEXT(car_text)

select  sql_no_cache
        `t`.*,  -- If you are not using all, spell out the list
        count(`t`.`id`) as `cnt_filtered_items`  -- This does not make sense
                         -- and is possibly delivering an inflated value
    from  `tracking` as `t`
    inner join  `tracking_items` as `ti`  ON (`ti`.`tracking_id` = `t`.`id`)
    join   -- not LEFT JOIN
         `cars` as `c`  ON `c`.`car_id` = `ti`.`tracking_object_id`
                                     AND  `ti`.`tracking_type` = 1 
    where  `t`.`manufacture` in('1256703406078', '9600048390403', '1533405067830')
      AND  MATCH(c.car_text)  AGAINST('+europe' IN BOOLEAN MODE)
    group by  `t`.`id`    -- I don't know if this is necessary
    order by  `t`.`date_last_activity` asc, `t`.`id` asc
    limit  15;

чтобы увидеть, если он правильно даст вам подходящий 15 - автомобили.

если это выглядит нормально, то объедините три вместе:

SELECT  sql_no_cache
        t2.*,
        -- COUNT(*)  -- this is probably broken
    FROM (
        ( SELECT t.id FROM ... cars ... )  -- the query above
        UNION ALL     -- unless you need UNION DISTINCT
        ( SELECT t.id FROM ... bikes ... )
        UNION ALL
        ( SELECT t.id FROM ... trucks ... )
         ) AS u
    JOIN tracking AS t2  ON t2.id = u.id
    ORDER BY t2.date_last_activity, t2.id
    LIMIT 15;

обратите внимание, что внутри SELECTs только поставить t.id, а не t.*.

ti:  (tracking_type, tracking_object_id)   -- in either order

индексы

когда у вас есть INDEX(a,b), вам не нужно INDEX(a). (Это не поможет запросу в вопрос, но это поможет дисковое пространство и INSERT производительность.)

когда я вижу PRIMARY KEY(id), UNIQUE(x), Я ищу любую вескую причину, чтобы не избавиться от id и заменить на PRIMARY KEY(x). Если в "упрощении" схемы нет чего-то значительного, такое изменение поможет. Да,car_id громоздкий и т. д., Но это большая таблица, и дополнительный поиск (от индекса BTree до данных BTree) вредит и т. д.

я думаю, что это очень маловероятно, что KEYsort_field(date_order) всегда будет использоваться. Либо отбросьте его (сохранив несколько ГБ), либо объедините его каким-то полезным способом. Давайте посмотрим запрос, в котором вы думаете, что это может быть полезно. (Опять же, предложение, которое не имеет прямого отношения к этому вопросу.)

повторное замечание(с)

я внес некоторые существенные изменения в свою формулировку.

моя формулировка имеет 4 GROUP BYs, 3 в "производной" таблице (т. е. FROM ( ... UNION ... )), и один снаружи. Поскольку внешняя часть ограничена строками 3*15, I не беспокойтесь о производительности.

далее обратите внимание, что производная таблица поставляет только t.id, затем повторно пробники tracking чтобы получить другие столбцы. Это позволяет производной таблице работать намного быстрее, но за небольшой счет extra JOIN снаружи.

пожалуйста, подробнее о намерении COUNT(t.id); он не будет работать в моей формулировке, и я не знаю, что это подсчет.

я должен был избавиться от ORs; они вторичное представление убийца. (Первый убийца LIKE '%...'.)

SELECT t.*
FROM (SELECT * FROM tracking WHERE manufacture 
                IN('1256703406078','9600048390403','1533405067830')) t
INNER JOIN (SELECT tracking_id, tracking_object_id, tracking_type FROM tracking_items
    WHERE tracking_type IN (1,2,3)) ti 
    ON (ti.tracking_id = t.id)
LEFT JOIN (SELECT car_id, FROM cars WHERE car_text LIKE '%europe%') c 
ON (c.car_id = ti.tracking_object_id AND ti.tracking_type = 1)
    LEFT JOIN (SELECT bike_id FROM bikes WHERE bike_text LIKE '%europe%') b 
ON (b.bike_id = ti.tracking_object_id AND ti.tracking_type = 2)
    LEFT JOIN (SELECT truck_id FROM trucks WHERE truck_text LIKE '%europe%') tr 
ON (tr.truck_id = ti.tracking_object_id AND ti.tracking_type = 3)
    ORDER BY t.date_last_activity ASC, t.id ASC

подзапросы работают быстрее, когда дело доходит до объединения, и если они собираются отфильтровать много записей.

подзапросе отслеживание таблица отфильтрует много других нежелательных производство и приводит к меньшей таблице t присоединиться.

аналогично применяется условие tracking_items таблица, поскольку нас интересует только tracking_types 1,2 и 3; чтобы создать меньшую таблицу ti. Если существует много tracking_objects, вы даже можете добавить фильтр объекта отслеживания в этот подзапрос.

аналогичные подходы к таблицам автомобили, мотоциклы, грузовики с условием их текст, чтобы содержать Европы помогает нам создавать меньшие таблицы c, b, tr соответственно.

также удаление группы по t.id как t.id уникален, и мы выполнение внутреннего соединения и левого соединения на этой или результирующей таблице, так как нет необходимости.

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

надеюсь, что это помогает. Пожалуйста, дайте мне знать ваши отзывы и запустить статистику.

Я не уверен, что это сработает, как насчет применения фильтра к каждой таблице (автомобили, велосипеды и грузовики) в предложении ON, прежде чем присоединиться,он должен отфильтровать строки?