<\/p>\n
<\/p>\n
\n Fabrício Lima<\/a><\/span> · Abril 2026\n <\/p>\n<\/div>\n <\/p>\n Autor<\/p>\n Fabrício Lima<\/strong> · CEO Power Tuning · LinkedIn ↗<\/a> · YouTube ↗<\/a><\/p>\n<\/div>\n <\/p>\n Sobre o que é<\/p>\n Em 20 anos otimizando Protheus, vi muito gestor aprovar centenas de milhares em hardware ou aumentar a fatura mensal de cloud achando que ia resolver lentidão — e ver o problema voltar 6 meses depois. Esse post mostra por que isso acontece<\/strong>, com 4 cases reais do meu arquivo. O ponto não é que mais infra não serve. É que ela é quase sempre a última<\/strong> medida — não a primeira.<\/p>\n<\/div>\n A frase que mais ouvi em 20 anos de Protheus é essa — e nos últimos anos, com cloud, ela ganhou uma versão nova:<\/p>\n Mais infra parece<\/strong> a resposta óbvia, e a cloud deixou isso ainda mais fácil — não precisa nem de cotação, é um clique no portal. CPU em 100%? Sobe SKU. Disco lento? Aumenta IOPS. Memória cheia? Mais RAM. A lógica é tão simples que ninguém questiona.<\/p>\n Mas tem um detalhe incômodo: na maioria absoluta dos casos que atendi, mais infra não resolveu nada. Ou resolveu por 6 meses, e a empresa estava de volta com o mesmo problema — agora pagando mais caro pra continuar lenta. Por quê?<\/p>\n Porque infraestrutura não conserta query mal escrita. SSD\/Premium Storage não cria índice faltando. Mais vCore não impede um SELECT * lendo tabela de 48 milhões de linhas. Mais infra só faz o problema acontecer mais rápido<\/strong> — e, na cloud, faz você pagar mais por ele todo mês. A causa continua intacta. E cresce com o banco.<\/p>\n Quando o ERP fica lento, você tem três caminhos. Cada um com custo, prazo e risco bem diferentes:<\/p>\n Caminho 1<\/p>\n ☁️ Mais Infra<\/p>\n Hardware ou vCore\/DTU na cloud<\/p>\n Custo<\/p>\n Alto e recorrente<\/p>\n Prazo<\/p>\n Imediato (cloud) a meses (on-prem)<\/p>\n ⚠ Problema volta — mas você passa a pagar mais<\/p>\n<\/td>\n <\/p>\n Caminho 2<\/p>\n 📝 AdvPL<\/p>\n Reescrever código do ERP<\/p>\n Custo<\/p>\n Médio-alto<\/p>\n Prazo<\/p>\n Demorado<\/p>\n ⚠ Cria dependência de terceiros<\/p>\n<\/td>\n <\/p>\n Caminho 3<\/p>\n 💾 Banco de Dados<\/p>\n Índices, compressão, queries<\/p>\n Custo<\/p>\n Baixo<\/p>\n Prazo<\/p>\n Minutos a horas<\/p>\n ✅ Resolve a causa, sem mexer no ERP<\/p>\n<\/td>\n<\/tr>\n<\/table>\n Esse post inteiro é sobre o caminho 3 — o que economiza dinheiro (capex e opex), tempo e a sua reputação como gestor. E vou provar com 4 cases reais do meu arquivo de cliente.<\/p>\n<\/div>\n Você não precisa virar DBA. Mas precisa entender 5 conceitos que separam um ambiente bem cuidado de um prestes a estourar — pra saber quando seu time está fazendo o trabalho certo, e quando está te empurrando hardware.<\/p>\n Nos clientes que atendi, era comum encontrar uma única query<\/strong> consumindo 30% a 40% de todo o recurso do banco. Subir o SKU da instância não resolve isso — só faz a query consumir 40% de uma máquina mais cara. Em cloud, isso vira aumento mensal recorrente. Identificar e otimizar essa query, sim, libera o ambiente inteiro — e na cloud derruba a fatura.<\/p>\n<\/p><\/div>\n Sem ferramenta de monitoramento, ninguém sabe qual query é cara, qual tabela cresce mais, ou onde estão os locks. Você vive reagindo a chamado de usuário. Esse é o sintoma clássico que faz aprovar mais infra (ou subir o SKU na cloud)<\/strong>: quando ninguém enxerga o problema, "trocar tudo" vira a melhor hipótese possível. Não é.<\/p>\n<\/p><\/div>\n Quando uma query pede "todas as colunas" de uma tabela gigante, o SQL Server desiste de usar índice e lê a tabela inteira. Em tabelas do Protheus com 48 milhões de linhas, isso significa milhões de leituras desnecessárias. Pedir só as colunas necessárias muda tudo.<\/strong><\/p>\n<\/p><\/div>\n A maioria dos DBAs cuida bem dos índices nos filtros (WHERE). Mas quando uma query junta 3 tabelas grandes do Protheus, e os índices nas colunas de junção<\/strong> não existem, o servidor inteiro trava. Esse é o gargalo mais subestimado que existe — e raramente aparece em diagnóstico de fornecedor.<\/p>\n<\/p><\/div>\n O Protheus preenche colunas vazias com espaços em branco em vez de NULL — desperdiçando espaço massivamente. A compressão nativa do SQL Server elimina esses vazios, com reduções reais entre 60% e 80% — vi cliente sair de 242GB pra 50GB. Banco menor cabe na RAM, e aí tudo<\/strong> fica mais rápido. Sem mexer no ERP, sem novo servidor.<\/p>\n<\/p><\/div>\n<\/div>\n Pra ilustrar o impacto real, separei 4 cases de clientes do meu arquivo. Em todos, a empresa estava em vias de aumentar a infra — comprar servidor novo, subir o SKU no Azure, ou aumentar storage premium — e a otimização no banco resolveu o problema em horas. O custo: uma fração do que seria a infra extra (só ou recorrente).<\/p>\n <\/p>\n Case 1 · CT2010 (48 milhões de registros)<\/p>\n Query filtrava por uma coluna específica. O próprio SQL Server sugeriu um índice gigante — seria caro de manter numa tabela desse tamanho. Solução: um índice menor, apenas pela coluna seletiva (420MB, criado em 5 minutos):<\/p>\n
\n
\n<\/p>\n💰 Por que mais infra quase nunca é a resposta<\/h2>\n
As 3 opções que você tem (e o quanto cada uma custa)<\/h3>\n
\n
\n <\/p>\n \n \n \n ★ FOCO DESSE POST<\/span><\/p>\n
\n
\n<\/p>\n💡 O que você, gestor, precisa saber sobre seu banco<\/h2>\n
1. Uma só query pode comer 40% do servidor (ou da sua fatura cloud)<\/h3>\n
2. Sem visibilidade, você vive no escuro<\/h3>\n
3. SELECT * é o inimigo número 1 da performance<\/h3>\n
4. Índices nos JOINs, não só nos filtros<\/h3>\n
5. Compressão pode reduzir o banco em 70% (e não é gambiarra)<\/h3>\n
\n
\n<\/p>\n💬 O que aprendi em 20 anos<\/h2>\n
\n
\n<\/p>\n📈 4 cases reais que evitaram aumento de infra<\/h2>\n
O índice sugerido nem sempre é o melhor<\/h3>\n