{"id":16878,"date":"2026-01-16T18:23:13","date_gmt":"2026-01-16T17:23:13","guid":{"rendered":"https:\/\/webhosting.de\/wordpress-wordpress-datenbank-indizes-leistung-boost-optimiert\/"},"modified":"2026-01-16T18:23:13","modified_gmt":"2026-01-16T17:23:13","slug":"wordpress-base-de-dados-wordpress-indices-desempenho-optimizado","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/wordpress-wordpress-datenbank-indizes-leistung-boost-optimiert\/","title":{"rendered":"WordPress e \u00edndices de bases de dados: Quando ajudam e quando n\u00e3o ajudam"},"content":{"rendered":"<p>Eu mostro quando <strong>\u00cdndices de bases de dados<\/strong> As consultas do WordPress s\u00e3o visivelmente mais r\u00e1pidas e em que cen\u00e1rios degradam o desempenho. Utilizo regras claras do MySQL, tabelas t\u00edpicas do WP e verifica\u00e7\u00f5es testadas e comprovadas para decidir se um \u00edndice \u00e9 adequado ou se \u00e9 melhor <strong>Alternativas<\/strong> ajudar.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Antes de ajustar a base de dados, defino claramente <strong>Objectivos<\/strong> e medir os valores reais. Dou prioridade \u00e0s consultas de leitura intensiva, porque \u00e9 aqui que os \u00edndices fornecem o maior valor. <strong>Efeito<\/strong>. Trato as tabelas de escrita intensiva com cuidado porque cada \u00edndice adicional torna as opera\u00e7\u00f5es de inser\u00e7\u00e3o e atualiza\u00e7\u00e3o mais lentas. Muitas vezes, deixo as tabelas pequenas inalteradas, uma vez que a sua digitaliza\u00e7\u00e3o \u00e9 mais r\u00e1pida do que verificar um \u00edndice <strong>\u00cdndice<\/strong>. E combino \u00edndices com caching para otimizar de forma sustent\u00e1vel o acesso aos dados. <strong>baixar<\/strong>.<\/p>\n<ul>\n  <li><strong>Carga de leitura<\/strong> priorizar: WHERE, JOIN, ORDER BY prioritise<\/li>\n  <li><strong>Seletividade<\/strong> verifica\u00e7\u00e3o: poucos valores duplicados valem a pena<\/li>\n  <li><strong>Despesas gerais<\/strong> Nota: A escrita torna-se mais lenta<\/li>\n  <li><strong>wp_postmeta<\/strong> e tratar especificamente wp_options<\/li>\n  <li><strong>EXPLICAR<\/strong> Utilizar e medir em vez de adivinhar<\/li>\n<\/ul>\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\/01\/wordpress-datenbank-indexe-9381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como funcionam os \u00edndices no MySQL e no WordPress<\/h2>\n<p>Um \u00edndice funciona como um <strong>\u00cdndice<\/strong>Em vez de verificar cada linha, o MySQL salta diretamente para o intervalo apropriado. Os \u00edndices de \u00e1rvore B cobrem a maioria dos casos do WordPress porque tornam a ordena\u00e7\u00e3o, os filtros de intervalo e os JOINs muito f\u00e1ceis. <strong>bom<\/strong> suporte. Os \u00edndices de hash aceleram as compara\u00e7\u00f5es exactas, mas n\u00e3o s\u00e3o adequados para intervalos ou consultas LIKE, que vejo frequentemente nas pesquisas. Os \u00edndices de texto completo indexam palavras e aceleram significativamente as pesquisas de palavras-chave em campos de texto longos, como post_content. Sem \u00edndices significativos, todas as consultas complexas terminam numa pesquisa de tabelas completas, e \u00e9 exatamente aqui que se nota a necessidade de uma pesquisa de texto completo. <strong>Tempos de espera<\/strong>.<\/p>\n\n<h2>Quando os \u00edndices do WordPress s\u00e3o realmente \u00fateis<\/h2>\n<p>Defino \u00edndices onde as consultas s\u00e3o selectivas e executadas regularmente, por exemplo, em <strong>ID<\/strong>, email, slug ou post_date. Em wp_posts, os \u00edndices em post_author, post_date e post_status s\u00e3o eficazes porque estas colunas aparecem frequentemente em WHERE e ORDER BY. Em wp_postmeta, um \u00edndice em meta_key e, opcionalmente, (meta_key, meta_value) fornece enormes saltos se os temas ou plugins consultarem muitos campos personalizados. Os JOINs entre wp_posts e wp_postmeta beneficiam visivelmente assim que ambas as p\u00e1ginas t\u00eam as chaves correspondentes. E com tabelas grandes, relat\u00f3rios, arquivos e p\u00e1ginas de categoria beneficiam se as consultas forem lidas a partir do \u00edndice e n\u00e3o atrav\u00e9s de milh\u00f5es de linhas. <strong>deve<\/strong>.<\/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\/01\/wordpress_datenbank_meeting_9284.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando os \u00edndices fazem pouco bem ou mesmo mal<\/h2>\n<p>Cada \u00edndice adicional custa <strong>Mem\u00f3ria<\/strong> e torna mais lenta a inser\u00e7\u00e3o, atualiza\u00e7\u00e3o e elimina\u00e7\u00e3o porque o MySQL tamb\u00e9m tem de manter a estrutura. Em tabelas de escrita intensiva, isto pode aumentar significativamente o tempo de execu\u00e7\u00e3o global, mesmo que as leituras individuais sejam mais r\u00e1pidas. As colunas com pouca seletividade, por exemplo campos booleanos ou algumas categorias, dificilmente fornecem ao optimizador qualquer poder de filtragem. Prefiro pesquisar diretamente em tabelas muito pequenas, uma vez que a sobrecarga de verifica\u00e7\u00e3o do \u00edndice ultrapassa as vantagens. Resumi os erros t\u00edpicos e as contramedidas num guia para <a href=\"https:\/\/webhosting.de\/pt\/base-de-dados-indices-danos-utilizacao-mysql-armadilhas-serverboost\/\">Armadilhas de \u00edndice MySQL<\/a> juntos, que tenho de verificar antes de <strong>utiliza\u00e7\u00e3o<\/strong>.<\/p>\n\n<h2>Aplica\u00e7\u00e3o pr\u00e1tica: da medi\u00e7\u00e3o \u00e0 mudan\u00e7a<\/h2>\n<p>Come\u00e7o com a medi\u00e7\u00e3o, n\u00e3o com <strong>Pressentimento<\/strong>O Query Monitor no backend do WordPress mostra-me as consultas, os par\u00e2metros e os chamadores lentos. O EXPLAIN diz-me se o MySQL est\u00e1 a utilizar um \u00edndice ou a pesquisar toda a tabela atrav\u00e9s de ALL; posso reconhecer isto pelo tipo, chave e linhas. Com base nestes dados, crio \u00edndices especificamente para as colunas em WHERE, JOIN e ORDER BY em vez de indexar \u201epara todos os casos\u201c. Ap\u00f3s cada altera\u00e7\u00e3o, me\u00e7o novamente e registo o hist\u00f3rico de altera\u00e7\u00f5es para poder eliminar rapidamente os efeitos negativos. Se os tempos de espera resultarem principalmente da conce\u00e7\u00e3o da consulta, defino para <a href=\"https:\/\/webhosting.de\/pt\/por-que-a-alta-latencia-do-banco-de-dados-nao-vem-da-hospedagem-otimizador-de-design-de-consultas\/\">Conce\u00e7\u00e3o de consultas em vez de hardware<\/a>, porque os servidores mais fortes apenas escondem <strong>Causas<\/strong>.<\/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\/01\/wordpress-datenbank-indizes-vergleich-8271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Indexa\u00e7\u00e3o direcionada de tabelas do WordPress: Vis\u00e3o geral e exemplos<\/h2>\n<p>Em wp_posts, acelero as consultas sobre arquivos, autores ou estados com \u00edndices em <strong>data_post<\/strong>, post_author, post_status e, se necess\u00e1rio, combina\u00e7\u00f5es destes. Em wp_postmeta, defino meta_key e, se necess\u00e1rio, (post_id, meta_key) ou (meta_key, meta_value), consoante filtre mais frequentemente chaves ou valores. Em wp_comments, um \u00edndice em comment_post_ID funciona para acelerar as listas de coment\u00e1rios por publica\u00e7\u00e3o. Em wp_users, os \u00edndices em user_email e user_login proporcionam um acesso r\u00e1pido para logins ou pesquisas administrativas. E nas tabelas de taxonomia, presto aten\u00e7\u00e3o aos caminhos JOIN para que as consultas de categorias, etiquetas e atributos de produtos sejam t\u00e3o r\u00e1pidas quanto poss\u00edvel. <strong>diretamente<\/strong> trabalho.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Tabela \/ campo WP<\/th>\n      <th>Filtro t\u00edpico<\/th>\n      <th>Recomenda\u00e7\u00e3o de \u00edndice<\/th>\n      <th>Benef\u00edcio<\/th>\n      <th>Risco<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>wp_posts (post_date, post_status)<\/td>\n      <td>Arquivos, listas de estado<\/td>\n      <td>INDEX(post_status, post_date)<\/td>\n      <td>Classifica\u00e7\u00e3o r\u00e1pida e intervalos<\/td>\n      <td>Mais despesas gerais de escrita<\/td>\n    <\/tr>\n    <tr>\n      <td>wp_posts (post_author)<\/td>\n      <td>P\u00e1ginas de autor<\/td>\n      <td>INDEX(post_author)<\/td>\n      <td>Filtragem r\u00e1pida<\/td>\n      <td>Pouco lucro para s\u00edtios pequenos<\/td>\n    <\/tr>\n    <tr>\n      <td>wp_postmeta (meta_key, meta_value)<\/td>\n      <td>Campos personalizados<\/td>\n      <td>INDEX(meta_key), se necess\u00e1rio (meta_key, meta_value)<\/td>\n      <td>Acelera\u00e7\u00e3o significativa<\/td>\n      <td>Maiores necessidades de armazenamento<\/td>\n    <\/tr>\n    <tr>\n      <td>wp_comments (comment_post_ID)<\/td>\n      <td>Coment\u00e1rios por publica\u00e7\u00e3o<\/td>\n      <td>INDEX(comment_post_ID)<\/td>\n      <td>Atribui\u00e7\u00e3o r\u00e1pida<\/td>\n      <td>Custos de atualiza\u00e7\u00e3o mais elevados<\/td>\n    <\/tr>\n    <tr>\n      <td>wp_users (user_email, user_login)<\/td>\n      <td>Iniciar sess\u00e3o, pesquisa de administradores<\/td>\n      <td>UNIQUE(user_email), INDEX(user_login)<\/td>\n      <td>Correspond\u00eancias exactas<\/td>\n      <td>Custos de escrita para importa\u00e7\u00f5es a granel<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Tamb\u00e9m utilizo \u00edndices de prefixo para cadeias de caracteres longas, por exemplo <strong>meta_chave<\/strong>(20) para limitar os requisitos de espa\u00e7o e a pegada da cache. Alinho os \u00edndices de v\u00e1rias colunas de acordo com a sequ\u00eancia de filtros nas consultas, de modo a que seja utilizado o prefixo da esquerda. Para pesquisas de texto de volume m\u00e9dio, um \u00edndice de texto completo em post_content proporciona tempos de resposta significativamente mais curtos. Para pesquisas LIKE com um marcador de posi\u00e7\u00e3o \u00e0 esquerda (c), planeio em torno disto, uma vez que nenhum \u00edndice cl\u00e1ssico pode ajudar. E antes de alterar as tabelas, fa\u00e7o uma c\u00f3pia de seguran\u00e7a da base de dados e testo as altera\u00e7\u00f5es numa <strong>Encena\u00e7\u00e3o<\/strong>-ambiente.<\/p>\n\n<h2>Medi\u00e7\u00e3o e controlo: EXPLAIN, SHOW INDEX e registos<\/h2>\n<p>Com o EXPLAIN, posso ver rapidamente se uma consulta preenche os requisitos <strong>\u00cdndice<\/strong> usa: type=ref ou range \u00e9 bom, ALL aponta para a pesquisa na tabela. SHOW INDEX FROM table revela os \u00edndices existentes, a cardinalidade e os duplicados, que eu removo de forma consistente. Escrevo ativamente o slow_query_log em my.cnf para recolher consultas com um tempo de execu\u00e7\u00e3o longo e process\u00e1-las especificamente. Ap\u00f3s as altera\u00e7\u00f5es, utilizo o OPTIMIZE TABLE para atualizar as estat\u00edsticas e a fragmenta\u00e7\u00e3o. E eu documento as mudan\u00e7as com um coment\u00e1rio e data diretamente no arquivo <strong>SQL<\/strong>para que eu possa reproduzi-los mais tarde.<\/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\/01\/wordpress_datenbank_indizes_4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>WooCommerce, wp_postmeta e texto integral: otimiza\u00e7\u00e3o pr\u00e1tica<\/h2>\n<p>As lojas com muitos produtos sofrem frequentemente de muitos <strong>JOINs<\/strong> atrav\u00e9s de wp_postmeta, porque as propriedades e os filtros est\u00e3o a\u00ed localizados. Os \u00edndices em (post_id, meta_key) aceleram de forma mensur\u00e1vel as p\u00e1ginas de produtos, os filtros e as chamadas de API. Para as p\u00e1ginas de categoria, \u00e9 importante uma combina\u00e7\u00e3o de \u00edndice e cache para que as listas recorrentes n\u00e3o sobrecarreguem constantemente a base de dados. Para as pesquisas de produtos, pode ser \u00fatil um \u00edndice de texto completo sobre o t\u00edtulo e o conte\u00fado, pelo que testo primeiro as palavras de paragem, o comprimento m\u00ednimo das palavras e a relev\u00e2ncia. Se os filtros dependerem muito do meta-valor, examino a estrutura dos dados ou armazeno os valores repetidos em tabelas normalizadas com <strong>Chaves<\/strong> de.<\/p>\n\n<h2>Limpar wp_options: Autoload e transientes<\/h2>\n<p>A tabela wp_options \u00e9 frequentemente utilizada para a <strong>gargalo<\/strong>, quando as entradas do autoload crescem de forma incontrol\u00e1vel. Reduzo o autoload=yes ao necess\u00e1rio e elimino os transientes antigos para que o WordPress leia menos mem\u00f3ria no arranque. Um \u00edndice adicional \u00e9 menos \u00fatil do que uma manuten\u00e7\u00e3o de dados consistente e um caching sensato. Para uma introdu\u00e7\u00e3o estruturada, utilizo este guia para <a href=\"https:\/\/webhosting.de\/pt\/otimizacao-da-base-de-dados-wordpress-wpoptions-dicas-manutencao-de-dados\/\">Otimizar wp_options<\/a> e depois verifico regularmente o volume. Se necess\u00e1rio, transfiro as op\u00e7\u00f5es raramente utilizadas para tabelas separadas ou reduzo-as atrav\u00e9s de <strong>Trabalhos de limpeza<\/strong>.<\/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\/01\/wordpress_datenbank_index_7495.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Selecionar corretamente \u00edndices de v\u00e1rias colunas, de prefixos e de \u201ecobertura<\/h2>\n<p>Selecciono a sequ\u00eancia de colunas no \u00edndice multi-colunas de acordo com a <strong>Filtragem<\/strong> em WHERE, n\u00e3o por sensa\u00e7\u00e3o. A parte principal do \u00edndice deve ter a restri\u00e7\u00e3o mais forte para que a pesquisa selectiva tenha efeito. Para a ordena\u00e7\u00e3o, o benef\u00edcio depende do facto de as colunas de ordena\u00e7\u00e3o estarem no lugar certo no \u00edndice e de a dire\u00e7\u00e3o ser compat\u00edvel. Os \u00edndices de cobertura, que cont\u00eam todas as colunas necess\u00e1rias de uma consulta, evitam acessos adicionais \u00e0 tabela e reduzem visivelmente as lat\u00eancias. E com \u00edndices de prefixo em cadeias de caracteres vari\u00e1veis, reduzo a mem\u00f3ria e mantenho o buffer pool pequeno. <strong>eficaz<\/strong>.<\/p>\n\n<h2>Quest\u00f5es de arquitetura: caching, pooling e defini\u00e7\u00f5es do servidor<\/h2>\n<p>Os \u00edndices funcionam melhor quando os combino com um <strong>Objeto<\/strong>-(por exemplo, Redis) para evitar consultas repetidas. O tratamento de liga\u00e7\u00f5es persistentes e as defini\u00e7\u00f5es de pooling limpas reduzem os tempos de configura\u00e7\u00e3o dos trabalhadores PHP. Optimizo os par\u00e2metros do InnoDB, como innodb_buffer_pool_size, para que as p\u00e1ginas de \u00edndice e de dados frequentemente utilizadas sejam armazenadas na mem\u00f3ria. Igualmente importante: algumas consultas bem concebidas em vez de muitas pequenas, para que eu possa manter as despesas gerais por pedido sob controlo. E antes de atualizar o hardware, verifico o plano de consulta, a cobertura do \u00edndice e a l\u00f3gica da aplica\u00e7\u00e3o, porque estes par\u00e2metros fazem a maior diferen\u00e7a. <strong>Alavanca<\/strong> oferta.<\/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\/01\/wordpress-datenbankindizes-9381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Indexar corretamente padr\u00f5es de consulta WP comuns<\/h2>\n<p>As consultas t\u00edpicas do WordPress seguem padr\u00f5es recorrentes. Eu verifico de forma consistente:<\/p>\n<ul>\n  <li>Combina\u00e7\u00f5es WHERE com igualdade antes do intervalo: Num \u00edndice, ordeno as colunas de modo a que <strong>=<\/strong>-condi\u00e7\u00f5es <strong>ENTRE<\/strong>, <strong>&gt;<\/strong>, <strong>&lt;<\/strong> ou LIKE \u201aabc%\u2018. Isto mant\u00e9m o espa\u00e7o de pesquisa pequeno e o optimizador pode ser executado para a coluna de intervalo \u201efrom to\u201c no \u00edndice.<\/li>\n  <li>Cobrir ORDER BY com \u00edndice: Se uma consulta ordenar por post_date DESC para um post_status espec\u00edfico, utilizo um \u00edndice composto como (post_status, post_date DESC). As vers\u00f5es modernas do MySQL suportam <strong>descendente<\/strong> colunas de \u00edndice, o que o Filesort evita.<\/li>\n  <li>Minimizar os caminhos JOIN: Quando JOIN wp_posts \u2192 wp_postmeta on post_id, (post_id, meta_key) acelera consideravelmente a procura de chaves espec\u00edficas. No \u201eoutro lado\u201c, um \u00edndice nas colunas filtradas em wp_posts (por exemplo, post_status) ajuda a tornar ambos os passos selectivos.<\/li>\n  <li>EXISTS em vez de IN para grandes quantidades: Se as subconsultas fornecerem muitos valores, as variantes EXISTS semanticamente id\u00eanticas s\u00e3o frequentemente mais favor\u00e1veis e permitem uma melhor utiliza\u00e7\u00e3o do \u00edndice.<\/li>\n<\/ul>\n\n<h2>Carater\u00edsticas do MySQL para afina\u00e7\u00e3o moderna de \u00edndices<\/h2>\n<p>As vers\u00f5es actuais do MySQL\/MariaDB oferecem fun\u00e7\u00f5es que utilizo especificamente:<\/p>\n<ul>\n  <li><strong>EXPLAIN ANALYZE<\/strong> mostra os tempos de execu\u00e7\u00e3o reais por passo do plano. Posso ver se o plano se ajusta ou se as estat\u00edsticas est\u00e3o a induzir o optimizador em erro.<\/li>\n  <li><strong>\u00cdndices invis\u00edveis<\/strong> Utilizo-o para testes: Torno um \u00edndice temporariamente invis\u00edvel e observo se as consultas se tornam mais lentas. Isto permite-me remover o lastro com seguran\u00e7a.<\/li>\n  <li><strong>Colunas funcionais\/geradas<\/strong>Quando as consultas comparam LOWER(email), crio uma coluna gerada com representa\u00e7\u00e3o normalizada e indexo-a. Desta forma, o \u00edndice permanece utiliz\u00e1vel mesmo que exista uma fun\u00e7\u00e3o no WHERE.<\/li>\n  <li><strong>Histogramas e estat\u00edsticas<\/strong>No caso de distribui\u00e7\u00f5es muito desequilibradas, actualizo as estat\u00edsticas para que o optimizador estime a seletividade de forma realista.<\/li>\n<\/ul>\n\n<h2>Alterar sem tempo de inatividade: implementar e reverter de forma segura<\/h2>\n<p>Planeio as altera\u00e7\u00f5es de \u00edndices de modo a que o site permane\u00e7a online. Utilizo janelas de migra\u00e7\u00e3o com uma carga baixa, confio nas variantes ALTER com capacidade online e monitorizo as lat\u00eancias e os tempos de espera de bloqueio durante este per\u00edodo. Me\u00e7o antecipadamente os requisitos de mem\u00f3ria para que os \u00edndices adicionais n\u00e3o substituam o buffer pool. Para um rollback limpo, mantenho \u00e0 m\u00e3o os scripts DROP\/CREATE e os respectivos coment\u00e1rios com data, para que possa rapidamente <strong>retomar<\/strong> pode.<\/p>\n\n<h2>WooCommerce em termos concretos: HPOS, pesquisas e filtros<\/h2>\n<p>Em configura\u00e7\u00f5es modernas do WooCommerce <strong>Tabelas de encomenda e de pesquisa<\/strong> desempenha um papel importante. Certifico-me de que as consultas de s\u00ednteses de encomendas por estado e data t\u00eam \u00edndices adequados para que as listas e os relat\u00f3rios administrativos abram rapidamente. Os filtros de produtos baseados em atributos, pre\u00e7os ou n\u00edveis de stock beneficiam de tabelas de pesquisa com chaves espec\u00edficas. Quando os filtros se baseiam muito no meta_valor, uma mudan\u00e7a de conceito ajuda-me: normalizar atributos frequentemente utilizados ou materializ\u00e1-los em tabelas de pesquisa para aliviar a carga de wp_postmeta.<\/p>\n\n<h2>Instala\u00e7\u00f5es multi-site e de grande dimens\u00e3o<\/h2>\n<p>Em ambientes com v\u00e1rios sites, o WordPress \u00e9 dimensionado atrav\u00e9s de tabelas separadas por site. Isto mant\u00e9m as tabelas individuais mais pequenas - o que \u00e9 bom para <strong>Seletividade<\/strong> e acessos \u00e0 cache. Evito relat\u00f3rios globais, entre s\u00edtios, sem agrega\u00e7\u00f5es preparadas. Se for necess\u00e1rio resumir muitos s\u00edtios, trabalho com tabelas de agrega\u00e7\u00e3o preenchidas periodicamente e \u00edndices direcionados para os caminhos de consulta.<\/p>\n\n<h2>Conjunto de caracteres, agrupamento e comprimento do \u00edndice<\/h2>\n<p>Com <strong>utf8mb4<\/strong> as chaves de \u00edndice crescem em largura. Planeio deliberadamente \u00edndices de prefixo (por exemplo, (meta_key(20)) para que o limite de 3072 bytes por \u00edndice n\u00e3o se torne um obst\u00e1culo. Para pesquisas sem distin\u00e7\u00e3o entre mai\u00fasculas e min\u00fasculas, escolho um agrupamento adequado; se ainda quiser comparar exatamente normalizado (LOWER\/UPPER), utilizo colunas geradas em vez de fun\u00e7\u00f5es em WHERE. Para campos de texto longos, nunca indexo \u00e0s cegas - me\u00e7o quanto prefixo \u00e9 suficiente para obter uma cardinalidade elevada e escolho o prefixo em conformidade.<\/p>\n\n<h2>Anti-padr\u00f5es que se sobrep\u00f5em aos \u00edndices<\/h2>\n<p>Alguns padr\u00f5es custam muito tempo e impedem a utiliza\u00e7\u00e3o do \u00edndice:<\/p>\n<ul>\n  <li><strong>Fun\u00e7\u00f5es em colunas de \u00edndice<\/strong> no WHERE (por exemplo, DATE(post_date)) impedem que o \u00edndice existente seja usado. Em vez disso, eu filtro usando intervalos (post_date &gt;= ... AND post_date &lt; ...).<\/li>\n  <li><strong>Principais caracteres curinga<\/strong> em LIKE (\u201ac\u2018) n\u00e3o s\u00e3o index\u00e1veis. Estou a planear de novo (pesquisa de prefixos, texto integral, outra estrutura de dados).<\/li>\n  <li><strong>Demasiados \u00edndices<\/strong> na mesma coluna ou com o mesmo prefixo \u00e0 esquerda s\u00e3o de pouca utilidade, mas aumentam os custos de escrita. Consolido as sobreposi\u00e7\u00f5es.<\/li>\n  <li><strong>ORDER BY<\/strong> em colunas que n\u00e3o aparecem no \u00edndice leva a ordena\u00e7\u00f5es de ficheiros. Se a ordena\u00e7\u00e3o for cr\u00edtica para a empresa, construo o \u00edndice composto adequado.<\/li>\n<\/ul>\n\n<h2>Higiene dos \u00edndices: reduzir os duplicados e ret\u00ea-los de forma direcionada<\/h2>\n<p>Utilizo SHOW INDEX para encontrar estruturas redundantes, como um \u00edndice simples em post_status ao lado de um \u00edndice composto (post_status, post_date). Muitas vezes, posso remover o \u00edndice simples porque o \u00edndice composto cobre o prefixo esquerdo. Ao mesmo tempo, mantenho os \u00edndices que parecem semelhantes, mas que servem caminhos de consulta diferentes (por exemplo, (post_author) vs. (post_status, post_date)). Eu deliberadamente documento o porqu\u00ea de um \u00edndice permanecer ou cair para que as atualiza\u00e7\u00f5es de temas\/plugins n\u00e3o tragam nenhuma surpresa mais tarde.<\/p>\n\n<h2>Planeamento da capacidade: pool de buffers, E\/S e \u00e1rea de cobertura do \u00edndice<\/h2>\n<p>Os \u00edndices s\u00f3 s\u00e3o acelerados se as p\u00e1ginas relevantes do <strong>Grupo de tamp\u00f5es<\/strong> mentira. Certifico-me de que o tamanho dos \u00edndices e dados frequentemente utilizados cabe na mem\u00f3ria. Se o volume de dados aumentar, verifico primeiro quais os \u00edndices que s\u00e3o realmente importantes, reduzo os comprimentos dos prefixos e removo as combina\u00e7\u00f5es raramente utilizadas. S\u00f3 quando a carga de trabalho est\u00e1 limpa \u00e9 que vale a pena utilizar mais RAM. Se a carga de escrita for elevada, presto aten\u00e7\u00e3o \u00e0s E\/S adicionais atrav\u00e9s da manuten\u00e7\u00e3o de \u00edndices e evito a indexa\u00e7\u00e3o excessiva \u201etotalmente abrangente\u201c.<\/p>\n\n<h2>Medi\u00e7\u00e3o e controlo avan\u00e7ados<\/h2>\n<p>Para al\u00e9m do EXPLAIN, baseio-me em medi\u00e7\u00f5es em produ\u00e7\u00e3o: o slow_query_log com valores-limite realistas mostra-me os outliers, e uma an\u00e1lise de padr\u00f5es das consultas mais frequentes torna as tend\u00eancias vis\u00edveis. Ap\u00f3s as altera\u00e7\u00f5es de \u00edndices, verifico a cardinalidade em SHOW INDEX, analiso o n\u00famero de linhas afectadas (rows_examined) e observo a taxa de acerto e a lat\u00eancia da cache. Repito este ciclo regularmente porque os perfis de utiliza\u00e7\u00e3o mudam devido a novas funcionalidades, plugins ou picos de tr\u00e1fego.<\/p>\n\n<h2>Resumo<\/h2>\n<p>Eu fixo <strong>\u00cdndices de bases de dados<\/strong> onde as consultas selectivas e recorrentes s\u00e3o executadas, e deix\u00e1-las de fora onde a escrita domina. No WordPress, wp_posts, wp_postmeta, wp_comments e wp_users proporcionam os maiores ganhos quando cubro os filtros actuais. A medi\u00e7\u00e3o com EXPLAIN, Query Monitor e slow_query_log leva-me de forma fi\u00e1vel aos candidatos certos. A manuten\u00e7\u00e3o de wp_options, o armazenamento em cache e a boa conce\u00e7\u00e3o das consultas evitam que os \u00edndices mascarem os sintomas em vez de resolverem as causas. Isto mant\u00e9m a base de dados r\u00e1pida, a carga de escrita dentro dos limites e o <strong>Desempenho<\/strong> est\u00e1vel - sem indexa\u00e7\u00e3o cega.<\/p>","protected":false},"excerpt":{"rendered":"<p>Explica\u00e7\u00e3o do \u00edndice da base de dados do WordPress: Quando \u00e9 que os \u00edndices da base de dados melhoram o desempenho do WordPress e quando n\u00e3o? Dicas de afina\u00e7\u00e3o do MySQL WP.<\/p>","protected":false},"author":1,"featured_media":16871,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-16878","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"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":"1263","_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":null,"_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":"Datenbank-Indizes","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":"16871","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/16878","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=16878"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/16878\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/16871"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=16878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=16878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=16878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}