Início / dba / Perguntas / 186207
Accepted
commonSense
Asked: 2017-09-19 04:57:53 +0800 CST

Qual consulta é otimizada

  • 772

Eu escrevi essas duas consultas para a mesma operação, com base na complexidade do tempo, quero saber qual delas é eficiente.

select Fname, Lname, Address 
from (select * from department d, employee e where d.Dnumber = e.Dno) as a 
where a.Dname = 'Research';

Editar: com base no meu primeiro comentário, suponho que a consulta na cláusula from funcionará como tabela / visualização temporária que nomeio como "a", e contém todas as colunas de ambas as tabelas e eu a uso. (e eu não não sei que é uma maneira eficiente de fazer isso.)

ou

select Fname, Lname, Address from employee 
where Dno = (select Dnumber from department where Dname = 'Research');

Ou poderia haver uma maneira mais eficiente de fazê-lo. Obrigado.

Editar2: 

SELECT Pnumber, Dnum, Lname, Address, Bdate 
FROM employee 
JOIN department d ON d.Mgr_ssn = employee.Ssn 
JOIN project p ON p.Dnum = d.Dnumber 
WHERE p.Plocation = 'Stafford';

eu tenho esse argumento, você pode me dizer qual é a falha nisso.,

vamos ter 1000 linhas em cada tabela PROJECT, DEPARTMENT, EMPLOYEE,

então na consulta acima, o compilador escolherá em qual ordem a junção deve ser aplicada (ABC, ACB,BCA, BAC,...) escolhendo a mais eficiente. Mas para selecionar o melhor de todos para o primeiro, depois para o segundo,... EMPREGADO, DEPARTAMENTO primeiro tem apenas 100-150 linhas, que depende inteiramente das tabelas...certo???). Eu nunca trabalhei em situação de projeto ao vivo, talvez haja vantagens de JOINS (que existem, por isso é em lançamento antecipado) que não consigo ver. Mas não estou convencido.

então, na consulta abaixo, deixe 250 ser sucesso, que então PRODUTO CARTESIANO com tabela DEPARTAMENTO e produz 2.50.000 tuplas das quais digamos 5.000 seja RESULTADO, que então novamente PRODUTO CARTESIANO com 1.000 tuplas para produzir 500.000.

SELECT Pnumber, Dnum, Lname, Address, Bdate 
FROM (SELECT Pnumber, Dnum, Mgr_ssn 
      FROM department d, (SELECT Pnumber, Dnum 
                          FROM project where Plocation = 'Stafford') p
      WHERE d.Dnumber = p.Dnum) q, employee e  
WHERE q.Mgr_ssn = e.Ssn;

Então, minha pergunta é JOIN é escrever a consulta de forma simples e deixar o compilador decidir qual é a ordem eficiente. Considerando que no abaixo fizemos quase o trabalho para o compilador.

e, eu tenho mais uma pergunta, a cláusula WHERE se aplica apenas a uma relação?, ou deixe-me reformular, primeiro a cláusula FROM (juntamente com todos os JOINS) execute então a cláusula where execute porque nesse caso a consulta com JOINS será muito cara .

Obrigado.

optimization mysql-5.7

1 respostas

  1. Best Answer

    Você também poderia escrever

    SELECT Fname, Lname, Address 
FROM   department
JOIN   employee 
       ON employee.dno = department.dnumber
WHERE  department.Dname = 'Research';

    que é equivalente à consulta dois e pode ser uma forma mais clara (consulte https://stackoverflow.com/questions/1599050/ansi-vs-non-ansi-sql-join-syntax para obter uma resposta que descreve por que a sintaxe mais recente é preferida ). A maioria dos otimizadores de consulta verá essa equivalência e executará as mesmas operações para uma consulta tão simples, embora para consultas mais complexas esse não seja o caso (se houver uma diferença, a JOINvariante provavelmente será a melhor das duas).

    Não que isso seja quase equivalente à parte interna de sua primeira consulta, a sintaxe de junção que você usou é a mais antiga, mas equivalente. Como você está fazendo isso na consulta interna, basta adicionar um filtro extra na externa, um bom planejador de consultas verá essas consultas como idênticas e as executará exatamente da mesma maneira. Um planejador de consulta ruim fará com que o mecanismo execute a consulta interna primeiro e, em seguida, aplique a cláusula de filtragem extra, tornando-a muito menos eficiente, dependendo de quais índices estão presentes para uso.

    Mas tudo isso depende de algumas coisas que você deve editar sua pergunta e tags para fornecer:

    1. O banco de dados que você está usando como planejadores de consulta diferentes pode não otimizar da mesma maneira para uma determinada consulta (adicione o banco de dados e a versão às tags).
      Além disso, a maioria dos mecanismos de banco de dados fornece uma maneira de ler o que o planejador de consultas provavelmente fará para uma determinada consulta, o que será útil para julgar qual opção é a mais ideal - não listarei como fazer isso em todos os bancos de dados que conheço, seja específicos sobre os bancos de dados com os quais você está trabalhando e podemos ser mais específicos e relevantes sobre as respostas que damos.
    2. Os índices presentes nas tabelas relevantes (adicione o índice e as definições de chave ao texto da pergunta)

    Observe que, se você executar a segunda consulta e houver duas linhas em departmentque name='Research'provavelmente receberá um erro, pois o =operador só pode trabalhar em um valor de cada lado. Para listar pessoas em todos os departamentos com esse nome, use IN. Isso pode alterar a resposta para qual é mais eficiente.

    • 0

relate perguntas