Tuning de MySQL para servidores de MU Online: guia completo de performance

O banco de dados é o gargalo mais subestimado em servidores de MU Online com muitos jogadores simultâneos: cada login, troca de item, atualização de posição e log de evento gera consultas ao MySQL, e uma configuração padrão (out-of-the-box) simplesmente não foi feita para esse volume de operações pequenas e frequentes. Este tutorial cobre o tuning completo do MySQL/MariaDB para MU Online, dos parâmetros de memória até a estratégia de índices e manutenção contínua, com foco em quem já tem o servidor rodando e sente lentidão em horário de pico.

Diagnosticando o problema antes de ajustar

Antes de mudar qualquer parâmetro, confirme que o gargalo é realmente o banco de dados. Ative o slow query log temporariamente e observe quais queries excedem o limite de tempo aceitável:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

Depois de algumas horas em horário de pico, analise o arquivo de log (ou use mysqldumpslow/pt-query-digest) para identificar as queries mais lentas e mais frequentes. Isso direciona o esforço de tuning para o problema real, em vez de ajustar parâmetros genericamente.

Parâmetros essenciais do InnoDB

O InnoDB é o motor de armazenamento padrão e recomendado para as tabelas de personagem, inventário e conta em praticamente todos os emuladores de MU. Os parâmetros com maior impacto:

Configuração de conexões e threads

Servidores de MU com múltiplos processos (GameServer, ConnectServer, JoinServer, DataServer/painel web) abrem muitas conexões simultâneas ao banco. Ajuste:

[mysqld]
max_connections = 300
thread_cache_size = 64
table_open_cache = 4000

Um erro comum é deixar max_connections no padrão baixo (geralmente 151), o que causa erros de "too many connections" justamente em horário de pico, quando mais jogadores estão logando e gerando picos de conexão simultânea.

Índices essenciais nas tabelas do MU

A maioria dos emuladores já vem com índices básicos nas tabelas principais (Character, AccountCharacter, Warehouse), mas conforme o servidor cresce, é comum precisar de índices adicionais para queries customizadas (rankings, sistemas de doação, logs de auditoria). Antes de criar índices, identifique queries lentas repetidas no slow log e verifique o plano de execução:

EXPLAIN SELECT * FROM Character WHERE AccountID = 'exemplo' AND Ctl1 = 0;

Se o EXPLAIN mostrar type: ALL (full table scan) em uma tabela grande, é sinal de índice faltando na coluna usada no filtro. Adicione com cautela em produção, preferencialmente em horário de baixo movimento, pois criar índice em tabela grande pode travar escritas temporariamente.

Otimizando tabelas de log e ranking

Tabelas de log (login, comando GM, transação de item) crescem indefinidamente e raramente são otimizadas pelos administradores. Duas práticas recomendadas:

• Particionamento por data em tabelas de log muito grandes, para que consultas recentes (as mais comuns) não precisem varrer todo o histórico.
• Arquivamento periódico: mover registros com mais de X meses para uma tabela de histórico separada ou exportar e truncar, mantendo a tabela ativa enxuta.

Tabelas de ranking (top level, top guild, top reset) frequentemente rodam em cron jobs pesados — se o script recalcula tudo do zero a cada execução, considere otimizar para atualização incremental ou rodar em horário de menor movimento.

Connection pooling na aplicação (emulador)

Além do tuning do próprio MySQL, verifique se o emulador está usando pool de conexões de forma eficiente ou abrindo/fechando conexões novas a cada operação — isso último gera overhead desnecessário de handshake. Emuladores baseados em .NET geralmente usam connection string com pooling habilitado por padrão; confirme os parâmetros Min Pool Size e Max Pool Size na string de conexão do GameServer e do painel web, ajustando conforme o número de jogadores simultâneos esperado.

Configuração de cache de query (quando aplicável)

Versões mais antigas de MySQL (até 5.7) suportam query_cache, útil para queries repetitivas idênticas, mas com limitações de concorrência em cargas de escrita alta. Em versões 8.0+ o recurso foi removido — nesse caso, avalie caching na camada de aplicação (ex.: cache do painel web para rankings) em vez de depender do banco para esse tipo de otimização.

Monitoramento contínuo

Ferramentas leves de monitoramento (Percona Monitoring and Management, ou simplesmente scripts de SHOW STATUS/SHOW ENGINE INNODB STATUS agendados) ajudam a identificar tendências antes que virem incidentes. Acompanhe especialmente:

Rotina de manutenção e backup

Agende OPTIMIZE TABLE periódico nas tabelas com alta taxa de update/delete (inventário, personagem), pois o InnoDB acumula fragmentação ao longo do tempo. Para backup, prefira ferramentas de hot backup (como mariabackup/xtrabackup) em bancos grandes, evitando o bloqueio de tabelas que um mysqldump tradicional pode causar em produção. Sempre rode backups em horário de menor movimento e valide periodicamente que o backup é restaurável — um backup nunca testado é apenas uma suposição.

Erros comuns e soluções

Checklist de tuning de MySQL para MU Online

• Slow query log ativado e analisado antes de qualquer ajuste.
• Parâmetros de InnoDB (buffer pool, log file, flush method) ajustados à RAM disponível.
• max_connections e thread_cache_size calibrados para o número de processos do servidor.
• Índices revisados com EXPLAIN nas queries mais lentas identificadas.
• Rotina de arquivamento/particionamento aplicada às tabelas de log.
• Connection pooling do emulador validado (Min/Max Pool Size).
• Monitoramento contínuo de métricas-chave configurado.
• Backup em hot backup testado e validado como restaurável.

Com o banco de dados ajustado para suportar o volume real de jogadores, o próximo passo é revisar a configuração geral do servidor de jogo que depende dessa base: veja o tutorial de criação de servidor de MU Online para entender como GameServer, ConnectServer e banco de dados trabalham juntos na arquitetura completa.

Perguntas frequentes