XOOPS Brasil

 

5.5. Otimizando o Servidor MySQL

5.5.1. Sintonia dos Parâmetros em Tempo de Sistema/Compilação e na Inicialização

Nós iniciamos com o fator do nível do sistema pois algumas destas decisões devem ser feitas bem cedo. Em outros casos uma rápida olhada para esta seção pode satisfazer porque ela não é tão importante para os grandes ganhos. Entretanto, é sempre bom ter ter noções de como você pode obter melhorias alterando coisas neste nível.

Qual sistema operacional a usar é realmente importante! Para obter o melhor uso de máquinas com múltiplas CPUs você deve utilizar Solaris (porque a sua implemetação das threads funcionam muito bem) ou Linux (porque o kernel 2.2 tem suporte SMP muito bom). Também, em Linux mais antigos temos o limite de tamanho de arquivo de 2G por padrão. Se você tem tal kernel e precisa desesperadamente de trabalhar com arquivos maiores que 2G em máquinas intel Linux, você deve obter o patch LFS para o sistema de arquivos ext2. Outros sistemas de arquivo como ReiserFS e XFS não possuem esta limitação de 2G.

Como ainda não temos o MySQL em produção em muitas outras plataformas, nós aconselhamos que você teste a plataforma pretendida antes de escolhe-la, se possível.

Outras dicas:

  • Se você possui RAM suficiente, você pode remover todos os dispositivos de troca. Alguns sistemas operacionais irão utilizar um disposotico de troca em alguns contextos, mesmo se você possuir memória livre.

  • Utilize a opção do MySQL --skip-external-locking para evitar locks externos. Perceba que isto não irá afetar a funcionalidade do MySQL se você estiver executando um único servidor. Apenas lembre-se de desligar o servidor (ou travar as partes relevantes) antes de executar myisamchk. Em alguns sistemas esta opção é obrigatório porque o lock externo não funcionam em nenhum caso.

    A opção --skip-external-locking está ligada por padrão a partir do MySQL 4.0. Antes disto, era ligada por padrão quando compilando com MIT-pthreads, porque flock() não é totalmente suportado pelas MIT-pthreads em todas plataformas. É também o padrão para Linux pois o bloqueio de arquivos no Linux não é muito seguro.

    O único caso que você não pode utilizar --skip-external-locking é se você precisa de vários servidores MySQL (não clientes) acessando os mesmos dados, ou executar myisamchk na tabela sem dizer ao servidor para descarregar e travar as tabelas primeiro

    Você pode continuar usando LOCK TABLES/UNLOCK TABLES mesmo se você estiver utilizando --skip-external-locking.

5.5.2. Parâmetros de Sintonia do Servidor

Você pode determinar tamanho padrão do buffer usados pelo servidor mysqld com este comando:

shell> mysqld --help

Este comando produz uma lista de todas as opções do mysqld e variáveis configuráveis. A saída inclui os valores padrão das variáveis e se parece com isto:

back_log current value: 5
bdb_cache_size current value: 1048540
binlog_cache_size current value: 32768
connect_timeout current value: 5
delayed_insert_timeout current value: 300
delayed_insert_limit current value: 100
delayed_queue_size current value: 1000
flush_time current value: 0
interactive_timeout current value: 28800
join_buffer_size current value: 131072
key_buffer_size current value: 1048540
lower_case_nome_tabelas current value: 0
long_query_time current value: 10
max_allowed_packet current value: 1048576
max_binlog_cache_size current value: 4294967295
max_connections current value: 100
max_connect_errors current value: 10
max_delayed_threads current value: 20
max_heap_table_size current value: 16777216
max_join_size current value: 4294967295
max_sort_length current value: 1024
max_tmp_tables current value: 32
max_write_lock_count current value: 4294967295
myisam_sort_buffer_size current value: 8388608
net_buffer_length current value: 16384
net_retry_count current value: 10
net_read_timeout current value: 30
net_write_timeout current value: 60
read_buffer_size current value: 131072
record_rnd_buffer_size current value: 262144
slow_launch_time current value: 2
sort_buffer current value: 2097116
table_cache current value: 64
thread_concurrency current value: 10
tmp_table_size current value: 1048576
thread_stack current value: 131072
wait_timeout current value: 28800

Se existir um servidor mysqld em execução, você pode ver quais valores ele está usando atualmente para as variáveis executando esta instrução:

mysql> SHOW VARIABLES;

Você também pode ver algumas estatísticas e indicadores de status para um servidor em execução executando este comando:

mysql> SHOW STATUS;

Para encontrar uma descrição completa de todas as variáveis na seção SHOW VARIABLES neste manual. Veja mais informações sobre isto na Seção 4.6.8.4, “SHOW VARIABLES.

Para informação sobre variáveis de estado, veja Seção 4.6.8.3, “SHOW STATUS.

Variáveis de servidor e informação de status também pode ser obtido usando mysqladmin:

shell> mysqladmin variables
shell> mysqladmin extended-status

O MySQL utiliza algorítmos que são muito escaláveis, portanto, normalmente você pode trabalhar com pouca memória. Entretanto, se você fornecer ao MySQL mais memória, obterá um desempenho melhor.

Quando estiver ajustando um servidor MySQL, as duas variáveis mais importantes que devem ser usadas são key_buffer_size e table_cache. Você deve se sentir confiante que as duas estejam corretas antes de tentar alterar qualquer outra variável.

Os seguintes exemplos indicam alguns valores típicos de variáveis para diferentes configurações de tempo de execução. Os exemplos usam o script mysqld_safe e usam a sintaxe --name=value para definir a variável name com o valor value. Esta sintaxe está disponível a partir do MySQL 4.0. Para versões mais antigas do MySQL, tome as seguintes diferenças nas contas:

  • Use safe_mysqld em vez de mysqld_safe.

  • Configure as variáveis usando a sintaxe --set-variable=name=value ou -O name=value

  • Para nomes de variáveis que finalizam em _size, você pode precisar especificá-las sem _size. Por exemplo, o nome antigo para sort_buffer_size é sort_buffer. O nome antigo para read_buffer_size é record_buffer. Para ver quais variáveis a versão do seu servidor reconhece, use mysqld --help.

Se você possui pelo menos 256M de memória e várias tabelas e deseja obter o melhor desempenho com um número moderado de clientes, deve utilizar algo como:

shell> mysqld_safe --key_buffer_size=64M --table_cache=256 \
--sort_buffer_size=4M --read_buffer_size=1M &

Se possui apenas 128M de memória e apenas algumas poucas tabelas, mas ainda deseja realizar várias ordenações, você pode utilizar:

shell> mysqld_safe --key_buffer_size=16M --sort_buffer_size=1M

Se você possuir pouca memória e tiver muitas conexões, utilize algo como:

shell> mysqld_safe --key_buffer_size=512K --sort_buffer_size=100K \
--read_buffer_size=100K &

ou mesmo isto:

shell> mysqld_safe --key_buffer_size=512K --sort_buffer_size=16K \
--table_cache=32 --read_buffer_size=8K -O net_buffer_length=1K &

Se você estiver executando um GROUP BY ou ORDER BY em tabelas que são muito maiores que sua memória disponível você deve aumentar o valor de record_rnd_buffer_size para acelerar a leitura de registros após a operação de ordenação.

Quando você tiver instalado o MySQL, o diretório support-files irá conter alguns arquivos exemplos do my.cnf, my-huge.cnf, my-large.cnf, my-medium.cnf e my-small.cnf, você pode usá-los como base para otimizar seu sistema.

Se você possui várias conexões simultâneas, ``problemas de trocas'' podem ocorrer a menos que o mysqld tenha sido configurado para usar muito pouca memória para cada conexão. O mysqld tem melhor performance se você tiver memória suficiente para todas as conexões, é claro.

Perceba que se você especifica uma opção na linha de comando para o mysqld, ou mysqld_safe ele permanece em efeito somente para aquela chamada do servidor. Para usar a opção toda vez que o servidor executa, coloque-o em um arquivo de opção.

Para ver os efeitos de uma alteração de parâmetro, faça algo como:

shell> mysqld --key_buffer_size=32m --help

Tenha certeza que a opção --help seja a última do comando; de outra forma o efeito de qualquer opções listadas depois na linha de comando não serão refletidas na saída.

5.5.3. Como a Compilação e a Ligação Afetam a Velocidade do MySQL

A maioria dos testes seguintes são feitos no Linux com os benchmarks do MySQL, mas eles devem fornecer alguma indicação para outros sistemas operacionais e workloads.

Você obtêm um executável mais veloz quando ligado com -static.

No Linux, você irá obter o código mais rápido quando compilando com pgcc e -03. Para compilar sql_yacc.cc com estas opções, você precisa de cerca de 200M de memória porque o gcc/pgcc precisa de muita memória para criar todas as funções em linha. Também deve ser configurado o parâmetro CXX=gcc para evitar que a biblioteca libstdc++ seja incluida (não é necessária). Perceba que com algumas versões do pgcc, o código resultante irá executar somente em verdadeiros processadores Pentium, mesmo que você utilize a opção do compilador para o código resultante que você quer, funcionando em todos os processadores do tipo x586 (como AMD).

Só pelo fato de utilizar um melhor compilador e/ou melhores opções do compilador você pode obter um aumento de desempenho de 10-30% na sua aplicação. Isto é particularmente importante se você mesmo compila o servidor SQL!

Nós testamos ambos os compiladores Cygnus Codefusion e o Fujitsu, mas quando os testamos, nenhum dos dois era suficientemente livre de erros para que o MySQL compilasse com as otimizações.

Quando você compila o MySQL deve incluir suporte somente para os conjuntos de caracteres que deseja usar. (Opção --with-charset=xxx). As distribuições binárias padrão do MySQL são compiladas com suporte para todos os conjuntos de caracteres.

Segue uma lista de algumas medidas que temos feito:

  • Se você utiliza o pgcc e compila tudo com -O6, o servidor mysqld é 1% mais rápido do que com o gcc 2.95.2.

  • Se você liga dinamicamente (sem -static), o resultado é 13% mais lento no Linux. Note que você ainda pode utilizar uma biblioteca do MySQL dinamicamente ligada à sua aplicação cliente. É só o servidor que é crítico para performance.

  • Se você corta seu binário mysqld com strip libexec/mysqld, o binário gerado pode ficar até 4% mais rápido.

  • Para uma conexão de um cliente para um servidor em execução na mesma máquina, se você conecta utilizando TCP/IP em vez de utilizar um arquivo socket Unix, o rendimento é 7.5% mais lento no mesmo computador. (Se você fizer conexão à localhost, o MySQL irá, por padrão, utilizar sockets).

  • Para conexões TCP/IP de um cliente para um servidor, conectando a um servidor remoto em outra máquina será 8-11% mais lento que conectando ao servidor local na mesma máquina, mesmo para conexões Ethernet de 100M.

  • Quando executar o nosso teste de benchamrk usando conexões seguras (todos os dados crptografados com suporte interno SSL) ele se torna 55% mais lento.

  • Se você compilar com --with-debug=full, a maioria das consultas será 20% mais lentas. Algumas consultas podem demorar muito mais tempo (por exemplo, os benchmarks do MySQL demonstram 35% de perda). Se utilizar --with-debug, a queda será de apenas 15%. Para uma versão do mysqld compilada com --with-debug=full, você pode desabilitar a verificação de memória em tempo de execução iniciando-o com a opção --skip-safemalloc. O resultado final neste caso deve estar próximo de quando compilado com --with-debug.

  • Em um Sun UltraSPARC-IIe, Forte 5.0 é 4% mais rápido que gcc 3.2.

  • Em um Sun UltraSPARC-IIe, Forte 5.0 é 4% mais rápido em modo de 32 bits que em modo de 64 bits.

  • Compilando com gcc 2.95.2 para o ultrasparc com a opção -mcpu=v8 -Wa,-xarch=v8plusa melhora a performance em 4%.

  • No Solaris 2.5.1, a MIT-pthreads é 8-12% mais lenta do que as threads nativas do Solaris em um único processador. Com mais carga/CPUs a diferença deve aumentar.

  • Executar com --log-bin deixa o mysqld 1 % mais lento.

  • Compilando no Linux-x86 com gcc sem frame pointers -fomit-frame-pointer ou -fomit-frame-pointer -ffixed-ebp deixa o mysqld 1-4% mais rápido.

A distribuição MySQL-Linux fornecida pela MySQL AB é normalmente compilada com pgcc, mas vamos retornar ao uso do gcc pelo fato de um bug no pgcc que gera o código que não executa no AMD. Continuaremos a usar o gcc até que o bug seja resolvido. Neste meio tempo, se você possui uma máquina que não seja AMD, você pode ter um binário mais rápido compilando com o pgcc. O binário padrão do MySQL para Linux é ligado estaticamente para conseguir mais desempenho e ser mais portável.

5.5.4. Como o MySQL Utiliza a Memória

A lista abaixo indica algumas das maneiras inas quais o servidor mysqld utiliza a memória. Onde aplicável, o nome da variável do servidor relevante ao uso de memória é fornecido:

  • O buffer de chave (variável key_buffer_size) é compartilhado por todas as threads; Outros buffers usados pelo servido são alocados quando necessários. Veja mais informações sobre isto na Seção 5.5.2, “Parâmetros de Sintonia do Servidor”.

  • Cada conexão utiliza algum espaço específico da thread: Uma de pilha (padrão de 64K, variável thread_stack), um buffer de conexão (variável net_buffer_lenght), e um buffer de resultados (variável net_buffer_lenght). Os buffers de conexões e resultados são aumentados dinamicamente para max_allowed_packet quando necessário. Quando uma consulta está sendo executada, uma cópia da string da consulta atual é também alocada.

  • Todas as threads compartilhas a mesma memória base.

  • Somente as tabelas ISAM e MyISAM compactadas são mapeadas em memória. Isto é porque o espaço de memória de 32-bits de 4GB não é grande o bastante para a maioria das grandes tabelas. Quando sistemas com endereçamento de 64-bits se tornarem comuns poderemos adicionar um suporte gieral para o mapeamento de memória.

  • Cada requisição fazendo uma varredura sequencial em uma tabela aloca um buffer de leitura (variável read_buffer_size).

  • Ao ler registros na ordem ``randômica'' (por exemplo, depois de uma ordenação) um buffer de leitura randômico é alocado para evitar pesquisas em disco. (variável read_rnd_buffer_size).

  • Todas as joins são feitas em um único passo, e a maioria delas podem ser feitas mesmo sem usar uma tabela temporária. A maioria das tabelas temporárias são tabelas baseadas em memória (HEAP). Tabelas temporárias com uma grande extensão de registros (calculada como a soma do tamanho de todas as colunas) ou que contenham colunas BLOB são armazenadas em disco.

    Um problema nas versões do MySQL anteriores a 3.23.2 é que se uma tabela HEAP excede o tamanho de tmp_table_size, você recebe o erro The table nome_tabela is full. A partir da versão 3.23.2, isto é tratado alterando automaticamente a tabela em memória HEAP para uma tabela baseada em disco MyISAM quando necessário. Para contornar este problema, você pode aumentar o tamanho da tabela temporária configurando a opção tmp_table_size do mysqld, ou configurando a opção do SQL SQL_BIG_TABLES no progrma cliente. Veja mais informações sobre isto na Seção 5.5.6, “Sintaxe de SET. Na versão 3.20 do MySQL, o número máximo da tabela temporária é record_buffer*16; se você estiver utilizando esta versão, você terá que aumentar o valor record_buffer. Você também pode iniciar o mysqld com a opção --big-tables para sempre armazenar as tabelas temporárias em disco. Entretanto isto afetará a velocidade de várias consultas complicadas.

  • A maioria das requisições que realizam ordenação alocam um bufer de ordenação e 0-2 arquivos temporários dependendo do tamanho do resultado. Veja mais informações sobre isto na Seção A.4.4, “Onde o MySQL Armazena Arquivos Temporários”.

  • Quase todas as análises e cálculos são feitos em um armazenamento de memória local. Nenhuma sobrecarga de memória é necessário para ítens pequenos e a alocação e liberação normal de memória lenta é evitada. A memória é alocada somente para grandes strings inesperadas; isto é feito com malloc() e free().

  • Cada arquivo de índice é aberto uma vez e o arquivo de dados é aberto uma vez para cada thread concorrente. Uma estrutura de tabela, estrutura de coluna para cada coluna e um buffer de tamanho 3 * n é alocado para cada thread concorrente. (onde n é o maior tamanho do registro, sem levar em consideração colunas BLOB. Uma coluna BLOB utiliza de 5 a 8 bytes mais o tamanho dos dados contidos na mesma. O manipulador de tabelas ISAM/MyISAM irão usar um registro extra no buffer para uso interno.

  • Para cada tabela com colunas BLOB, um buffer é aumentado dinamicamente para ler grandes valores BLOB. Se você ler uma tabela, um buffer do tamanho do maior registro BLOB é alocado.

  • Estruturas de manipulacão para todas tabelas em uso são salvos em um cache e gerenciado como FIFO. Normalmente o cache possui 64 entradas. Se uma tabela foi usada por duas threads ao mesmo tempo, o cache terá duas entredas para a tabela. Veja mais informações sobre isto na Seção 5.4.7, “Como o MySQL Abre e Fecha as Tabelas”.

  • Um comando mysqladmin flush-tables fecha (ou instruções FLUSH TABLES) todas tabelas que não estão em uso e marca todas tabelas em uso para serem fechadas quando a thread atualmente em execução terminar. Isto irá liberar efetivamente a maioria da memória em uso.

ps e outros programas de informações do sistema podem relatar que o mysqld usa muita memória. Isto pode ser causado pelas pilhas de threads em diferentes endereços de memória. Por exemplo, a versão do ps do Solaris conta a memória não usada entre as pilhas como memória usada. Você pode verificar isto conferindo a memória disponível com swap -s. Temos testado o mysqld com detectores comerciais de perda de memória, portanto tais perdas não devem existir.

5.5.5. Como o MySQL Utiliza o DNS

Quando um novo cliente conecta ao mysqld, o mysqld extende uma nova thread para lidar com o pedido. Esta thread primeiro confere se o nome da máquina está no cache de nomes de máquinas. Se não, a thread tenta resolver o nome da máquina.

  • Se o sistema operacional suporta as chamadas seguras com thread gethostbyaddr_r() e gethostbyname_r(), a thread as utiliza para fazer a resolução do nome máquina.

  • Se o sistema operacional não suporta as chamadas de threads seguras, a thread trava um mutex e chama gethostbyaddr() e gethostbyname(). Perceba que neste caso nenhuma outra thread pode resolver outros nomes de máquinas que não existam no cache de nomes de máquina até que a primeira thread esteja destrave o mutex.

Você pode desabilitar a procura de nomes de máquinas no DNS iniciando o mysqld com a opção --skip-name-resolve. No entanto, neste caso você só pode usar números IP nas tabelas de privilégio do MySQL.

Se você possuir um DNS muito lento e várias máquinas, pode obter mais desempenho desligando a procura de nomes de máquinas usando a opção --skip-name-resolve ou aumentando HOST_CACHE_SIZE (valor padrão: 128) e recompilar mysqld.

Você pode desabilitar o cache de nomes de máquinas iniciando o servidor com a opção --skip-host-cache. Para limpar a cache do nome de máquinas, envie uma instru;ção FLUSH HOSTS ou execute o comando mysqladmin flush-hosts.

Se você deseja disabilitar as conexões TCP/IP totalmente, inicie o mysqld com a opção --skip-networking.

5.5.6. Sintaxe de SET

SET [GLOBAL | SESSION] sql_variable=expression,
[[GLOBAL | SESSION] sql_variable=expression] ...

SET configura várias opções que afetam a operação do servidor ou seu cliente.

Os seguintes exemplos mostram as diferentes sintaxes que se pode usar para configurar variáveis:

Em versões antigas do MySQL permitiamos o uso da sintaxe SET OPTION, mas esta sintaxe agora está obsoleta.

No MySQL 4.0.3 adicionamos as opções GLOBAL e SESSION e acessamos as variáveis de inicialização mais importantes.

LOCAL pode ser usado como sinôniumo de SESSION.

Se você define diversas variáveis na mesma linha de comando, o último modo GLOBAL | SESSION é utilizado

SET sort_buffer_size=10000;
SET @@local.sort_buffer_size=10000;
SET GLOBAL sort_buffer_size=1000000, SESSION sort_buffer_size=1000000;
SET @@sort_buffer_size=1000000;
SET @@global.sort_buffer_size=1000000, @@local.sort_buffer_size=1000000;

A sintaxe @@nome_variável é suoprtada para tornar a sintaxe do MySQL compatível com outros bancos de dados.

As diferentes variáveis de sistema que podem ser configuradas estão descritas na seção de variáveis de sistema deste manual. Veja mais informações sobre isto na Seção 6.1.5, “Variáveis de Sistema”.

Se você estiver usando SESSION (o padrão) a opção que você definir terá efeito até que o sessão atual finalize ou até que vecê atribua um valor diferente a esta opção. Se você estiver usando GLOBAL, que exige o privilégio SUPER, a opção é lembrada e usada pelas novas conexões até que o servidor reinicie. Se você quiser tornar uma opção permanente, você deve definí-la em um arquivo de opção. Veja mais informações sobre isto na Seção 4.1.2, “Arquivo de Opções my.cnf.

Para evitar o uso incorreto, o MySQL exibirá um erro se você usar SET GLOBAL com uma variável que só pode ser usada com SET SESSION ou se você não estiver usando SET GLOBAL com uma variável global.

Se você quiser definir uma variável SESSION com um valor GLOBAL ou um valor GLOBAL ao valor padrão do MySQL, você pode configurá-lo com DEFAULT.

SET max_join_size=DEFAULT;

Isto é idêntico a:

SET @@session.max_join_size=@@global.max_join_size;

Se você quiser restringir o valor máximo com o qual uma variável de servidor pode ser configurado com o comando SET, você pode especificaá-lo usando a opção de linha de comando --maximum-variable-name. Veja mais informações sobre isto na Seção 4.1.1, “Opções de Linha de Comando do mysqld.

Você pode obter uma lista da maioria das variáveis com SHOW VARIABLES. Veja mais informações sobre isto na Seção 4.6.8.4, “SHOW VARIABLES. Você pode obter o valor de uma variável específica com a sintaxe @@[global.|local.]variable_name:

SHOW VARIABLES like "max_join_size";
SHOW GLOBAL VARIABLES like "max_join_size";
SELECT @@max_join_size, @@global.max_join_size;

Segue aqui a descrição das variáveis que usam uma sintaxe SET não padrão e algumas das outras variáveis. A definição das outras variáveis podem ser encontrados na seção variáveis de sistema, entre as opções de inicialização ou na descrição de SHOW VARIABLES. Veja mais informações sobre isto na Seção 6.1.5, “Variáveis de Sistema”. Veja mais informações sobre isto na Seção 4.1.1, “Opções de Linha de Comando do mysqld. Veja mais informações sobre isto na Seção 4.6.8.4, “SHOW VARIABLES.

  • AUTOCOMMIT= 0 | 1

    Se configurado com 1 todas alterações em uma tabela será feita de uma vez. Para iniciar uma transação de vários comandos, deve ser usada a instrução BEGIN. Veja mais informações sobre isto na Seção 6.7.1, “Sintaxe de START TRANSACTION, COMMIT e ROLLBACK. Se configurado com 0 deve ser usado COMMIT/ROLLBACK para aceitar/recusar aquela transação. Veja mais informações sobre isto na Seção 6.7.1, “Sintaxe de START TRANSACTION, COMMIT e ROLLBACK. Note que quando você altera do modo não-AUTOCOMMIT para AUTOCOMMIT, o MySQL irá fazer um COMMIT automático em quaisquer transações abertas.

  • BIG_TABLES = 0 | 1

    Se definido com 1, todas as tabelas temporárias são armazenadas no disco em vez de o ser na meória. Isto será um pouco mais lento, mas você não terá o erro The table tbl_name is full para grandes operações SELECT que exigem uma tabela temporária maior. O valor padrão para uma nova conexão é 0 (isto é, usa tabelas temporárias em memória) Esta opção era chamada SQL_BIG_TABLES. No MySQL 4.0 você normalmente nunca deve precisar deste parâmetro já que o MySQL converterá automaticamente tabelas em memória para tabelas em disco se isto for necessário.

  • CHARACTER SET nome_conjunto_caracteres | DEFAULT

    Mapeia todas as strings do e para o cliente com o mapa especificado. Atualmente a única opção para character_set_name é cp1251_koi8, mas você pode adicionar novos mapas editando o arquivo sql/convert.cc na distribuição fonte do MySQL. O mapeamento padrão pode ser restaurado utilizando o valor DEFAULT para character_set_name.

    Perceba que a sintaxe para configurar a opção CHARACTER SET é diferente da sintaxe para configurar as outras opções.

  • DATE_FORMAT = format_str

    Determina como o servidor converte valores DATE para strings. Esta variável está disponível como uma opção global, local ou de linha de comando. format_str pode ser especificado convenientemente usando a função GET_FORMAT(). Veja Veja mais informações sobre isto na Seção 6.3.4, “Funções de Data e Hora”.

  • DATETIME_FORMAT = format_str

    Determina como o servidor converte valores DATETIME para string. Esta variável está disponível como uma opção global, local ou de linha de comando. format_str pode ser especificada convenientemente usando a função GET_FORMAT(). Veja Veja mais informações sobre isto na Seção 6.3.4, “Funções de Data e Hora”.

  • INSERT_ID = #

    Configura o valor que será usado pelo comando INSERT ou ALTER TABLE seguinte ao inserir um valor AUTO_INCREMENT. Isto é usado principalmente com o log de atualizações.

  • LAST_INSERT_ID = #

    Configura o valor a ser retornado de LAST_INSERT_ID(). Ele é armazenado no log de atualizações quando você utiliza LAST_INSERT_ID() em um comando que atualiza uma tabela.

  • LOW_PRIORITY_UPDATES = 0 | 1

    Se configurado com 1, todas instruções INSERT, UPDATE, DELETE e LOCK TABLE WRITE irão esperar até que não existam SELECT ou LOCK TABLE READ pendentes na tabela afetada. Esta opção era chamada SQL_LOW_PRIORITY_UPDATES.

  • MAX_JOIN_SIZE = value | DEFAULT

    Não permite que SELECTs que provavelmente necessitem examinar mais que valor combinações de registros. Configurando este valor, você pode obter SELECTs onde chaves não são usadas corretamente e que provavelmente gastarão um bom tempo. Configurando-o para um valor diferente do DEFAULT irá definir o atributo SQL_BIG_SELECTS com o padrão. Se você configurar o atributo SQL_BIG_SELECTS novamente, a variável SQL_MAX_JOIN_SIZE será ignorada. Você pode configurar um valor padrão para esta variável iniciando o mysqld com -O max_join_size=#. Esta opção era chamada SQL_MAX_JOIN_SIZE

    Note que se o resultado da consulta ja estiver na cache de consultas, o verificaição acima não será feita. O MySQL irá enviar o resultado ao cliente. Uma vez que o resultado da consulta já foi consultado e não será responsabilidade do servidor enviar o resultado ao cliente.

  • PASSWORD = PASSWORD('alguma senha')

    Configura a senha para o utilizador atual. Qualquer utilizador que não seja anônimo pode alterar sua própria senha!

  • PASSWORD FOR user = PASSWORD('alguma senha')

    Configura a senha para um utilizador específico no servidor atual. Somente um utilizador com acesso ao banco de dados mysql pode fazer isto. O utilizador deve ser fornecido no formato utilizador@home_maquina, onde utilizador e nome_máquina são exatamente o que estão listados nas colunas User e Host da tabela mysql.user. Por exemplo, se você possui uma entrada com os campos User e Host com 'bob' e '%.loc.gov', você escreveria:

    mysql> SET PASSWORD FOR 'bob'@'%.loc.gov' = PASSWORD('newpass');
    

    Que é equivalente a:

    mysql> UPDATE mysql.user SET Password=PASSWORD('newpass')
    -> WHERE User='bob' AND Host='%.loc.gov';
    mysql> FLUSH PRIVILEGES;
    

  • QUERY_CACHE_TYPE = OFF | ON | DEMAND, QUERY_CACHE_TYPE = 0 | 1 | 2

    Define a configuração da cache de consultas para esta thread. Set query cache setting for this thread.

    OpçãoDescrição
    0 ou OFFNão armazena ou recupera resultados.
    1 ou ONArmazena todos os resultados, exceto consultas SELECT SQL_NO_CACHE ....
    2 ou DEMANDArmazena apenas consultas SELECT SQL_CACHE ....
  • SQL_AUTO_IS_NULL = 0 | 1

    Se configurado com 1 (padrão) o último registro inserido em uma tabela com um regitro auto_incremnto pode ser encontrado com a seguinte construção: WHERE auto_increment_column IS NULL. Isto é usado por alguns programas ODBC como o Access.

  • SQL_BIG_SELECTS = 0 | 1

    Se configurado com 0, o MySQL aborta as instruções SELECTs que provavelmente levam muito tempo (isto é, instruções para as quais o otimizador estima que o número de registros examinados provavelmente irá exceder o valor de MAX_JOIN_SIZE. Isto é útil quando uma instrução WHERE não aconselhada for utilizado. O valor padrão para uma nova conexão é 1 (que permitirá qualquer instrução SELECT).

    Se você definir MAX_JOIN_SIZE com um valor diferente de DEFAULT, SQL_BIG_SELECTS será definida com 0.

  • SQL_BUFFER_RESULT = 0 | 1

    SQL_BUFFER_RESULT força para que o resultado das SELECT's seja colocado em tabelas temporárias. Isto irá ajudar o MySQL a liberar mais cedos bloqueios de tabela e ajudarão em casos onde elas ocupam muito tempo para enviar o conjunto de resultados para o cliente.

  • SQL_SAFE_UPDATES = 0 | 1

    Se configurado com 1, o MySQL irá aborar se tentarmos fazer um UPDATE ou DELETE sem utilizar uma chave ou LIMIT na cláusula WHERE. Desta forma é possível capturar atualizações erradas ao criarmos comandos SQL manualmente.

  • SQL_SELECT_LIMIT = valor | DEFAULT

    O número máximo de registros para retornar de instruções SELECT. Se uma SELECT tem uma cláusula LIMIT, o LIMIT tem precedêencia sobre o valor de SQL_SELECT_LIMIT. O valor padrão para uma nova conexão é ``unlimited'' (ilimitado). Se você alterou o limite, o valor padrão pode ser restaurado atribuindo o valor DEFAULT a SQL_SELECT_LIMIT.

  • SQL_LOG_OFF = 0 | 1

    Se configurado com 1, nenhum registro será feito no log padrão para este cliente, se o cliente tiver o privilégio SUPER.

  • SQL_LOG_BIN = 0 | 1

    Se configurada com 0, nenhum registro é feito no log binário para o cliente, se o cliente tiver o privilégio SUPER.

  • SQL_LOG_UPDATE = 0 | 1

    Se configurado com 0, nenhum registro será feito no log de atualizações para o cliente, se o cliente tiver o privilégio SUPPER. Esta variável está obsoleta a partir da versão 5.0.

  • SQL_QUOTE_SHOW_CREATE = 0 | 1

    Se configurado com 1, SHOW CREATE TABLE irá colocar os nomes de tabela e colunas entre aspas. Está ligado por padrão, para que replicação de tabelas com nomes de colunas estranhos funcione. Seção 4.6.8.8, “SHOW CREATE TABLE.

  • TIMESTAMP = valor_timestamp | DEFAULT

    Configura a hora/data para este cliente. É usado para obter a hora e data original se você utiliza o log de atualizações para restaurar registros. valor_timestamp deve ser um timestamp UNIX Epoch, não um timestamp MySQL.

  • TIME_FORMAT = format_str

    Determina como o servidor converte valores TIME para string. Esta variável está disponível como uma opção global, local ou de linha de comando. format_str pode ser especificada convenientemente usando a função GET_FORMAT(). Veja Veja mais informações sobre isto na Seção 6.3.4, “Funções de Data e Hora”.