Nesta primeira aplicação, vamos construir um sistema de log de consultas MySQL lentas diretamente no WordPress.
Muitas vezes, o banco de dados degrada o desempenho do site silenciosamente.
Como especialistas seniores, não podemos depender apenas do erro_log do servidor.
Precisamos de uma interface didática que nos mostre exatamente qual hook ou plugin disparou a query pesada.
O objetivo é capturar consultas que ultrapassam um limite de tempo pré-definido e armazená-las em uma tabela de auditoria personalizada.
Isso nos permite realizar uma análise forense do banco de dados em tempo real.
Arquitetura do Banco de Dados de Auditoria
Primeiro, precisamos de uma estrutura que suporte o armazenamento de strings longas de SQL e metadados de execução.
Utilizaremos o tipo de dados LONGTEXT para garantir que consultas complexas de plugins de e-commerce não sejam cortadas.
A collation deve ser utf8mb4_unicode_520_ci para manter a consistência com o core do WordPress.
Adicionaremos índices na data e no tempo de execução para facilitar as buscas futuras.
O “porquê” desta escolha reside na necessidade de filtragem rápida por picos de tráfego.
// SQL para criação da tabela de logs
CREATE TABLE IF NOT EXISTS wp_slow_query_logs (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
query_text LONGTEXT NOT NULL,
execution_time FLOAT NOT NULL,
hook_trace TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX (execution_time),
INDEX (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;Agora, vamos criar a lógica PHP para interceptar as queries.
Utilizaremos o filtro query do objeto global $wpdb.
Este filtro é executado logo antes de cada instrução SQL ser enviada ao driver MySQL.
Mediremos o tempo de início e fim da execução usando microtime(true) para precisão decimal.
Se o tempo for superior a 0.
5 segundos, registramos no banco.
Esta sensibilidade pode ser ajustada conforme a robustez do seu servidor.
add_filter('query', function($query) {
global $wpdb;
$start_time = microtime(true);
// Execução fictícia simulada pela própria ação do core
// Aqui capturamos o tempo pós-execução via destruct ou logs de retorno
add_action('shutdown', function() use ($query, $start_time) {
$end_time = microtime(true);
$total_time = $end_time - $start_time;
if ($total_time > 0.5) {
global $wpdb;
$wpdb->insert('wp_slow_query_logs', [
'query_text' => $query,
'execution_time' => $total_time,
'hook_trace' => wp_debug_backtrace_summary()
]);
}
});
return $query;
});Didaticamente, o uso de wp_debug_backtrace_summary() é crucial aqui.
Ele nos diz qual função ou arquivo foi responsável por chamar a query lenta.
Sem essa informação, saberíamos que o banco está lento, mas não saberíamos onde corrigir no PHP.
Este é o diferencial de uma ferramenta profissional de monitoramento.
Mantenha este log limpo através de um processo de cron mensal para não sobrecarregar o storage.
A performance deve ser observada, mas a observação não deve causar lentidão.
Dashboard de Visualização Sênior
Para visualizar esses dados, criaremos uma página simples no admin do WordPress.
Utilizaremos a classe WP_List_Table para manter o padrão visual do CMS.
Isso permite que iniciantes operem a ferramenta sem estranhamento técnico.
Seniores podem usar os dados brutos para otimizar índices conforme ensinado em posts anteriores.
Otimização é um ciclo contínuo de medição, análise e ajuste.
Com esta ferramenta, o MundoPHP te dá o controle total sobre o que acontece sob o capô.
