Guia Aplicacao Indices

📋 Guia de Aplicação de Índices - C-Suite

Data: 2025-12-06
Status: ✅ Análise Completa - Pronto para Aplicação


🎯 Visão Geral

Este guia detalha como aplicar os 160 índices sugeridos pela análise de performance do banco de dados.


📊 Resumo da Análise


🚀 Método 1: Aplicação Automática (Recomendado)

Passo 1: Revisar Arquivos SQL

# Ver arquivos gerados
ls -lh database_analysis/*.sql

# Revisar um arquivo (exemplo)
head -50 database_analysis/indexes_staging_20251206_143809.sql

Passo 2: Fazer Backup

# Backup completo
mysqldump -h vallery.catmgckfixum.sa-east-1.rds.amazonaws.com \
  -u core -p \
  --all-databases \
  > backup_before_indexes_$(date +%Y%m%d_%H%M%S).sql

Passo 3: Aplicar Índices

# Usar script automático
./scripts/apply_indexes.sh

# Ou aplicar manualmente por schema:
mysql -h vallery.catmgckfixum.sa-east-1.rds.amazonaws.com \
  -u core -p \
  staging < database_analysis/indexes_staging_20251206_143809.sql

🔧 Método 2: Aplicação Manual (Controle Total)

Aplicar por Prioridade

1. Alta Prioridade - Staging (26 índices)

Por quê primeiro: Tabelas sem índices, maior impacto imediato

mysql -h vallery.catmgckfixum.sa-east-1.rds.amazonaws.com \
  -u core -p \
  staging < database_analysis/indexes_staging_20251206_143809.sql

Tempo estimado: 5-15 minutos

2. Alta Prioridade - Core (10 índices)

Por quê segundo: Foreign keys e views críticas

mysql -h vallery.catmgckfixum.sa-east-1.rds.amazonaws.com \
  -u core -p \
  core < database_analysis/indexes_core_20251206_143809.sql

Tempo estimado: 3-10 minutos

3. Alta Prioridade - C-Suite (17 índices)

Por quê terceiro: Índices compostos, queries por organização

mysql -h vallery.catmgckfixum.sa-east-1.rds.amazonaws.com \
  -u core -p \
  csuite < database_analysis/indexes_csuite_20251206_143809.sql

Tempo estimado: 10-30 minutos

4. Alta Prioridade - C-Suite Staging (1 índice)

mysql -h vallery.catmgckfixum.sa-east-1.rds.amazonaws.com \
  -u core -p \
  csuite_staging < database_analysis/indexes_csuite_staging_20251206_143809.sql

Tempo estimado: 1-2 minutos


⚠️ Considerações Importantes

Antes de Aplicar

  1. Backup Obrigatório
    bash mysqldump -h $DB_HOST -u $DB_USER -p --all-databases > backup.sql

  2. Horário de Baixo Tráfego

  3. Criar índices pode bloquear tabelas
  4. Executar fora do horário comercial
  5. Avisar equipe sobre possível lentidão

  6. Monitorar Espaço em Disco

  7. Índices ocupam espaço adicional
  8. Verificar espaço disponível antes

  9. Testar em Staging Primeiro

  10. Sempre validar em ambiente de teste
  11. Monitorar por 24-48 horas

Durante a Aplicação

  1. Não Interromper
  2. Deixar processo completar
  3. Interrupção pode deixar índices inconsistentes

  4. Monitorar Progresso
    ```sql
    -- Ver índices sendo criados
    SHOW PROCESSLIST;

-- Ver índices existentes
SHOW INDEX FROM table_name;
```

  1. Verificar Erros
  2. Alguns índices podem falhar (ex: já existem)
  3. Revisar logs de erro

Após Aplicação

  1. Validar Criação
    sql -- Verificar índices criados SELECT TABLE_SCHEMA, TABLE_NAME, INDEX_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA IN ('csuite', 'core', 'staging', 'csuite_staging') ORDER BY TABLE_SCHEMA, TABLE_NAME, INDEX_NAME;

  2. Testar Performance
    ```sql
    -- Antes (salvar tempo)
    EXPLAIN SELECT * FROM csuite.action_items
    WHERE organization_id = 1 AND created_at > '2025-01-01';

-- Depois (comparar tempo)
-- Deve ser significativamente mais rápido
```

  1. Monitorar por 1 Semana
  2. Verificar que queries estão mais rápidas
  3. Validar que não há regressões
  4. Monitorar tempo de INSERT/UPDATE

📋 Checklist de Aplicação

Pré-Aplicação

Aplicação

Pós-Aplicação


🔍 Troubleshooting

Erro: "Duplicate key name"

Causa: Índice já existe

Solução:

-- Verificar índices existentes
SHOW INDEX FROM table_name;

-- Remover índice duplicado ou pular criação
-- Editar arquivo SQL para remover linha

Erro: "Table is locked"

Causa: Tabela em uso ou lock de outro processo

Solução:

-- Ver processos bloqueando
SHOW PROCESSLIST;

-- Aguardar ou matar processo bloqueador (com cuidado)
KILL process_id;

Erro: "Out of disk space"

Causa: Espaço insuficiente para criar índices

Solução:
- Liberar espaço em disco
- Aplicar índices em lotes menores
- Considerar aplicar apenas alta prioridade

Performance Pior Após Índices

Causa: Índices podem aumentar tempo de INSERT/UPDATE

Solução:
- Monitorar queries específicas
- Remover índices que não estão sendo usados
- Otimizar queries para usar índices corretos


📊 Métricas de Sucesso

Antes da Aplicação

Medir tempo de queries críticas:

-- Exemplo: Query por organização
SELECT * FROM csuite.action_items 
WHERE organization_id = 1 
  AND created_at > '2025-01-01'
ORDER BY created_at DESC;
-- Anotar tempo de execução

Após Aplicação

Comparar tempo:
- Esperado: 50-90% de redução em queries por organização
- Esperado: 70-95% de redução em queries em staging
- Esperado: 40-60% de melhoria geral


🎯 Ordem Recomendada de Aplicação

Fase 1: Crítico (Imediato)

  1. staging - Tabelas sem índices (26 índices)
  2. core - Foreign keys críticas (10 índices)

Fase 2: Importante (Após Fase 1)

  1. csuite - Índices compostos (17 índices)
  2. csuite_staging - Único índice crítico (1 índice)

Fase 3: Otimização (Após Validação)

  1. Aplicar índices de média prioridade conforme necessidade

💡 Dicas

  1. Aplicar em Lotes
  2. Não aplicar todos de uma vez
  3. Aplicar por schema ou por prioridade

  4. Monitorar Continuamente

  5. Usar SHOW PROCESSLIST durante aplicação
  6. Verificar logs de erro

  7. Documentar Resultados

  8. Anotar melhorias observadas
  9. Documentar problemas encontrados

  10. Revisar Periódicamente

  11. Re-executar análise a cada 3-6 meses
  12. Ajustar índices conforme uso real

📚 Referências


Última atualização: 2025-12-06

🔊 Text-to-Speech

1.0x
1.0
Pronto para reproduzir