Captura de queries lentas

No MariaDB as informações sobre as queries lentas estão mais completas e nos possibilitando mais opções para seu controle, a seguir veremos o que há de novo no MariaDB e suas diferenças no MySQL.

Em primeiro lugar vamos visualizar quatro variáveis que serão responsáveis por auxiliar no log das queries lentas, em seu cliente digite os seguintes comandos.

mysql> select @@log_slow_verbosity;
mysql> select @@log_slow_filter;
mysql> select @@log_slow_rate_limit;

Estas são as quatro variáveis que devemos definir de acordo com as explicações abaixo e de acordo com a necessidade de filtragem das queries lentas:


log_slow_verbosity; a verbosidade de informações que você deseja que seja logado quando ocorrer uma querie lenta.
Os valores para log_slow_verbosity podem ser: Query_plan, para o log sobre o planejamento de execução da query, isto inclui

* Full_scan,
* Full_join,
* Tmp_table,
* Tmp_table_on_disk,
* Filesort,
* Filesort_on_disk
* Merge_passes during sorting

Múltiplos valores podem ser usados e separados com (,) (vírgula).
O valor padrão é vazio para manter a compatibilidade com o MySQL 5.1


log_slow_filter; você pode definir quais queries irão para o log de queries lentas definindo os valores de acordo com a seguir:

* admin; irá logar comandos administrativos como CREATE, OPTIMIZE, DROP etc.
* filesort; se usar filesort
* filesort_on_disk; caso o comando use filesort que necessite de tabelas temporárias no disco
* full_join; loga comandos que não use index em tabelas pertencentes ao JOIN
* full_scan; quando for utilizado o escaneamento total das tabelas, full scan table
* query_cache; loga comandos que serão resolvidos pelo query cache
* query_cache_miss; loga comandos que não são resolvidos pelo query cache
* tmp_table;loga comandos que utilizam tabelas temporárias na memória
* tmp_table_on_disk; loga comandos que utilizam tabelas temporárias no disco


log_slow_rate_limit; limita a quantidade de queries que serão logadas, quando 1 apenas uma query será logada,
isso facilita no momento de debugging evitando muita informação quando não necessária.

Vamos então a um exemplo de como ficará nosso arquivo de log executando uma query que leve mais de 1 segundos (propositadamente) para liberar o resultado.

O primeiro passo é ativar nosso log de queries lentas com o seguinte comando:

SET GLOBAL log_slow_queries=1;

Em seguida definir nossa variável long_query_time como a seguir:

SET long_query_time=1;

Vamos definir as novas variáveis no MariaDB que acabamos de ver:

mysql> set log_slow_verbosity='query_plan';
Query OK, 0 rows affected (0.00 sec)

mysql> set log_slow_filter='full_scan';
Query OK, 0 rows affected (0.01 sec)

Em seguida utilizando o banco de dados world, o mais famoso para testes no MySQL iremos executar a seguinte query:

SELECT p.Code AS `Cód País`, p.Name AS `Nome País`,
(SELECT MAX(population) FROM City WHERE p.Code = countrycode) AS `Populacao`,
(SELECT name FROM City WHERE p.Code = countrycode ORDER BY Population DESC LIMIT 1) AS `Cidade Mais Populosa`,
l.Language AS `Língua Oficial`,
l.Percentage AS `%`
FROM Country AS p
JOIN CountryLanguage AS l ON p.Code = l.CountryCode AND l.isofficial = 'T'
WHERE p.Code IN(SELECT Code FROM Country WHERE (Continent='Asia' OR Continent='Europe')
AND GovernmentForm = 'Republic')
ORDER BY Continent;

Após o resultado podemos verificar o que foi gravado em nosso arquivo de log gravado no diretório escolhido para gravar os logs de queries lentas:


TCP Port: 3306, Named Pipe: MySQL
Time Id Command Argument
# Time: 100614 17:14:17
# User@Host: root[root] @ localhost [127.0.0.1]
# Thread_id: 1 Schema: world QC_hit: No
# Query_time: 1.872003 Lock_time: 0.000000 Rows_sent: 62 Rows_examined: 507204
# Full_scan: Yes Full_join: No Tmp_table: Yes Tmp_table_on_disk: No
# Filesort: Yes Filesort_on_disk: No Merge_passes: 0
use world;
SET timestamp=1276546457;
SELECT p.Code AS `C¢d Pa¡s`, p.Name AS `Nome Pa¡s`,
(SELECT MAX(population) FROM City WHERE p.Code = countrycode) AS `Populacao`,
(SELECT name FROM City WHERE p.Code = countrycode ORDER BY Population DESC LIMIT 1) AS `Cidade Mais Populosa`,
l.Language AS `L¡ngua Oficial`,
l.Percentage AS `%`
FROM Country AS p
JOIN CountryLanguage AS l ON p.Code = l.CountryCode AND l.isofficial = 'T'
WHERE p.Code IN(SELECT Code FROM Country WHERE (Continent='Asia' OR Continent='Europe')
AND GovernmentForm = 'Republic')
ORDER BY Continent;

Bem, esta é uma forma de sabermos qual query está lenta em nosso sistema com mais recursos agora no MariaDB. Atá a próxima.

Armazenar endereços IP como tipos inteiros

Neste artigo irei explicar qual a principal vantagem de armazenarmos endereços IP como tipo inteiro.

Para que você possa entender melhor vamos criar uma tabela simples de forma que possamos armazenar algum endereço IP utilizando o tipo CHAR.

CREATE DATABASE exemplo;
USE exemplo;
CREATE TABLE log(id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
                                 usuario CHAR(30), visitas INT, ip CHAR(15)

Vamos inserir alguns registros nesta tabela.

INSERT INTO exemplo VALUES(null, 'douglas', 10, '192.168.10.10');
INSERT INTO log VALUES(null, 'luciana', 10, '200.213.162.161');
INSERT INTO log VALUES(null, 'alberto', 10, '213.187.0.1');

Bem, por enquanto temos tres registros em nossa tabela, começaremos nossa primeira análise.

Qual o tamanho ocupado pela coluna IP ?

Utilizando a função LENGTH do MySQL que nos retorna o tamanho utilizado por cada byte baseado no CHARSET utilizado temos:

SELECT LENGTH(IP) FROM log; ==> 15 bytes

Como resultado a este comando temos um custo total de 15 bytes, como nosso tipo para esta coluna é um CHAR que ocupa uma posição fixa então temos uma utilização de 15 bytes mesmo para um IP 1.1.1.1

Armazenando endereço IP com tipos String teremos um maior custo em disco e mais tempo será preciso para buscar um determinado registro, mas então como podemos economizar utilizando inteiros ?

Em primeiro lugar temos que fazer uma pequena alteração em nossa tabela onde o campo que armazenará o endereço IP seja do tipo UNSIGNED INT

Após esta alteração poderemos utilizar duas funções para armazenar o registro e outra quando precisamos recuper este.

Veja o exemplo:

INET_ATON('192.168.0.1'); ==> 3232235521

SELECT INET_NTOA(3232235521); ==> 192.168.0.1

Nossa tabela desta forma se tornará menos dispendiosa no que se refere ao armazenamento e muito mais rápida ao se procurar por um determinado registro.

Até a próxima.