Profiler no MySQL 5.0.37

[Wagner Bianchi 0]

Olá pessoal,

 

Espero com este primeiro mini-artigo, agradar a gregos e troianos com mais uma novidade, que já vem a algum tempo sendo utilizada no MySQL 5.0.37 ++, na versão community, o profiler!

 

Muitos SGBD's já trazem esta ferramenta em forma de software, como o próprio conceito de SGBD já defende, ser um conjunto de softwares que gerenciam bancos de dados. A MySQL AB traz em linha de comando, na versão community, o comandinho que adiciona ao cliente mysql, as funcionalidades de exibir as últimas queries que foram enviadas ao servidor, nos dando várias possibilidades de chacar informações de grande importância para DBA e administradores de ambiente de TI em geral.

 

COMO UTILIZAR

 

O Profiler foi adaptado em uma construção interna ao database e pode ser facilmente habilitado ou desabilitado. Via cliente mysql. Para que o servidor comece a capturar as consultas enviadas a ele e comece a análisá-las, basta emitirmos o seguinte comando:

 

mysql> SET profiling=1;
Query OK, 0 rows affected (0.00 sec)

 

Após esse comando, alguns outros processos são criados internamente, dentro do MySQL, como os diagnósticos das análises de suas queries que são armazenados dentro do banco de dados INFORMATION_SCHEMA, armazenando as consultas da sessão corrente, tudo em uma tabela temporária (MEMORY). Após o termino desta sessão, a tabela será eliminada como qualquer tabela MEMORY.

 

Um comentário antes de prosseguirmos é que, tabelas MEMORY tem características diferentes de tabelas TEMPORARY. TEMPORARY TABLE somente podem ser acessadas por quem as criou e MEMORY são globais. Quando o servidor é reiniciado, a estrutura de uma tabela MEMORY continua no dicionário de dados, mas seu conteúdo é perdido, enquanto que a TEMPORARY é totalmente removida após a desconexão de quem a criou.

 

Seguindo...

 

Bom, a partir de agora, basta executar algumas consultas para testarmos nosso profiler, especialmete, consultas com COUNT(*), AVG(), SUM(), ORDER BY e LIKE, que são funções e operadores que custam muito para o SGBD.

 

Após emitir qualquer consulta, poderemos então checar as consultas mais caras para o SGBD com o seguinte comando:

 

mysql> SHOW profiles;

 

Um exemplo de um resultado aleatório pode ser parecido com o apresentado abaixo:

 

+----------+------------+-----------------------------------------------+
| Query_ID | Duration   | Query                                         |
+----------+------------+-----------------------------------------------+
|        0 | 0.00007300 | SET profiling=1                               |
|        1 | 0.00044700 | SELECT count(*) FROM client WHERE broker_id=2 |
+----------+------------+-----------------------------------------------+
2 rows IN SET (0.00 sec)

 

Caso ainda você queira fazer um SELECT na tal tabela temporária criada no INFORMATION_SCHEMA, emita o seguinte comando:

 

mysql> SELECT sum(duration) FROM information_schema.profiling WHERE query_id=1;

 

O resultado dessa consulta será o tempo de duração da primeira consulta emitida após acionar o profiler! Muito legal não acham?!?! :rolleyes:

 

POXA WAGNER, eu gostaria de acompanhar passo-a-passo a minha consulta, quanto tempo ela levou para chegar ao analisador, definir as rotas de recuperação de dados, ou mesmo, quanto tempo levou para ela abrir a tabela...CALMA!!

 

Emita o seguinte comando e analise os resultados, tente interpretar cada coluna:

 

mysql> SHOW profile FOR query 1;

 

O resultado pode ser algo parecido com isso:

 

+--------------------+------------+
| STATUS             | Duration   |
+--------------------+------------+
| (initialization)   | 0.00006300 |
| Opening TABLES     | 0.00001400 |
| System LOCK        | 0.00000600 |
| TABLE LOCK         | 0.00001000 |
| init               | 0.00002200 |
| optimizing         | 0.00001100 |
| statistics         | 0.00009300 |
| preparing          | 0.00001700 |
| executing          | 0.00000700 |
| Sending DATA       | 0.00016800 |
| end                | 0.00000700 |
| query end          | 0.00000500 |
| freeing items      | 0.00001200 |
| closing TABLES     | 0.00000800 |
| logging slow query | 0.00000400 |
+--------------------+------------+
15 rows IN SET (0.00 sec)

 

Agora, sugiro que você faça seus testes, por exemplo:

 

- Qual engine, na minha tabela X é mais rápida para recuperar dados?

- Qual engine, na minha tabela X é mais rápida para atualizar dados?

- Qual engine, na minha tabela X é mais rápida para inserir dados?

- Qual engine, na minha tabela X é mais rápida para excluir dados?

 

Bom gente, espero que tenham gostado, esse recurso é de grande valia para administradores de bancos de dados e administradores de ambiente de TI.

 

Um abraço à todos!!! http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif

[cassitos 2]

Simplesmente sensacional!

http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif