¿Qué pasa?

Simples! Atualização de estatistas do MySQL

Os bancos de dados utilizam estatísticas para definir seus planos de acesso aos dados e assim executar o caminho mais eficiente na busca pelos dados solicitados por determinada consulta. Para isso o banco de dados deve manter suas estatísticas sempre atualizadas. Por padrão o InnoDB já realiza essa atualização automaticamente, evitando que haja qualquer tipo de problema de performance por falta de informações de acesso.

Essa atualização forçada ou automatizada é controlada pela variável:

innodb_stats_persistent

Mais informações a respeito dessa configuração estão disponiveis em:

http://dev.mysql.com/doc/refman/5.6/en/innodb-persistent-stats.html

Ok, …

Como verificar a existência de locks no ambiente ?

SELECT
*
FROM
information_schema.processlist
WHERE
state IN ('Waiting for table flush' , 'Locked', 'Table lock')
OR state REGEXP 'Waiting for .* lock'
ORDER BY time DESC

E como identificar as consultas ou sessões que estão realizando o lock?

SELECT
TRX.TRX_MYSQL_THREAD_ID,
TRX.TRX_ISOLATION_LEVEL,
TRX.TRX_STARTED,
TRX.TRX_STATE,
PROCESSLIST.USER,
PROCESSLIST.HOST,
PROCESSLIST.DB,
PROCESSLIST.COMMAND,
PROCESSLIST.TIME,
PROCESSLIST.STATE,
LOCK_WAITS.REQUESTING_TRX_ID,
LOCK_WAITS.BLOCKING_TRX_ID,
LOCK_WAITS.BLOCKING_LOCK_ID
FROM
INFORMATION_SCHEMA.INNODB_LOCKS LOCKS,
INFORMATION_SCHEMA.INNODB_TRX TRX,
INFORMATION_SCHEMA.PROCESSLIST PROCESSLIST,
INFORMATION_SCHEMA.INNODB_LOCK_WAITS LOCK_WAITS
WHERE
LOCKS.LOCK_TRX_ID = TRX.TRX_ID
AND TRX.TRX_MYSQL_THREAD_ID = PROCESSLIST.ID;

MySQL Fabric é uma ferramenta que está inclusa no MySQL Utilities que ajuda a gerenciar servidores MySQL.
Ele funciona basicamente adicionando uma nova camada entre a aplicação e os servidores MySQL, que auxilia no processo de sharding e alta disponibilidade.

Para mais informações referente ao que é MySQL Fabric, leia a documentação.

Para instalar nosso ambiente com MySQL Fabric, vamos precisar de 4 servidores, eu utilizei os seguintes nomes e IPs:

fabric1 (192.168.0.200) - fabric
mysql1 (192.168.0.201) - mysql master
mysql2 (192.168.0.202) - mysql slave
mysql3 (192.168.0.203) - mysql slave

Obs.: Estou rodando CentOS 6.5 em todos os servidores.

1. Adicione o repositório mysql nos 4 servidores, leia …

Você deve imaginar, que vou explicar como otimizar a performance do banco de dados com os novos catálogos de performance do mysql(performance_schema)?

Não! HAhAHA

Vou explicar, que ele também pode ser o vilão da história!

Performance_schema é uma excelente ferramenta para monitoria do ambiente, possibilitando a analise de possíveis problemas de performance, mas o uso desse recurso causa em média entre 10% e até 30% de “overhead”, ou seja onera em até 30% o seu banco de dados causando lentidão nos processos executados no mesmo.

As versões mais recentes do MySQL tem esse recurso configurado por padrão, ou seja, é automaticamente ativado na inicialização da instância. Em pequenos bancos de dados ou com fluxo transacional baixo, acaba sendo imperceptível a queda de performance gerada por essa monitoria, mas em ambientes com grande fluxo transacional, filas de processamento e Terabytes de …

Uma das mais importantes configurações para quem usa InnoDB é o innodb_buffer_pool_size, ele basicamente armazena dados e índices em memória, quando o MySQL recebe uma query e as paginas que contem o resultado da pesquisa/índice estao armazenadas no buffer, o MySQL não precisar ler essas informações do disco, o que é muito mais rápido (velocidade da memória vs velocidade do disco) .

Como estas informações estão armazenadas na memória, cada vez que o MySQL é re-iniciado, o buffer é apagado, e para “esquentar” o buffer normalmente leva-se algum tempo.

Para agilizar este processo, vamos utilizar 2 variáveis para salvar e restaurar as referencias das paginas que estão armazenadas no buffer, esta é uma nova funcionalidade adicionada no MySQL 5.6 (essa opção já pode ser encontrada em algumas versões anteriores do Percona Server e MariaDB )

Se o seu servidor já está rodando e com o buffer …

Dê ao homem certo a ferramenta certa e este operará verdadeiros milagres. Agora, dê a ferramenta errada ao cara errado, e o desastre é certo! Venho insistindo nisto já faz algum tempo, e, creio que não custa batermos nesta tecla […] ↓ Read the rest of this entry...

Olá, pessoal. Neste artigo vou abordar um tópico muito importante para quem trabalha com banco de dados: a melhoria de desempenho também conhecido como performance em banco de dados. Veremos que, de acordo com a documentação oficial dos bancos de dados atuais, ainda estamos muito longe de caracterizar o que realmente gera ou não melhor desempenho no banco.

Antes de começar, vamos imaginar uma situação hipotética que pode acontecer no dia a dia de qualquer profissional que esteja envolvido com banco de dados. Durante o desenvolvimento de algum sistema ou aplicação web, alguém cita que utilizar tal funcionalidade X ou parâmetro Y ou mesmo arquitetura Z gera um desempenho melhor em banco de dados. Até aqui tudo bem, porém são raros os momentos em que alguém se dispõe a quantificar o quanto de desempenho espera-se obter. Esta é uma questão muito …

Hoje vamos falar de uma ferramenta bem bacana do MySQL, o query cache.
o query cache salva resultados de SELECT’s já executados e que seus dados brutos não tenham sido alterados tornando assim o tempo de resposta da query muito mais otimizada, pois ele vai buscar da memória e não do disco.
Ele pode trabalhar de 3 maneiras diferentes, no nosso my.ini dentro do grupo [mysqld]:
query_cache_type = 0
Desligado
query_cache_type = 1
Ligado para todas as query’s
query_cache_type = 2
Ligado sobre demanda

Mas qual a melhor maneira de utilizar o query cache?
Tendo em vista que toda a vez que você altera dados em alguma tabela, ele invalida o cache da mesma, o mais indicado é você fazer um mapeamento da frequencia de atualização das tabelas e utilizar o cache para as que não tenham uma frequencia grande a atualização / inserção, para …