join_buffer_size = 4 M não é recomendado?

Question

Eu recebo esta mensagem do MysqlTunner.pl:

join_buffer_size >= 4 M This is not advised

Por outro lado, eu li no guia my.cnf do Debian sobre jont_buffer_size que:

This buffer is used for the optimization of full JOINs (JOINs without indexes). Such JOINs are very bad for performance in most cases anyway, but setting this variable to a large value reduces the performance impact. See the "Select_full_join" status variable for a count of full JOINs. Allocated per thread if full join is found

Então eu estou querendo saber qual deles devo acreditar? Atualmente, configurei join_buffer_size = 64M como parte dos esforços para lidar com o problema de escalabilidade de um site de alto tráfego cujas consultas não são particularmente otimizadas. Eu aprecio suas dicas sobre isso.

    

Answer 1

join_buffer_size = 64MB é meio louco, são + 64MB alocados para cada novo tópico.

The size of the buffer that is used for plain index scans, range index scans, and joins that do not use indexes and thus perform full table scans. Normally, the best way to get fast joins is to add indexes. Increase the value of join_buffer_size to get a faster full join when adding indexes is not possible.

Eu diria que você deve reduzir join_buffer_size para um valor entre 128K e 256K ao adicionar índices às suas tabelas e usar a memória que acabou de salvar para aumentar key_buffer_size > + 10x.

Mais memória nem sempre se traduz em mais velocidade, exemplos comuns: sort_buffer_size , read_buffer_size , read_rnd_buffer_size e table_open_cache . Google.

    

Answer 2

Ambos parecem estar dizendo a mesma coisa para mim. Ambos estão dizendo que FULL JOINS são ruins .

• Mysqltuner está apontando que algo sobre o seu sistema é ruim, neste caso ter um grande buffer de junção é um sinal de que você tem algo ruim sobre o seu banco de dados.
• A documentação está dizendo que é ruim, mas se você não puder alterar seu código, adicionar mais memória permitirá que você aceite a maldade.

Você verificou a variável Select_full_join ? Você está realmente vendo esse aumento de contador? Tem certeza de que corrigir o código ou gritar com as pessoas responsáveis por corrigi-lo não é uma opção?

    

Answer 3

Não aumente os buffers por conexão!

Nem todos os buffers no my.cnf são alocados apenas uma vez para a instância do servidor. Alguns buffers são alocados para cada conexão. Por favor, veja mais informações em link :

Citação:

Buffers such as join_buffer_size, sort_buffer_size, read_buffer_size and read_rnd_buffer_size are allocated per connection. Therefore a setting of read_buffer_size=1M and max_connections=150 is asking MySQL to allocate – from startup – 1MB per connection x 150 connections. For more than a decade the default remains at 128K. Increasing the default is not only a waste of server memory, but often does not help performance. In nearly all cases its best to use the defaults by removing or commenting out these four buffer config lines. For a more gradual approach, reduce them in half to free up wasted RAM, keep reducing them towards default values over time. I’ve actually seen improved throughput by reducing these buffers. But there’s really no performance gains from increasing these buffers except in cases of very high traffic and/or other special circumstances. Avoid arbitrarily increasing these!

A velocidade do acesso à memória

Ao contrário da lógica comum, o acesso à memória não é O (1).

Mais RAM você tem, mais lento é o acesso a qualquer dado nesta RAM.

Portanto, usar menos memória RAM pode fornecer acesso mais rápido à RAM - esta é uma regra geral, não se aplica apenas ao MySQL. Por favor, veja O Mito da RAM - por que uma memória aleatória é lida? (√N)

Agora vamos voltar ao MySQL join_buffer_size.

Ajustando o MySQL join_buffer_size

The join_buffer_size is allocated for each full join between two tables. From MySQL’s documentation the join_buffer_size is described as: “The minimum size of the buffer that is used for plain index scans, range index scans, and joins that do not use indexes and thus perform full table scans.” It goes on to say: “Memory allocation time can cause substantial performance drops if the global size is larger than needed by most queries that use it.” The join buffer is allocated to cache table rows when the join can’t use an index. If your database(s) suffer from many joins performed without indexes it cannot be solved by just increasing join_buffer_size. The problem is “joins performed without indexes” and thus the solution for faster joins is to add indexes.

Altere a configuração do MySQL para registrar as consultas sem índices, para que você possa encontrar essas consultas e adicionar índices e / ou modificar o aplicativo que envia essas consultas incorretas. Você deve habilitar "log-queries-não-usando-índices" Em seguida, procure por associações não indexadas no log de consultas lentas.

    

Answer 4

Eu não penso assim. Seu provável mysqltuner sugere que você faça a configuração com base nas configurações necessárias. se eu executar o mysqltuner no servidor de banco de dados. aqui é recomendação que eu recebo:

Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    join_buffer_size (> 64.0M, or always use indexes with joins)
    innodb_buffer_pool_size (>= 54G) if possible.
    innodb_log_file_size should be (=2G) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

Então, acho que nem sempre é um tamanho ruim em outro servidor e precisa.

    

Answer 5

O JOINS sem o INDEXES deve ser resolvido com análise e criação de índice apropriado.

Use mysqlcalculator.com com seu join_buffer_size para ver os efeitos nos requisitos de memória. Deve demorar menos de 1 minuto do seu tempo para um resultado dramático.