MySQL: оптимизируйте UNION с помощью «ORDER BY» во внутренних запросах

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

Существует одна таблица для каждого источника данных.

Для просмотра журнала я хочу

• UNION все журнальные таблицы ,
• фильтровать их по аккаунту ,
• добавить псевдостолбец для идентификации источника,
• сортировать их по времени ,
• и ограничить их для нумерации страниц .

Все таблицы содержат поле с именем, zeitpunktкоторое является индексированным столбцом даты / времени.

Моя первая попытка была:

(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt AS zeit,
 'hp' AS source FROM is_log AS l WHERE l.account_id = 730)

UNION

(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt,
 'ig' AS source FROM ig_is_log AS l WHERE l.account_id = 730)

ORDER BY zeit DESC LIMIT 10;

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

Мой обходной путь был следующим:

(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt AS zeit,
 'hp' AS source FROM is_log AS l WHERE l.account_id = 730
 ORDER BY l.zeitpunkt DESC LIMIT 10)

UNION

(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt,
 'ig' AS source FROM ig_is_log AS l WHERE l.account_id = 730
 ORDER BY l.zeitpunkt DESC LIMIT 10)

ORDER BY zeit DESC LIMIT 10;

Я ожидал, что механизм запросов будет использовать индексы здесь, так как оба подзапроса должны быть отсортированы и ограничены уже до UNION, который затем объединяет и сортирует строки.

Я действительно думал, что это так, но выполнение EXPLAINзапроса говорит мне, что подзапросы все еще ищут обе таблицы.

EXPLAINingСами подзапросы показывают мне желаемую оптимизацию, а UNIONingих вместе - нет.

Я что-то пропустил?

Я знаю, что ORDER BYпредложения внутри UNIONподзапросов игнорируются без LIMIT, но есть предел.

Изменить:
На самом деле, вероятно, также будут запросы безaccount_idусловия.

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

Я должен держать своего рода слой между читателями журнала и фактическими таблицами.

Вот планы выполнения для всего запроса и первого подзапроса, а также детализация таблицы:

https://gist.github.com/ca8fc1093cd95b1c6fc0

Просто из любопытства, вы можете попробовать эту версию? Оптимизатор может обмануть использование тех же индексов, которые подзапросы будут использовать отдельно:

SELECT *
FROM
(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt AS zeit,
 'hp' AS source FROM is_log AS l WHERE l.account_id = 730
 ORDER BY l.zeitpunkt DESC LIMIT 10) 
    AS a

UNION ALL

SELECT *
FROM
(SELECT l.id, l.account_id, l.vnum, l.count, l.preis, l.zeitpunkt,
 'ig' AS source FROM ig_is_log AS l WHERE l.account_id = 730
 ORDER BY l.zeitpunkt DESC LIMIT 10)
    AS b

ORDER BY zeit DESC LIMIT 10;

Я все еще думаю, что лучший индекс, который вы могли бы иметь, - это сложный (account_id, zeitpunkt). Это дало бы 10 рядов быстро, и никаких трюков не понадобилось бы.