Junção vs. subconsulta

Eu sou um usuário antigo do MySQL e sempre preferi JOINa subconsulta. Mas hoje em dia todo mundo usa subconsulta, e eu odeio isso; Não sei porque.

Não tenho o conhecimento teórico para julgar por mim mesmo se há alguma diferença. Uma subconsulta é tão boa quanto uma JOINe, portanto, não há nada com que se preocupar?

Retirado do manual do MySQL ( 13.2.10.11 Reescrevendo subconsultas como associações ):

Uma junção [ESQUERDA] ESQUERDA pode ser mais rápida que uma subconsulta equivalente, porque o servidor pode otimizar melhor - um fato que não é específico apenas ao MySQL Server.

Portanto, as subconsultas podem ser mais lentas que LEFT [OUTER] JOIN, mas, na minha opinião, a força delas é uma legibilidade um pouco maior.

As subconsultas são a maneira logicamente correta de resolver problemas do formulário "Obter fatos de A, condicional aos fatos de B". Nesses casos, faz mais sentido lógico colocar B em uma subconsulta do que fazer uma associação. Também é mais seguro, no sentido prático, já que você não precisa ser cauteloso ao obter fatos duplicados de A devido a várias partidas contra B.

Praticamente falando, no entanto, a resposta geralmente se resume ao desempenho. Alguns otimizadores sugam limões quando recebem uma junção versus uma subconsulta, e outros sugam limões de outra maneira, e isso é específico do otimizador, específico da versão do DBMS e específico da consulta.

Historicamente, as junções explícitas geralmente vencem, daí a sabedoria estabelecida de que as junções são melhores, mas os otimizadores estão melhorando o tempo todo e, portanto, prefiro escrever as consultas primeiro de uma maneira logicamente coerente e depois reestruturar se as restrições de desempenho justificarem isso.

Na maioria dos casos, JOINs são mais rápidos que as subconsultas e é muito raro uma subconsulta ser mais rápida.

No JOINs, o RDBMS pode criar um plano de execução melhor para sua consulta e prever quais dados devem ser carregados para serem processados ​​e economizar tempo, ao contrário da subconsulta em que ele executará todas as consultas e carregará todos os dados para fazer o processamento. .

O bom das subconsultas é que elas são mais legíveis que JOINs: é por isso que a maioria das pessoas novas do SQL prefere; é o caminho mais fácil; mas quando se trata de desempenho, o JOINS é melhor na maioria dos casos, mesmo que também não seja difícil de ler.

Use EXPLAIN para ver como seu banco de dados executa a consulta em seus dados. Existe uma enorme "depende" nesta resposta ...

O PostgreSQL pode reescrever uma subconsulta em uma junção ou uma junção em uma subconsulta quando achar que uma é mais rápida que a outra. Tudo depende dos dados, índices, correlação, quantidade de dados, consulta, etc.

No ano de 2010, eu teria me juntado ao autor dessas perguntas e teria votado fortemente JOIN, mas com muito mais experiência (especialmente no MySQL), posso afirmar: Sim, as subconsultas podem ser melhores. Eu li várias respostas aqui; algumas subconsultas declaradas são mais rápidas, mas faltavam uma boa explicação. Espero poder fornecer uma com esta (muito) resposta tardia:

Antes de mais, deixe-me dizer o mais importante: existem diferentes formas de subconsultas

E a segunda declaração importante: o tamanho importa

Se você usar subconsultas, esteja ciente de como o DB-Server executa a subconsulta. Especialmente se a subconsulta for avaliada uma vez ou para cada linha! Por outro lado, um servidor de banco de dados moderno é capaz de otimizar muito. Em alguns casos, uma subconsulta ajuda a otimizar uma consulta, mas uma versão mais recente do DB-Server pode tornar a otimização obsoleta.

Subconsultas em campos selecionados

SELECT moo, (SELECT roger FROM wilco WHERE moo = me) AS bar FROM foo

Esteja ciente de que uma subconsulta é executada para cada linha resultante foo.
Evite isso, se possível; isso pode diminuir drasticamente a sua consulta em grandes conjuntos de dados. No entanto, se a subconsulta não tiver nenhuma referência, fooela poderá ser otimizada pelo servidor de banco de dados como conteúdo estático e poderá ser avaliada apenas uma vez.

Subconsultas na instrução Where

SELECT moo FROM foo WHERE bar = (SELECT roger FROM wilco WHERE moo = me)

Se você tiver sorte, o banco de dados otimiza isso internamente em um JOIN. Caso contrário, sua consulta se tornará muito, muito lenta em grandes conjuntos de dados, porque executará a subconsulta para cada linha foo, não apenas os resultados, como no tipo de seleção.

Subconsultas na instrução Join

SELECT moo, bar 
  FROM foo 
    LEFT JOIN (
      SELECT MIN(bar), me FROM wilco GROUP BY me
    ) ON moo = me

Isto é interessante. Combinamos JOINcom uma subconsulta. E aqui temos a força real das subconsultas. Imagine um conjunto de dados com milhões de linhas, wilcomas apenas algumas distintas me. Em vez de ingressar em uma mesa enorme, agora temos uma mesa temporária menor para participar. Isso pode resultar em consultas muito mais rápidas, dependendo do tamanho do banco de dados. Você pode ter o mesmo efeito com CREATE TEMPORARY TABLE ...e INSERT INTO ... SELECT ..., o que pode fornecer melhor legibilidade em consultas muito complexas (mas pode bloquear conjuntos de dados em um nível de isolamento de leitura repetível).

Subconsultas aninhadas

SELECT moo, bar
  FROM (
    SELECT moo, CONCAT(roger, wilco) AS bar
      FROM foo
      GROUP BY moo
      HAVING bar LIKE 'SpaceQ%'
  ) AS temp_foo
  ORDER BY bar

Você pode aninhar subconsultas em vários níveis. Isso pode ajudar em grandes conjuntos de dados se você precisar agrupar ou classificar os resultados. Normalmente, o servidor de banco de dados cria uma tabela temporária para isso, mas às vezes você não precisa classificar a tabela inteira, apenas o conjunto de resultados. Isso pode fornecer um desempenho muito melhor, dependendo do tamanho da tabela.

Conclusão

As subconsultas não substituem a JOINe você não deve usá-las dessa maneira (embora possível). Na minha humilde opinião, o uso correto de uma subconsulta é o uso como uma substituição rápida de CREATE TEMPORARY TABLE .... Uma boa subconsulta reduz um conjunto de dados de uma maneira que você não pode realizar na ONinstrução a JOIN. Se uma sub-consulta tem uma das palavras-chave GROUP BYou DISTINCT, de preferência não está situado nos campos selecionados ou a declaração em que, em seguida, pode melhorar o desempenho muito.

Antes de tudo, para comparar os dois primeiro, você deve distinguir consultas com subconsultas para:

1. uma classe de subconsultas que sempre têm consulta equivalente correspondente gravada com junções
2. uma classe de subconsultas que não podem ser reescritas usando junções

Para a primeira classe de consultas, um bom RDBMS verá junções e subconsultas como equivalentes e produzirá os mesmos planos de consulta.

Hoje em dia, até o mysql faz isso.

Ainda assim, às vezes isso não acontece, mas isso não significa que as junções sempre vencerão - eu tive casos ao usar subconsultas no mysql para melhorar o desempenho. (Por exemplo, se houver algo impedindo o planejador do mysql estimar corretamente o custo e se o planejador não vir a variante de junção e a variante de subconsulta da mesma forma, as subconsultas poderão superar as junções forçando um determinado caminho).

A conclusão é que você deve testar suas consultas para as variantes de junção e subconsulta, se quiser ter certeza de qual delas terá um desempenho melhor.

Para a segunda classe, a comparação não faz sentido, pois essas consultas não podem ser reescritas usando junções e, nesses casos, as subconsultas são uma maneira natural de executar as tarefas necessárias e você não deve discriminá-las.

Eu acho que o que foi subestimado nas respostas citadas é a questão de duplicatas e resultados problemáticos que podem surgir de casos específicos (de uso).

(embora Marcelo Cantos o mencione)

Citarei o exemplo dos cursos Lagunita de Stanford sobre SQL.

Tabela do aluno

+------+--------+------+--------+
| sID  | sName  | GPA  | sizeHS |
+------+--------+------+--------+
|  123 | Amy    |  3.9 |   1000 |
|  234 | Bob    |  3.6 |   1500 |
|  345 | Craig  |  3.5 |    500 |
|  456 | Doris  |  3.9 |   1000 |
|  567 | Edward |  2.9 |   2000 |
|  678 | Fay    |  3.8 |    200 |
|  789 | Gary   |  3.4 |    800 |
|  987 | Helen  |  3.7 |    800 |
|  876 | Irene  |  3.9 |    400 |
|  765 | Jay    |  2.9 |   1500 |
|  654 | Amy    |  3.9 |   1000 |
|  543 | Craig  |  3.4 |   2000 |
+------+--------+------+--------+

Aplicar tabela

(pedidos feitos para universidades e cursos específicos)

+------+----------+----------------+----------+
| sID  | cName    | major          | decision |
+------+----------+----------------+----------+
|  123 | Stanford | CS             | Y        |
|  123 | Stanford | EE             | N        |
|  123 | Berkeley | CS             | Y        |
|  123 | Cornell  | EE             | Y        |
|  234 | Berkeley | biology        | N        |
|  345 | MIT      | bioengineering | Y        |
|  345 | Cornell  | bioengineering | N        |
|  345 | Cornell  | CS             | Y        |
|  345 | Cornell  | EE             | N        |
|  678 | Stanford | history        | Y        |
|  987 | Stanford | CS             | Y        |
|  987 | Berkeley | CS             | Y        |
|  876 | Stanford | CS             | N        |
|  876 | MIT      | biology        | Y        |
|  876 | MIT      | marine biology | N        |
|  765 | Stanford | history        | Y        |
|  765 | Cornell  | history        | N        |
|  765 | Cornell  | psychology     | Y        |
|  543 | MIT      | CS             | N        |
+------+----------+----------------+----------+

Vamos tentar encontrar as pontuações do GPA para estudantes que se inscreveram no ensino médio CS(independentemente da universidade)

Usando uma subconsulta:

select GPA from Student where sID in (select sID from Apply where major = 'CS');

+------+
| GPA  |
+------+
|  3.9 |
|  3.5 |
|  3.7 |
|  3.9 |
|  3.4 |
+------+

O valor médio para este conjunto de resultados é:

select avg(GPA) from Student where sID in (select sID from Apply where major = 'CS');

+--------------------+
| avg(GPA)           |
+--------------------+
| 3.6800000000000006 |
+--------------------+

Usando uma junção:

select GPA from Student, Apply where Student.sID = Apply.sID and Apply.major = 'CS';

+------+
| GPA  |
+------+
|  3.9 |
|  3.9 |
|  3.5 |
|  3.7 |
|  3.7 |
|  3.9 |
|  3.4 |
+------+

valor médio para este conjunto de resultados:

select avg(GPA) from Student, Apply where Student.sID = Apply.sID and Apply.major = 'CS';

+-------------------+
| avg(GPA)          |
+-------------------+
| 3.714285714285714 |
+-------------------+

É óbvio que a segunda tentativa produz resultados enganosos em nosso caso de uso, uma vez que conta duplicatas para o cálculo do valor médio. Também é evidente que o uso da distinctdeclaração baseada em junção não eliminará o problema, pois manterá erroneamente uma das três ocorrências da 3.9pontuação. O caso correto é contabilizar DUAS (2) ocorrências da 3.9pontuação, uma vez que realmente temos DOIS (2) alunos com essa pontuação que atendem aos nossos critérios de consulta.

Parece que, em alguns casos, uma subconsulta é o caminho mais seguro, além de quaisquer problemas de desempenho.

A documentação do MSDN para SQL Server diz

Muitas instruções Transact-SQL que incluem subconsultas podem ser formuladas alternativamente como junções. Outras perguntas podem ser feitas apenas com subconsultas. No Transact-SQL, geralmente não há diferença de desempenho entre uma instrução que inclui uma subconsulta e uma versão semanticamente equivalente que não. No entanto, em alguns casos em que a existência deve ser verificada, uma junção produz um melhor desempenho. Caso contrário, a consulta aninhada deve ser processada para cada resultado da consulta externa para garantir a eliminação de duplicatas. Nesses casos, uma abordagem de junção produziria melhores resultados.

então se você precisar de algo como

select * from t1 where exists select * from t2 where t2.parent=t1.id

tente usar join. Em outros casos, não faz diferença.

Eu digo: A criação de funções para subconsultas elimina o problema do cluttter e permite implementar lógica adicional nas subconsultas. Portanto, recomendo criar funções para subconsultas sempre que possível.

A desordem no código é um grande problema e a indústria trabalha para evitá-lo há décadas.

Execute em um banco de dados muito grande a partir de um antigo Mambo CMS:

SELECT id, alias
FROM
  mos_categories
WHERE
  id IN (
    SELECT
      DISTINCT catid
    FROM mos_content
  );

0 segundos

SELECT
  DISTINCT mos_content.catid,
  mos_categories.alias
FROM
  mos_content, mos_categories
WHERE
  mos_content.catid = mos_categories.id;

~ 3 segundos

Um EXPLAIN mostra que eles examinam exatamente o mesmo número de linhas, mas um leva 3 segundos e o outro é quase instantâneo. Moral da história? Se o desempenho é importante (quando não é?), Tente de várias maneiras e veja qual é o mais rápido.

E...

SELECT
  DISTINCT mos_categories.id,
  mos_categories.alias
FROM
  mos_content, mos_categories
WHERE
  mos_content.catid = mos_categories.id;

0 segundos

Novamente, mesmos resultados, mesmo número de linhas examinadas. Meu palpite é que DISTINCT mos_content.catid leva muito mais tempo para descobrir do que DISTINCT mos_categories.id.

Conforme minha observação, como dois casos, se uma tabela tiver menos de 100.000 registros, a junção funcionará rapidamente.

Porém, no caso de uma tabela ter mais de 100.000 registros, uma subconsulta é o melhor resultado.

Eu tenho uma tabela que possui 500.000 registros que criei abaixo da consulta e seu tempo de resultado é como

SELECT * 
FROM crv.workorder_details wd 
inner join  crv.workorder wr on wr.workorder_id = wd.workorder_id;

Resultado: 13.3 Segundos

select * 
from crv.workorder_details 
where workorder_id in (select workorder_id from crv.workorder)

Resultado: 1.65 Segundos

As subconsultas geralmente são usadas para retornar uma única linha como um valor atômico, embora possam ser usadas para comparar valores com várias linhas com a palavra-chave IN. Eles são permitidos em praticamente qualquer ponto significativo em uma instrução SQL, incluindo a lista de destino, a cláusula WHERE e assim por diante. Uma subconsulta simples pode ser usada como condição de pesquisa. Por exemplo, entre um par de tabelas:

   SELECT title FROM books WHERE author_id = (SELECT id FROM authors WHERE last_name = 'Bar' AND first_name = 'Foo');

Observe que o uso de um operador de valor normal nos resultados de uma subconsulta requer que apenas um campo seja retornado. Se você estiver interessado em verificar a existência de um único valor em um conjunto de outros valores, use IN:

   SELECT title FROM books WHERE author_id IN (SELECT id FROM authors WHERE last_name ~ '^[A-E]');

Isso é obviamente diferente de, digamos, LEFT-JOIN, no qual você apenas deseja juntar itens das tabelas A e B, mesmo que a condição de junção não encontre nenhum registro correspondente na tabela B, etc.

Se você está preocupado apenas com a velocidade, precisará verificar com o banco de dados e escrever uma boa consulta e verificar se há alguma diferença significativa no desempenho.

Versão do MySQL: 5.5.28-0ubuntu0.12.04.2-log

Também tive a impressão de que JOIN é sempre melhor que uma subconsulta no MySQL, mas EXPLAIN é a melhor maneira de fazer um julgamento. Aqui está um exemplo em que as subconsultas funcionam melhor que JOINs.

Aqui está minha consulta com 3 subconsultas:

EXPLAIN SELECT vrl.list_id,vrl.ontology_id,vrl.position,l.name AS list_name, vrlih.position AS previous_position, vrl.moved_date 
FROM `vote-ranked-listory` vrl 
INNER JOIN lists l ON l.list_id = vrl.list_id 
INNER JOIN `vote-ranked-list-item-history` vrlih ON vrl.list_id = vrlih.list_id AND vrl.ontology_id=vrlih.ontology_id AND vrlih.type='PREVIOUS_POSITION' 
INNER JOIN list_burial_state lbs ON lbs.list_id = vrl.list_id AND lbs.burial_score < 0.5 
WHERE vrl.position <= 15 AND l.status='ACTIVE' AND l.is_public=1 AND vrl.ontology_id < 1000000000 
 AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=43) IS NULL 
 AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=55) IS NULL 
 AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=246403) IS NOT NULL 
ORDER BY vrl.moved_date DESC LIMIT 200;

EXPLAIN mostra:

+----+--------------------+----------+--------+-----------------------------------------------------+--------------+---------+-------------------------------------------------+------+--------------------------+
| id | select_type        | table    | type   | possible_keys                                       | key          | key_len | ref                                             | rows | Extra                    |
+----+--------------------+----------+--------+-----------------------------------------------------+--------------+---------+-------------------------------------------------+------+--------------------------+
|  1 | PRIMARY            | vrl      | index  | PRIMARY                                             | moved_date   | 8       | NULL                                            |  200 | Using where              |
|  1 | PRIMARY            | l        | eq_ref | PRIMARY,status,ispublic,idx_lookup,is_public_status | PRIMARY      | 4       | ranker.vrl.list_id                              |    1 | Using where              |
|  1 | PRIMARY            | vrlih    | eq_ref | PRIMARY                                             | PRIMARY      | 9       | ranker.vrl.list_id,ranker.vrl.ontology_id,const |    1 | Using where              |
|  1 | PRIMARY            | lbs      | eq_ref | PRIMARY,idx_list_burial_state,burial_score          | PRIMARY      | 4       | ranker.vrl.list_id                              |    1 | Using where              |
|  4 | DEPENDENT SUBQUERY | list_tag | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.l.list_id,const                          |    1 | Using where; Using index |
|  3 | DEPENDENT SUBQUERY | list_tag | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.l.list_id,const                          |    1 | Using where; Using index |
|  2 | DEPENDENT SUBQUERY | list_tag | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.l.list_id,const                          |    1 | Using where; Using index |
+----+--------------------+----------+--------+-----------------------------------------------------+--------------+---------+-------------------------------------------------+------+--------------------------+

A mesma consulta com JOINs é:

EXPLAIN SELECT vrl.list_id,vrl.ontology_id,vrl.position,l.name AS list_name, vrlih.position AS previous_position, vrl.moved_date 
FROM `vote-ranked-listory` vrl 
INNER JOIN lists l ON l.list_id = vrl.list_id 
INNER JOIN `vote-ranked-list-item-history` vrlih ON vrl.list_id = vrlih.list_id AND vrl.ontology_id=vrlih.ontology_id AND vrlih.type='PREVIOUS_POSITION' 
INNER JOIN list_burial_state lbs ON lbs.list_id = vrl.list_id AND lbs.burial_score < 0.5 
LEFT JOIN list_tag lt1 ON lt1.list_id = vrl.list_id AND lt1.tag_id = 43 
LEFT JOIN list_tag lt2 ON lt2.list_id = vrl.list_id AND lt2.tag_id = 55 
INNER JOIN list_tag lt3 ON lt3.list_id = vrl.list_id AND lt3.tag_id = 246403 
WHERE vrl.position <= 15 AND l.status='ACTIVE' AND l.is_public=1 AND vrl.ontology_id < 1000000000 
AND lt1.list_id IS NULL AND lt2.tag_id IS NULL 
ORDER BY vrl.moved_date DESC LIMIT 200;

e a saída é:

+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+
| id | select_type | table | type   | possible_keys                                       | key          | key_len | ref                                         | rows | Extra                                        |
+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+
|  1 | SIMPLE      | lt3   | ref    | list_tag_key,list_id,tag_id                         | tag_id       | 5       | const                                       | 2386 | Using where; Using temporary; Using filesort |
|  1 | SIMPLE      | l     | eq_ref | PRIMARY,status,ispublic,idx_lookup,is_public_status | PRIMARY      | 4       | ranker.lt3.list_id                          |    1 | Using where                                  |
|  1 | SIMPLE      | vrlih | ref    | PRIMARY                                             | PRIMARY      | 4       | ranker.lt3.list_id                          |  103 | Using where                                  |
|  1 | SIMPLE      | vrl   | ref    | PRIMARY                                             | PRIMARY      | 8       | ranker.lt3.list_id,ranker.vrlih.ontology_id |   65 | Using where                                  |
|  1 | SIMPLE      | lt1   | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.lt3.list_id,const                    |    1 | Using where; Using index; Not exists         |
|  1 | SIMPLE      | lbs   | eq_ref | PRIMARY,idx_list_burial_state,burial_score          | PRIMARY      | 4       | ranker.vrl.list_id                          |    1 | Using where                                  |
|  1 | SIMPLE      | lt2   | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.lt3.list_id,const                    |    1 | Using where; Using index                     |
+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+

Uma comparação da rowscoluna indica a diferença e a consulta com JOINs está usando Using temporary; Using filesort.

Obviamente, quando executo as duas consultas, a primeira é feita em 0,02 segundos, a segunda não é concluída mesmo após 1 minuto, por isso EXPLAIN explicou essas consultas corretamente.

Se eu não tiver o INNER JOIN na list_tagmesa, ou seja, se eu remover

AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=246403) IS NOT NULL  

da primeira consulta e correspondentemente:

INNER JOIN list_tag lt3 ON lt3.list_id = vrl.list_id AND lt3.tag_id = 246403

a partir da segunda consulta, EXPLAIN retorna o mesmo número de linhas para ambas as consultas e essas consultas são executadas igualmente rápido.

As subconsultas têm a capacidade de calcular funções de agregação rapidamente. Por exemplo, encontre o preço mínimo do livro e obtenha todos os livros vendidos com esse preço. 1) Usando subconsultas:

SELECT titles, price
FROM Books, Orders
WHERE price = 
(SELECT MIN(price)
 FROM Orders) AND (Books.ID=Orders.ID);

2) usando JOINs

SELECT MIN(price)
     FROM Orders;
-----------------
2.99

SELECT titles, price
FROM Books b
INNER JOIN  Orders o
ON b.ID = o.ID
WHERE o.price = 2.99;

• Uma regra geral é que as junções são mais rápidas na maioria dos casos (99%).
• Quanto mais tabelas de dados houver, as subconsultas serão mais lentas.
• Quanto menos tabelas de dados tiverem, as subconsultas terão velocidade equivalente às junções .
• As subconsultas são mais simples, mais fáceis de entender e mais fáceis de ler.
• A maioria das estruturas da Web e de aplicativos e seus "ORM" e "Registro ativo" geram consultas com subconsultas , porque com subconsultas é mais fácil dividir responsabilidades, manter código etc.
• Para sites ou aplicativos menores da web, as subconsultas são boas, mas para sites e aplicativos maiores, você precisará reescrever consultas geradas para ingressar em consultas, especialmente se uma consulta usar muitas subconsultas na consulta.

Algumas pessoas dizem que "alguns RDBMS podem reescrever uma subconsulta em uma associação ou uma associação a uma subconsulta quando achar que uma é mais rápida que a outra.", Mas essa declaração se aplica a casos simples, certamente não para consultas complicadas com subconsultas que realmente causam uma problemas no desempenho.

A diferença é vista apenas quando a segunda tabela de junção possui significativamente mais dados que a tabela principal. Eu tive uma experiência como abaixo ...

Tivemos uma tabela de usuários com cem mil entradas e seus dados de associação (amizade) com cerca de 300 mil entradas. Foi uma declaração de junção para levar os amigos e seus dados, mas com um grande atraso. Mas estava funcionando bem, onde havia apenas uma pequena quantidade de dados na tabela de associação. Depois que o alteramos para usar uma subconsulta, funcionou bem.

Entretanto, as consultas de junção estão funcionando com outras tabelas que possuem menos entradas que a tabela principal.

Então, acho que as instruções de junção e subconsulta estão funcionando bem e isso depende dos dados e da situação.

Hoje em dia, muitos dbs podem otimizar subconsultas e associações. Portanto, basta examinar sua consulta usando o Explique e veja qual é mais rápida. Se não houver muita diferença no desempenho, prefiro usar a subconsulta, pois elas são simples e fáceis de entender.

Estou apenas pensando no mesmo problema, mas estou usando subconsulta na parte FROM. Eu preciso conectar e consultar de tabelas grandes, a tabela "escrava" tem 28 milhões de registros, mas o resultado é apenas 128, portanto, resultado tão pequeno quanto o big data! Estou usando a função MAX () nele.

Primeiro estou usando LEFT JOIN porque acho que é o caminho correto, o mysql pode otimizar etc. Segunda vez apenas para teste, reescrevo para sub-selecionar contra o JOIN.

Tempo de execução LEFT JOIN: 1.12s Tempo de execução SUB-SELECT: 0.06s

A subseleção 18 vezes mais rápida que a junção! Apenas no adv chokito. A subseleção parece terrível, mas o resultado ...

Se você deseja acelerar sua consulta usando join:

Para "junção interna / junção", não use a condição where, em vez disso, use-a na condição "ON". Por exemplo:

     select id,name from table1 a  
   join table2 b on a.name=b.name
   where id='123'

 Try,

    select id,name from table1 a  
   join table2 b on a.name=b.name and a.id='123'

Para "Junção esquerda / direita", não use na condição "ATIVADO", pois se você usar a junção esquerda / direita, todas as linhas serão exibidas para qualquer tabela. Então, tente usar a condição "Onde"