Se você esta querendo saber qual script SQL o sistema está gerando para suas consultas, então imagino que você esta tendo problemas com os resultados apresentados, certo?!
Isso pode ocorrer por diversas razões, desde a instalação de algum módulo, plugin que intercepta dados, tema customizado, cache, etc.
Então vamos capturar toda consulta SQL gerada pelo sistema para descartarmos a possibilidade do problema ser o banco de dados.
Habilitando o Log de Querys
Na versão 2.4.1 do M2 que estou rodando aqui, é possível habilitar um recurso para capturar todo comando SQL e armazenar em um arquivo de log. Basta abrir o CLI (prompt de comando do seu sistema operacional), navegar até o diretório de instalação da sua loja, e digitar:
bin/magento dev:query-log:enable
Aqui, eu apertei ENTER e já passou a funcionar de imediato, algumas pessoas relatam que foi preciso dar flush e atualizar caches.
![](https://i0.wp.com/mariosam.com.br/wp-content/uploads/2021/03/sql-log-enable-m2.png?resize=529%2C33&ssl=1)
Obviamente, para desativar esse recurso basta digitar:
bin/magento dev:query-log:disable
O Armazenamento
Como dito anteriormente, na versão 2.4.1 testada aqui, os arquivos de log foram gerados no diretório/arquivo:
<sua instalacao>/var/debug/db.log
Mas, a depender da versão/configuração que você utiliza, o arquivo de log pode surgir no diretório var/log.
O que capturamos?
Vamos dar uma olhada em coisas que você pode encontrar neste arquivo de log. Para o teste, eu executei uma pesquisa rápido com o termo “black piano”.
![](https://i0.wp.com/mariosam.com.br/wp-content/uploads/2021/03/busca-black-piano-m2.png?resize=704%2C386&ssl=1)
Ao abrir o arquivo, podemos observar dezenas de consultas, pois para renderizar a página foi necessário consultar as configurações do tema, construção do menu, informações de conta do usuário (logado ou não), além claro, da nossa consulta (pesquisa).
![](https://i0.wp.com/mariosam.com.br/wp-content/uploads/2021/03/log-black-piano-m2.png?resize=810%2C171&ssl=1)
Se buscarmos pelo termo dentro do arquivo de log, vamos notar que ele se repete centena de vezes (102 resultados). Isso porque o arquivo não armazena apenas o SQL, mas toda cadeia de processos até a classe que dispara a consulta, e nesse encadeamento. o termo “black piano” é passado como parâmetro.
Vamos encontrar até INSERT nos scripts, pois o sistema armazena todas as consultas já realizadas (para o relatório de termos mais pesquisados).
Para encontrar apenas as consultas, experimente buscar pelo termo:
query_text = 'black piano'
Com isso reduzimos para quatro resultados.
SELECT COUNT(*) FROM (SELECT DISTINCT `main_table`.`query_text` FROM `search_query` AS `main_table` WHERE (main_table.store_id IN (1)) AND (num_results > 0) ORDER BY `popularity` desc
LIMIT 100) AS `result` WHERE (result.query_text = 'black piano')
Esse contador provavelmente serve para mostrar a quantidade de resultados encontrados, tanto no auto-completar do campo busca, como na página de resultados da pesquisa (resultados encontrados).
SELECT `search_query`.* FROM `search_query` WHERE (query_text = 'black piano') AND (store_id = '1') LIMIT 1
E temos a busca pelo termo, que provavelmente também precisa buscar os termos relacionados à ele, gerando outra consulta semelhante.
Isso é o suficiente!?
Não. Neste exemplo, estamos rodando o elasticsearch, e isso pode gerar um comportamento diferente nos resultados. O ideal seria fazer um teste paralelo com MySQL (sem elasticsearch). Mas eu não fiz. :S
Agora com o SQL em mãos, podemos abrir um SGBD, como o MySQL Workbench ou o Sequel Pro, para testarmos diretamente no banco de dados as consultas (isso claro, se você entende de SQL).
Dessa forma podemos identificar se o problema está na geração da query, ou se os dados estão sendo manipulados e modificados após a consulta. Logo, isso não resolve o problema, mas nos ajuda a eliminar possibilidades.
Sucesso!
Você precisa fazer login para comentar.