Uma abordagem possível para otimizar as consultas de pesquisa é (a) armazenar os registros que retêm dados que correspondem a diferentes relações/tabelas em (b) o mesmo arquivo → nas mesmas páginas. Dessa forma, uma junção pode ser executada muito mais rapidamente.
Eu pesquisei "co-clustering" e surpreendentemente poucos resultados apareceram. Não encontrei nada no MySQL, por exemplo. Há alguma indicação de que a Oracle o ofereceu há 10 anos. O co-clustering ainda é uma opção válida para otimização?
Por exemplo, você tem duas relações/tabelas:
Employee (id, name, age, did)Department (did, location)
Uma consulta típica para a qual você otimiza talvez seja algo assim:
SELECT E.name,
E.age
FROM Employee E,
Department D
WHERE E.age = 25
AND E.did = D.did;
Se você tinha 1.000.000 de funcionários e todos eles têm entre 25 e 27, o melhor método de junção é provavelmente a junção por mesclagem ou junção por hash - ambos exigem várias verificações.
Agora, se você armazena tuplas/linhas de várias relações/tabelas na mesma página, você pode usar uma estrutura física que armazena um departamento com um determinado didjuntamente com funcionários com o mesmo did. Observe que essa junção requer muito menos E/S.
Claro, é uma opção válida para otimização, se o seu SGBD oferecer. Como David Browne mencionou em um comentário, apenas a Oracle faz (o que, de certa forma, diz o quão prático é esse recurso).
Como você observou, é útil em um conjunto muito limitado de cenários, ao mesmo tempo em que é prejudicial para uma variedade maior de consultas. Nos casos que podem se beneficiar do agrupamento de tabelas, você pode empregar técnicas de otimização alternativas, como exibições materializadas (indexadas) ou tabelas organizadas por colunas, que oferecem benefícios de desempenho semelhantes e estão mais amplamente disponíveis.
Considere também que hoje o uso comum de armazenamento SSD, abundância de RAM barata em servidores de banco de dados, em combinação com melhores otimizadores de consulta, diminuem o valor da redução marginal na E/S física ao custo de possíveis efeitos colaterais negativos e sobrecarga adicional de manutenção de banco de dados.
TLDR: não se preocupe.