A cena é sempre a mesma: alguém mexeu no preço, o site não atualizou, e o dev roda indexer:reindex seco. Quarenta minutos depois a loja volta ao normal, com o servidor no talo e o cliente reclamando de lentidão no meio do dia.
Quase nunca precisa disso. O Magento sabe exatamente qual índice está sujo e ele te conta se você perguntar.
Leia o status antes de sair reindexando
Um comando responde tudo:
php bin/magento indexer:statusA tabela tem seis colunas: ID, Title, Status, Update On, Schedule Status e Schedule Updated. O que interessa:
- Status é
Ready,Reindex required,ProcessingouSuspended. Só o segundo pede ação sua. - Update On é
SaveouSchedule, o modo de cada índice. - Schedule Status só aparece em modo Schedule e traz o tamanho da fila, no formato
(N in backlog).
Para filtrar direto quem está sujo:
php bin/magento indexer:status | grep "Reindex required"Se você não lembra o ID exato de um índice, php bin/magento indexer:info lista todos com nome e título.
Reindexe só o que precisa
O indexer:reindex aceita a lista de IDs, separados por espaço:
php bin/magento indexer:reindex catalog_product_priceOu dois de uma vez, quando o par anda junto:
php bin/magento indexer:reindex catalog_category_product catalog_product_categoryOs que mais aparecem sujos no dia a dia de loja brasileira:
| ID | Quando costuma invalidar |
|---|---|
catalog_product_price | mudou preço, regra de preço ou grupo de cliente |
catalogsearch_fulltext | produto novo não aparece na busca |
catalog_category_product | produto não aparece na categoria |
cataloginventory_stock | estoque entrou pelo ERP e a vitrine não viu |
catalogrule_product | promoção de catálogo com data de início |
O caminho inverso também existe: php bin/magento indexer:reset catalogsearch_fulltext marca o índice como inválido sem reconstruir nada. Útil para deixar o trabalho pesado para o cron da madrugada em vez de segurar o terminal.
Se virou rotina, o modo está errado
Reindexar na mão toda semana é sintoma. Em Update on Save, salvar um produto dispara reindexação na hora, no meio do request — por isso o admin fica lento e o índice vive caindo em massa quando entra importação.
Em Update by Schedule, o Magento registra a mudança numa tabela de changelog e o cron aplica só o que mudou:
php bin/magento indexer:set-mode schedule catalog_category_product catalog_product_categoryQuem faz o trabalho depois é o grupo de cron index, com três jobs declarados no core: indexer_reindex_all_invalid e indexer_update_all_views rodando a cada minuto, e indexer_clean_all_changelogs a cada cinco. Ou seja, com cron saudável, índice inválido some sozinho em pouco tempo.
Duas ressalvas antes de virar a chave em tudo. Primeira: o customer_grid. Até o 2.4.7 ele só suportava Update on Save; a partir do 2.4.8 aceita os dois modos e já vem em Update by Schedule. Se a sua loja está numa versão anterior, deixe esse quieto no modo Save.
Segunda: modo schedule só funciona com cron rodando de verdade. Se o cron está parado, o changelog cresce, a coluna de backlog dispara e a loja fica exibindo dado velho sem nenhum aviso. Confira o backlog no indexer:status de vez em quando.
Perguntas rápidas
Posso reindexar com a loja no ar?
Pode, e é o normal. O custo é CPU e banco, não indisponibilidade. Prefira horário de baixo movimento para os índices grandes e, se der pico de lentidão, rode um índice por vez em vez da lista toda.
Preciso de alguma ordem entre os índices?
A documentação da Adobe não define ordem obrigatória. Na prática vale reindexar categoria e produto juntos, porque um alimenta a listagem do outro, e deixar o fulltext por último para ele ler o preço já atualizado.
Coloquei tudo em schedule e o backlog só cresce. O que aconteceu?
É cron parado ou o grupo index sem rodar. Confira se o crontab do sistema chama o bin/magento cron:run e olhe o var/log/cron.log. Sem cron, o modo schedule só acumula mudança e nunca aplica.
Pra conferir na fonte
- Manage indexers — Adobe Experience League
- Magento_Indexer etc/crontab.xml — GitHub
- Magento_Indexer IndexerStatusCommand.php — GitHub