MySQL: Otimize UNION com "ORDER BY" em consultas internas

Acabei de configurar um sistema de registro que consiste em várias tabelas com o mesmo layout.

Há uma tabela para cada fonte de dados.

Para o visualizador de logs, quero

• UNION todas as tabelas de log ,
• filtrá-los por conta ,
• adicione uma pseudo-coluna para identificação da fonte,
• classificá-los por tempo ,
• e limite-os para paginação .

Todas as tabelas contêm um campo chamado zeitpunktque é uma coluna de data / hora indexada.

Minha primeira tentativa foi:

(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;

O otimizador não pode usar os índices aqui porque todas as linhas de ambas as tabelas são retornadas pelas subconsultas e classificadas após o UNION.

Minha solução alternativa foi a seguinte:

(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;

Eu esperava que o mecanismo de consulta usasse os índices aqui, já que as duas subconsultas já deveriam ser classificadas e limitadas antes da UNION, que depois mescla e classifica as linhas.

Eu realmente pensei que seria isso, mas a execução EXPLAINda consulta me diz que as subconsultas ainda pesquisam as duas tabelas.

EXPLAINingas próprias subconsultas me mostram a otimização desejada, mas UNIONingelas juntas não.

Perdi alguma coisa?

Eu sei que ORDER BYcláusulas dentro de UNIONsubconsultas são ignoradas sem a LIMIT, mas há um limite.

Edit:
Na verdade, provavelmente também haverá consultas sem aaccount_idcondição.

As tabelas já existem e são preenchidas com dados. Pode haver alterações no layout, dependendo da fonte, então eu quero mantê-las divididas. Além disso, os clientes de log usam credenciais diferentes por um motivo.

Eu tenho que manter um tipo de camada entre os leitores de log e as tabelas reais.

Aqui estão os planos de execução para toda a consulta e a primeira subconsulta, bem como o layout da tabela em detalhes:

https://gist.github.com/ca8fc1093cd95b1c6fc0

Por curiosidade, você pode experimentar esta versão? Pode ser um truque para o otimizador usar os mesmos índices que as subconsultas usariam separadamente:

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;

Eu ainda acho que o melhor índice que você poderia ter é o composto (account_id, zeitpunkt). Produziria as 10 linhas rapidamente, e nenhum truque seria necessário.