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.
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”.
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).
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.