{"id":21379,"date":"2026-09-14T08:34:50","date_gmt":"2026-09-14T06:34:50","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-query-response-time-plugin-database-monitoring-analyse-focus\/"},"modified":"2026-09-14T08:34:50","modified_gmt":"2026-09-14T06:34:50","slug":"mariadb-tempo-de-resposta-das-consultas-plugin-monitorizacao-de-bases-de-dados-analise-foco","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/mariadb-query-response-time-plugin-database-monitoring-analyse-focus\/","title":{"rendered":"Utilizar o plugin de tempo de resposta de consultas do MariaDB para uma monitoriza\u00e7\u00e3o eficiente do desempenho"},"content":{"rendered":"<p>Utilizo o plugin MariaDB Query Response Time para <strong>resposta \u00e0 consulta<\/strong> Tornar vis\u00edveis as m\u00e9tricas por intervalo e identificar rapidamente os pontos de estrangulamento. Assim, consigo ver em segundos se as consultas est\u00e3o a acumular-se num \u00abbucket\u00bb lento e, a partir da\u00ed, tomo as medidas necess\u00e1rias <strong>Otimiza\u00e7\u00f5es<\/strong> para o meu acompanhamento.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Antes de entrar em pormenores, vou resumir sucintamente os aspetos mais importantes, para que possas orientar-te claramente nos pr\u00f3ximos passos. Vou concentrar-me nos benef\u00edcios, na ativa\u00e7\u00e3o, na avalia\u00e7\u00e3o e na integra\u00e7\u00e3o com ferramentas existentes, pois \u00e9 precisamente a\u00ed que reside o maior fator de influ\u00eancia para um melhor desempenho. Os pontos-chave que se seguem fornecem-te as orienta\u00e7\u00f5es para a implementa\u00e7\u00e3o t\u00e9cnica e o trabalho di\u00e1rio com o plugin. S\u00e3o \u00fateis como lembrete para tarefas recorrentes. Com esta vis\u00e3o geral concisa, mantenho a minha <strong>Prioridades<\/strong> em vista e garanto a mim pr\u00f3prio uma <strong>Resultados<\/strong>.<\/p>\n<ul>\n  <li><strong>Histograma<\/strong> Em vez da m\u00e9dia: a distribui\u00e7\u00e3o dos tempos de execu\u00e7\u00e3o revela claramente valores at\u00edpicos.<\/li>\n  <li>Simples <strong>Ativa\u00e7\u00e3o<\/strong>: dinamicamente atrav\u00e9s do INSTALL ou estaticamente atrav\u00e9s da configura\u00e7\u00e3o.<\/li>\n  <li>R\u00e1pido <strong>An\u00e1lises<\/strong>: SHOW\/FLUSH para janelas de medi\u00e7\u00e3o e compara\u00e7\u00f5es.<\/li>\n  <li>Sem costuras <strong>Integra\u00e7\u00e3o<\/strong>: Dados dispon\u00edveis nos pain\u00e9is e alertas.<\/li>\n  <li>Limpo <strong>Defini\u00e7\u00e3o de prioridades<\/strong>: A percentagem de consultas lentas \u00e9 vis\u00edvel de imediato.<\/li>\n<\/ul>\n\n<h2>Princ\u00edpio b\u00e1sico e arquitetura<\/h2>\n\n<p>O plugin regista o tempo de execu\u00e7\u00e3o de cada consulta e distribui-o por buckets, que funcionam como um <strong>Histograma<\/strong> funciona. Analiso esta distribui\u00e7\u00e3o e percebo imediatamente se h\u00e1 muitas instru\u00e7\u00f5es com tempos inferiores a 1 ms ou se os intervalos de segundos est\u00e3o a aumentar. Dois componentes sustentam este conceito: uma parte de auditoria, que efetua medi\u00e7\u00f5es durante a execu\u00e7\u00e3o, e uma parte do INFORMATION_SCHEMA, que torna os dados acess\u00edveis. Desta forma, obtenho n\u00e3o s\u00f3 valores m\u00e9dios, mas tamb\u00e9m uma verdadeira <strong>Distribui\u00e7\u00e3o<\/strong> em todas as classes temporais. \u00c9 precisamente esta vis\u00e3o que me ajuda a distinguir os valores at\u00edpicos espor\u00e1dicos dos problemas sistem\u00e1ticos e a planear medidas de forma espec\u00edfica.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-performance-monitoring-8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ativa\u00e7\u00e3o: din\u00e2mica e est\u00e1tica<\/h2>\n\n<p>Eu ativo o <strong>Plugin<\/strong> Durante o funcionamento, utilizo o comando INSTALL SONAME\/INSTALL PLUGIN e, em seguida, defino query_response_time_stats como ON. Estes passos iniciam imediatamente a recolha de dados, sem necessidade de reiniciar o servidor. Em alternativa, adiciono plugin_load_add \u00e0 configura\u00e7\u00e3o, para que o MariaDB carregue o m\u00f3dulo no arranque. Em configura\u00e7\u00f5es de cluster, mantenho a defini\u00e7\u00e3o consistente em todos os n\u00f3s relevantes, para que o meu <strong>Valores medidos<\/strong> permanecerem compar\u00e1veis. Desta forma, garanto a continuidade dos dados, que mantenho coerentes entre si nos ambientes de teste, staging e produ\u00e7\u00e3o.<\/p>\n\n<h2>Compreender os dados: histograma dos tempos de execu\u00e7\u00e3o<\/h2>\n\n<p>Consulto a distribui\u00e7\u00e3o atrav\u00e9s de INFORMATION_SCHEMA.QUERY_RESPONSE_TIME ou atrav\u00e9s de SHOW QUERY_RESPONSE_TIME e analiso os <strong>Baldes<\/strong> . Cada linha descreve um limite de tempo m\u00e1ximo, o n\u00famero de consultas e o tempo de execu\u00e7\u00e3o total nesse intervalo. Assim, consigo perceber qual \u00e9 a carga em intervalos de milissegundos e onde existem riscos de picos de segundos. Verifico regularmente como a <strong>Distribui\u00e7\u00e3o<\/strong> ap\u00f3s altera\u00e7\u00f5es nos \u00edndices, nas caches ou nas configura\u00e7\u00f5es. Este procedimento evita que valores m\u00e9dios isolados ocultem problemas reais de lat\u00eancia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_performance_meeting_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utilizar o SHOW e o FLUSH de forma eficaz<\/h2>\n\n<p>Inicio novas janelas de medi\u00e7\u00e3o com o comando FLUSH QUERY_RESPONSE_TIME, para poder fazer compara\u00e7\u00f5es \u00abantes e depois\u00bb de forma precisa. Depois, leio a distribui\u00e7\u00e3o atual com o comando SHOW QUERY_RESPONSE_TIME e verifico se o n\u00famero de buckets r\u00e1pidos est\u00e1 a aumentar. Especialmente nos testes de lan\u00e7amento, isto d\u00e1-me, em poucos minutos, uma imagem clara sobre se as altera\u00e7\u00f5es nas consultas est\u00e3o a surtir efeito. Combino o FLUSH com tarefas recorrentes que recolhem os dados e os armazenam centralmente. Assim, mantenho a minha <strong>Tend\u00eancias<\/strong> de olho e a reconhecer os sinais sutis <strong>Deteriora\u00e7\u00f5es<\/strong> atempadamente.<\/p>\n\n<h2>Integra\u00e7\u00e3o em ferramentas de monitoriza\u00e7\u00e3o<\/h2>\n\n<p>Incluo as distribui\u00e7\u00f5es nos pain\u00e9is e combino-as com m\u00e9tricas de CPU, E\/S e bloqueios. Para an\u00e1lises mais aprofundadas, recorro tamb\u00e9m a <a href=\"https:\/\/webhosting.de\/pt\/ferramenta-de-monitorizacao-do-mysql-performance-schema\/\">Monitoriza\u00e7\u00e3o do esquema de desempenho<\/a>, para ver em detalhe as esperas e as fases. Esta combina\u00e7\u00e3o permite-me perceber se as lat\u00eancias elevadas se devem ao armazenamento, aos bloqueios ou a planos ineficientes. Configurei os alertas de forma a que uma determinada percentagem tenha de entrar em intervalos lentos antes de receber uma notifica\u00e7\u00e3o. Isso reduz <strong>Ru\u00eddo<\/strong> e concentra a minha <strong>Rea\u00e7\u00e3o<\/strong> a problemas reais.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-monitoring-efficiency-4278.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Situa\u00e7\u00f5es do dia-a-dia e passos pr\u00e1ticos<\/h2>\n\n<p>Ap\u00f3s uma atualiza\u00e7\u00e3o, verifico primeiro a distribui\u00e7\u00e3o para ver se grande parte da carga ficou mais lenta. Se forem detetados novos picos na ordem dos segundos, inicio uma an\u00e1lise detalhada e espec\u00edfica das cargas de trabalho afetadas. Ao otimizar os \u00edndices, limpo as estat\u00edsticas, simulo carga e verifico se a propor\u00e7\u00e3o de buckets mais r\u00e1pidos aumenta. No caso de planos de consulta complexos, analiso tamb\u00e9m o <a href=\"https:\/\/webhosting.de\/pt\/mariadb-otimizador-rastreio-analise-de-desempenho-sql-base-de-dados\/\">Tra\u00e7o do optimizador<\/a>, para compreender as decis\u00f5es relativas ao plano. \u00c9 assim que eu relaciono <strong>Visibilidade<\/strong> da distribui\u00e7\u00e3o, com an\u00e1lise das causas, sobre <strong>Declara\u00e7\u00e3o<\/strong>-n\u00edvel.<\/p>\n\n<h2>Melhores pr\u00e1ticas para resultados mensur\u00e1veis<\/h2>\n\n<p>Defino intervalos de medi\u00e7\u00e3o fixos, por exemplo, diariamente com um FLUSH noturno, para poder comparar as tend\u00eancias de forma fi\u00e1vel. Al\u00e9m disso, disponho de medi\u00e7\u00f5es pontuais antes e depois das altera\u00e7\u00f5es, para poder avaliar os efeitos diretamente. Em sistemas com elevada carga, verifico o <strong>Despesas gerais<\/strong> em suma, o que, na pr\u00e1tica, costuma ser moderado. Integro a an\u00e1lise de forma automatizada, exporto os buckets e arquivo-os com base em intervalos de tempo. Esta rotina permite <strong>Transpar\u00eancia<\/strong> e poupa-me tempo nas auditorias ou nas an\u00e1lises p\u00f3s-incidente.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_monitoring_nacht_5782.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resolver rapidamente as fontes de erro<\/h2>\n\n<p>Se faltar o SHOW ou a tabela, verifico primeiro se consigo o <strong>Plugin<\/strong> carreguei corretamente. Em seguida, verifico o `query_response_time_stats`; se estiver definido como `OFF`, o MariaDB n\u00e3o recolhe dados. Se faltarem direitos, ajusto os privil\u00e9gios para a instala\u00e7\u00e3o ou para o flushing. Em caso de diferen\u00e7as entre vers\u00f5es, comparo as variantes de sintaxe de INSTALL SONAME e INSTALL PLUGIN, para evitar conflitos. Al\u00e9m disso, mantenho o meu <strong>Documenta\u00e7\u00e3o<\/strong> atualizado, para que as verifica\u00e7\u00f5es recorrentes sejam r\u00e1pidas.<\/p>\n\n<h2>Comparar m\u00e9tricas: tabela<\/h2>\n\n<p>Utilizo este plugin em conjunto com o Slow Query Log e o Performance Schema, porque cada uma destas fontes oferece uma perspetiva diferente. A tabela seguinte ajuda-me a tirar partido dos pontos fortes de cada uma de forma espec\u00edfica e a evitar expectativas erradas. Para registos detalhados, consulto o meu <a href=\"https:\/\/webhosting.de\/pt\/mysql-slow-query-log-hosting-analyse-queryperf\/\">An\u00e1lise do registo de consultas lentas<\/a>, enquanto utilizo a distribui\u00e7\u00e3o por categorias para definir prioridades. Desta forma, na fase de planeamento, reduzo os pontos cegos e identifico padr\u00f5es mais cedo. Isso leva a <strong>claro<\/strong> Decis\u00f5es e maior rapidez <strong>Itera\u00e7\u00f5es<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Carater\u00edstica<\/th>\n      <th>Plugin de Tempo de Resposta das Consultas<\/th>\n      <th>Registo de consultas lentas<\/th>\n      <th>Regime de desempenho<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Granularidade<\/td>\n      <td>Distribui\u00e7\u00e3o por <strong>Baldes<\/strong> (Histograma)<\/td>\n      <td>Algumas lentas <strong>Declara\u00e7\u00f5es<\/strong><\/td>\n      <td>Waits\/Stages\/Locks de granularidade fina<\/td>\n    <\/tr>\n    <tr>\n      <td>Fonte de dados<\/td>\n      <td>ESQUEMA_DE_INFORMA\u00c7\u00c3O\/MOSTRAR<\/td>\n      <td>Ficheiro de registo ou tabela<\/td>\n      <td>Vis\u00f5es internas de desempenho<\/td>\n    <\/tr>\n    <tr>\n      <td>Adequa\u00e7\u00e3o<\/td>\n      <td>Vis\u00e3o geral, tend\u00eancias, alertas<\/td>\n      <td>Causas ao n\u00edvel das instru\u00e7\u00f5es<\/td>\n      <td>An\u00e1lise aprofundada das causas<\/td>\n    <\/tr>\n    <tr>\n      <td>Despesas gerais<\/td>\n      <td>Baixo, facilmente control\u00e1vel<\/td>\n      <td>Valores, consoante os limiares<\/td>\n      <td>Vari\u00e1vel, dependendo da ativa\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>Reiniciar<\/td>\n      <td>FLUSH QUERY_RESPONSE_TIME<\/td>\n      <td>Rota\u00e7\u00e3o de registos\/Truncate<\/td>\n      <td>Espec\u00edfico do contexto<\/td>\n    <\/tr>\n    <tr>\n      <td>Excedentes<\/td>\n      <td>Distribui\u00e7\u00e3o percentual vis\u00edvel<\/td>\n      <td>\u00c9 poss\u00edvel distinguir pontas isoladas<\/td>\n      <td>Causas da espera identific\u00e1veis<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_plugin_desk_9123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Papel na monitoriza\u00e7\u00e3o integral<\/h2>\n\n<p>Utilizo a distribui\u00e7\u00e3o por categorias como indicador central nos meus pain\u00e9is de controlo, porque reflete a percep\u00e7\u00e3o <strong>Lat\u00eancia<\/strong> que reflita bem a experi\u00eancia do utilizador. Se a percentagem de buckets mais lentos aumentar, intensifico a urg\u00eancia da minha an\u00e1lise. A correla\u00e7\u00e3o com as m\u00e9tricas do sistema indica-me se devo abordar a CPU, a RAM, a E\/S ou os bloqueios. Verifico tamb\u00e9m se as estrat\u00e9gias de cache est\u00e3o a funcionar ou se um aumento de dados torna necess\u00e1ria a cria\u00e7\u00e3o de novos \u00edndices. A partir desta vis\u00e3o global, deduzo medidas concretas <strong>Ac\u00e7\u00f5es<\/strong> em vez de me perder nos pormenores.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-monitoring-5289.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Personalizar o design do balde de forma espec\u00edfica<\/h2>\n\n<p>Adapto a resolu\u00e7\u00e3o dos buckets \u00e0s minhas cargas de trabalho. Se me faltar detalhe na escala de submilissegundos, aumentei a resolu\u00e7\u00e3o nessa \u00e1rea. Se as consultas forem medidas mais em segundos, alargo as classes superiores. O importante \u00e9 o compromisso: um maior n\u00famero de buckets proporciona uma resolu\u00e7\u00e3o mais precisa <strong>Conhecimentos<\/strong>, mas aumentam ligeiramente a sobrecarga de medi\u00e7\u00e3o e o volume de dados para exporta\u00e7\u00e3o. Verifico as minhas vari\u00e1veis ativas com SHOW VARIABLES LIKE \u201aquery_response_time%\u2018; e documento a escolha para cada ambiente. Implemento as altera\u00e7\u00f5es de forma coordenada, para que as s\u00e9ries temporais entre n\u00f3s e ambientes continuem a ser compar\u00e1veis. Inicio sempre as altera\u00e7\u00f5es de configura\u00e7\u00e3o com um FLUSH espec\u00edfico, para observar o efeito da nova resolu\u00e7\u00e3o numa janela de medi\u00e7\u00e3o renovada.<\/p>\n\n<p>Na pr\u00e1tica, tenho sempre em conta as seguintes quest\u00f5es-chave: a escala de buckets abrange os meus SLOs (por exemplo, 95% abaixo dos 100 ms)? Consigo identificar as classes com valores at\u00edpicos com suficiente clareza? As agrega\u00e7\u00f5es para os pain\u00e9is de controlo s\u00e3o est\u00e1veis (sem mudan\u00e7as frequentes de escala)? \u00c9 assim que garanto que o histograma apoia as decis\u00f5es e n\u00e3o \u00e9 apenas um \u201cextra\u201d opcional.<\/p>\n\n<h2>Calcular percentis a partir de intervalos<\/h2>\n\n<p>Calculo os valores p90\/p95\/p99 a partir da distribui\u00e7\u00e3o do histograma, sem registar cada instru\u00e7\u00e3o. Para tal, acumulo os valores de contagem dos intervalos por ordem crescente, at\u00e9 atingir a percentagem pretendida. Utilizo o limite do intervalo correspondente como uma estimativa conservadora do percentil. Isso \u00e9 suficiente para o monitoriza\u00e7\u00e3o do SLO e <strong>Alertas<\/strong>. Acrescento: em caso de grande concentra\u00e7\u00e3o na borda do bucket, defino limites mais restritos ou classes adicionais, para que os percentis n\u00e3o \u201cd\u00eaem saltos\u201d. Este m\u00e9todo \u00e9 robusto, r\u00e1pido e quase n\u00e3o sobrecarrega o servidor \u2013 ideal para monitoriza\u00e7\u00e3o cont\u00ednua.<\/p>\n\n<p>Para c\u00e1lculos ad hoc, utilizo vari\u00e1veis SQL simples para calcular somas cumulativas sobre o INFORMATION_SCHEMA.QUERY_RESPONSE_TIME. Em ambientes de produ\u00e7\u00e3o, calculo os percentis no meu sistema de m\u00e9tricas depois de exportar os intervalos, para poder realizar an\u00e1lises hist\u00f3ricas e comparativas.<\/p>\n\n<h2>Replica\u00e7\u00e3o, Galera e alta disponibilidade<\/h2>\n\n<p>Na rede de replica\u00e7\u00e3o, os histogramas s\u00e3o <strong>espec\u00edfico do n\u00f3<\/strong>. Isto \u00e9 intencional, uma vez que as cargas de trabalho nos n\u00f3s prim\u00e1rios e secund\u00e1rios s\u00e3o diferentes (carga de escrita vs. carga de leitura). No entanto, mantenho a configura\u00e7\u00e3o do plugin id\u00eantica, para poder atribuir as diferen\u00e7as de forma clara. Nas configura\u00e7\u00f5es do Galera, a distribui\u00e7\u00e3o por buckets por n\u00f3 ajuda-me a identificar pontos de congestionamento nos clusters de leitura e a ajustar o balanceamento de carga. Ap\u00f3s as mudan\u00e7as de configura\u00e7\u00e3o, replaneio os intervalos de medi\u00e7\u00e3o e assinalo-os nos meus pain\u00e9is de controlo, para poder interpretar corretamente as varia\u00e7\u00f5es. Importante: os contadores s\u00e3o vol\u00e1teis; ap\u00f3s reinicializa\u00e7\u00f5es, come\u00e7o deliberadamente com um novo intervalo, mas exporto os \u00faltimos valores antes das janelas de manuten\u00e7\u00e3o, para minimizar quebras na s\u00e9rie temporal.<\/p>\n\n<h2>Exporta\u00e7\u00e3o autom\u00e1tica e gest\u00e3o de dados<\/h2>\n\n<p>Para an\u00e1lises de tend\u00eancias e auditorias, exporto os buckets regularmente. Prefiro a consulta a partir do INFORMATION_SCHEMA, porque \u00e9 leg\u00edvel por m\u00e1quina. A tarefa grava o timestamp, o n\u00f3, o ambiente e todos os buckets num pipeline de m\u00e9tricas ou numa tabela pr\u00f3pria. Fa\u00e7o a reinicializa\u00e7\u00e3o de forma deliberada: Ou esvazio os buckets ap\u00f3s a exporta\u00e7\u00e3o (an\u00e1lise de janela rolante), ou acumulo os dados e calculo as diferen\u00e7as externamente (modelo de contador). Ambas as variantes t\u00eam a sua utilidade \u2013 o importante \u00e9 optar por uma abordagem por painel, para que os alarmes se mantenham consistentes.<\/p>\n\n<p>Para verifica\u00e7\u00f5es r\u00e1pidas em ambientes de teste, recorro a exporta\u00e7\u00f5es simples em CSV e analiso-as com ferramentas padr\u00e3o. Em produ\u00e7\u00e3o, dou prioridade a um processo de exporta\u00e7\u00e3o simplificado e repet\u00edvel, com um tratamento de erros claro, para n\u00e3o perder nenhuma janela de medi\u00e7\u00e3o.<\/p>\n\n<h2>Seguran\u00e7a, direitos e governa\u00e7\u00e3o<\/h2>\n\n<p>Para INSTALL\/UNINSTALL do plugin, preciso dos privil\u00e9gios adequados (por exemplo, INSTALL PLUGIN ou direitos administrativos). Para executar o comando \u00abFLUSH QUERY_RESPONSE_TIME\u00bb, tamb\u00e9m s\u00e3o necess\u00e1rios direitos elevados. Considero que a leitura dos dados deve ser t\u00e3o restritiva quanto razo\u00e1vel, uma vez que mesmo as m\u00e9tricas podem permitir tirar conclus\u00f5es sobre as cargas de trabalho. Em ambientes regulamentados, registo as altera\u00e7\u00f5es ao estado e \u00e0 configura\u00e7\u00e3o do plugin. Defino quem pode iniciar janelas de medi\u00e7\u00e3o e indico nos pain\u00e9is de controlo quando e por quem foi executado um FLUSH. Desta forma, as an\u00e1lises permanecem rastre\u00e1veis e adequadas para auditorias.<\/p>\n\n<h2>Limites e delimita\u00e7\u00e3o<\/h2>\n\n<p>O plugin mede a <strong>Do lado do servidor<\/strong> Tempo de execu\u00e7\u00e3o \u2013 a lat\u00eancia da rede e as tentativas de repeti\u00e7\u00e3o do cliente n\u00e3o s\u00e3o tidas em conta. O texto da consulta, o utilizador, o esquema ou a origem n\u00e3o s\u00e3o registados; para isso, utilizo adicionalmente o Slow Query Log e o Performance Schema. N\u00e3o h\u00e1 persist\u00eancia: ap\u00f3s o rein\u00edcio, os contadores ficam a zero, pelo que fa\u00e7o exporta\u00e7\u00f5es regulares. O plugin n\u00e3o oferece uma filtragem granular (por exemplo, apenas SELECT); resolvo isso operacionalmente atrav\u00e9s de janelas de medi\u00e7\u00e3o durante cargas espec\u00edficas ou correlacionando buckets com registos. Em caso de QPS muito elevados, verifico rapidamente a sobrecarga atrav\u00e9s de medi\u00e7\u00f5es A\/B; na pr\u00e1tica, esta \u00e9 reduzida, mas nunca fa\u00e7o medi\u00e7\u00f5es \u201c\u00e0s cegas\u201d.<\/p>\n\n<h2>Diagn\u00f3stico aprofundado: obst\u00e1culos t\u00edpicos<\/h2>\n\n<p>Se n\u00e3o existir o comando SHOW QUERY_RESPONSE_TIME, verifico se o nome do plugin est\u00e1 correto e se o m\u00f3dulo se encontra no diret\u00f3rio plugin_dir. Verifico os m\u00f3dulos carregados com o comando SHOW PLUGINS e comparo os caminhos. Se a sintaxe diferir entre vers\u00f5es, recorro \u00e0 forma alternativa do comando INSTALL (com SONAME) e anoto a variante que funciona na documenta\u00e7\u00e3o interna. Se os valores no INFORMATION_SCHEMA n\u00e3o corresponderem aos do comando SHOW, isso deve-se, na maioria das vezes, a um FLUSH intercalar ou a um conflito de janelas de medi\u00e7\u00e3o \u2013 repito a medi\u00e7\u00e3o de forma estruturada. Se ocorrerem erros de direitos de acesso durante o FLUSH, verifico privil\u00e9gios espec\u00edficos em vez de atribuir SUPER de forma gen\u00e9rica.<\/p>\n\n<h2>Pain\u00e9is de controlo e alertas que realmente ajudam<\/h2>\n\n<p>Visualizo os buckets de forma cumulativa e em percentagens, e n\u00e3o apenas em valores absolutos. Desta forma, as varia\u00e7\u00f5es na carga (maior n\u00famero total de pedidos) de <strong>Deslocamentos de lat\u00eancia<\/strong> desacopladas. Formulo os alertas em linguagem empresarial: \u201c&gt;5% das consultas com dura\u00e7\u00e3o superior a 500 ms durante 10 minutos\u201d em vez de \u201cm\u00e9dia &gt; 120 ms\u201d. Al\u00e9m disso, utilizo alertas de tend\u00eancia (propor\u00e7\u00e3o crescente de lentid\u00e3o) e estabilizadores (histerese) para evitar o ru\u00eddo de alarmes. Em ambientes com v\u00e1rios n\u00f3s, agrupo os dados por fun\u00e7\u00e3o (Writer\/Reader) e apresento adicionalmente os principais respons\u00e1veis a partir do esquema de registos\/desempenho, para que a escala\u00e7\u00e3o possa ser feita diretamente com um <strong>Plano de a\u00e7\u00e3o<\/strong> inicia.<\/p>\n\n<h2>Testes metodol\u00f3gicos e medi\u00e7\u00e3o do overhead<\/h2>\n\n<p>Verifico sistematicamente a sobrecarga: um cen\u00e1rio de carga curto sem o plugin, depois com o plugin carregado e, por fim, com as estat\u00edsticas ativas. Medei o d\u00e9bito, a utiliza\u00e7\u00e3o da CPU e a distribui\u00e7\u00e3o da lat\u00eancia. Repito o mesmo processo com uma resolu\u00e7\u00e3o de bucket diferente. Documento os resultados para a minha pr\u00f3pria plataforma, em vez de me basear em afirma\u00e7\u00f5es gerais. Desta forma, posso aprovar o plugin mesmo em sistemas rigorosamente regulamentados. No caso de funcionalidades de que s\u00f3 necessito pontualmente (por exemplo, buckets mais restritos na ordem de sub-ms), limito a sua utiliza\u00e7\u00e3o a intervalos de medi\u00e7\u00e3o curtos e claramente definidos.<\/p>\n\n<h2>Guia pr\u00e1tico para altera\u00e7\u00f5es<\/h2>\n\n<p>Antes de uma altera\u00e7\u00e3o estrutural (\u00edndice, par\u00e2metro, implementa\u00e7\u00e3o), esvazio a cache, defino um intervalo de tempo e registo, em paralelo, as m\u00e9tricas do sistema. Ap\u00f3s a altera\u00e7\u00e3o, repito exatamente o mesmo processo. O essencial \u00e9 a <strong>Simetria<\/strong> da medi\u00e7\u00e3o: carga id\u00eantica, per\u00edodo igual, agrega\u00e7\u00e3o igual. Comparo as percentagens por intervalo e avalio-as em rela\u00e7\u00e3o aos meus SLOs. S\u00f3 quando os intervalos r\u00e1pidos aumentam significativamente ou os lentos diminuem \u00e9 que considero a medida um sucesso. Se a distribui\u00e7\u00e3o permanecer inalterada, recorro a ferramentas mais avan\u00e7adas (Optimizer Trace, Performance Schema) ou ajusto a minha hip\u00f3tese.<\/p>\n\n<h2>Resumo: Respostas claras mais rapidamente<\/h2>\n\n<p>Com o plugin \u00abQuery Response Time\u00bb, consigo obter rapidamente uma vis\u00e3o clara da distribui\u00e7\u00e3o dos tempos de resposta das consultas. Ativo o <strong>M\u00f3dulo<\/strong> De forma direcionada, limpa as janelas de medi\u00e7\u00e3o e compara a evolu\u00e7\u00e3o antes e depois das altera\u00e7\u00f5es. A combina\u00e7\u00e3o com o Slow Query Log, o Performance Schema e, se necess\u00e1rio, as an\u00e1lises do otimizador permite identificar todas as causas. No dia-a-dia, concentro-me nos buckets que est\u00e3o a ficar sobrecarregados e, a partir da\u00ed, deduzo medidas concretas <strong>Medidas<\/strong> . Desta forma, garanto uma experi\u00eancia de utilizador r\u00e1pida e mantenho os custos da minha base de dados sob controlo.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprenda a utilizar o plugin MariaDB Query Response Time para uma monitoriza\u00e7\u00e3o precisa da base de dados, a analisar os tempos de resposta das consultas e a detetar atempadamente problemas de desempenho.<\/p>","protected":false},"author":1,"featured_media":21372,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21379","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"83","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"query response","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21372","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21379","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21379"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21379\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21372"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21379"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21379"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21379"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}