Link original deste artigo: https://blog.csdn.net/xzk9381/article/details/114872726
1. Solução de bloqueio de thread MySQL 5.7
1.1 Descrição do problema
Um erro é relatado ao executar a instrução no banco de dados: ERROR 1205 (HY000): Tempo limite de espera de bloqueio excedido; tente reiniciar a transação.
1.2 Solução
- Ver os tópicos no banco de dados atual
show full processlist;
- Se você não vê o segmento de registro sql lento sendo executado, verifique a tabela de transação INNODB_TRX para ver se há um segmento de transação que está bloqueado e veja se trx_mysql_thread_id está no segmento de suspensão na lista de processos completa da exibição. isso prova que a transação da thread deste sleep foi travada sem commit ou rollback, precisamos matá-la manualmente, por exemplo, kill 32735
2. O MySQL 5.7 é lento ao se conectar ao banco de dados remotamente
2.1 Descrição do problema
Use o comando mysql para acessar remotamente o banco de dados. Após inserir a senha, você precisa esperar 5s-10s para completar a conexão, fazendo com que o serviço de segundo plano lance uma exceção.
2.2 Causas do problema
Cada vez que acessar o banco de dados, o mysql tentará resolver o nome de domínio da máquina acessada.Se não puder ser resolvido neste momento, ele falhará após um tempo antes que os dados possam ser recuperados.
2.3 Solução
Adicione o item de configuração skip-name-resolve em [mysqld] no arquivo de configuração mysql para proibir a resolução de nome de domínio e reinicie o banco de dados para ter efeito
3. Erro de instalação binária do MySQL 5.7
3.1 Descrição do problema
Use o pacote de instalação binário para instalar o MySQL 5.7 em centos6.8 (instalação mínima) e relatar um erro:
erro ao carregar bibliotecas compartilhadas: libaio.so.1: não é possível abrir o arquivo de objeto compartilhado: Não existe esse arquivo ou diretório
3.2 Solução
A biblioteca libaio não é instalada por padrão durante a instalação mínima do CentOS, e você precisa instalá-la manualmente
yum install libaio-devel
4. Solução para o problema de dados truncados usando a função concat de grupo no MySQL 5.7
4.1 Descrição do problema
Quando a função GROUP_CONCAT é chamada para consulta, a consulta não para e não retorna nenhum dado (também há uma situação em que os dados consultados são truncados e o comprimento mais longo não excede 1024 bytes)
4.2 Causa do problema
A razão para este problema é que a configuração oficial padrão group_concat_max_len é 1024, o que limitará o comprimento dos dados GROUP_CONCAT. Você pode usar o seguinte comando para consultar:
mysql> show variables like 'group_concat_max_len';
+----------------------+--------+
| Variable_name | Value |
+----------------------+--------+
| group_concat_max_len | 1024 |
+----------------------+--------+
1 row in set (0.05 sec)
# 官方手册对该配置的定义是：The maximum permitted result length in bytes for the GROUP_CONCAT() function
4.3 Solução
Você pode ajustar group_concat_max_len para o valor máximo de 18446744073709551615 (ou definir de acordo com o comprimento máximo do retorno real do negócio)
- Modifique o arquivo de configuração do MySQL, adicione group_concat_max_len = 18446744073709551615 (efetivo permanente) em [mysqld]
- Definido no console (temporariamente efetivo)
SET GLOBAL group_concat_max_len=18446744073709551615;
SET SESSION group_concat_max_len=18446744073709551615;
5. MySQL 报 ERROR: O pacote de consulta é muito grande (2034> 1024)
5.1 Descrição do problema
Um erro é relatado quando os dados são armazenados:
ERRO: o pacote para consulta é muito grande (2034> 1024). Você pode alterar este valor no servidor definindo a variável max_allowed_packet '.
5.2 Solução
- Use o seguinte comando para ver a configuração max_allowed_packet no banco de dados atual
mysql> show variables like '%max_allowed_packet%';
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| max_allowed_packet | 1024 |
| slave_max_allowed_packet | 1073741824 |
+--------------------------+------------+
2 rows in set (0.00 sec)
# 这里显示max_allowed_packet的大小只有1M
- Adicione ou modifique max_allowed_packet = 128M no arquivo de configuração my.cnf [mysqld] e reinicie o mysql para ter efeito. Se o valor de max_allowed_packet for restaurado para 1024 após um período de tempo, você precisará consultar se a memória do servidor atual é insuficiente, o que fará com que o MySQL redefina automaticamente o parâmetro para 1024 e reserve memória suficiente para resolver o problema.
6. Solução de erro do MySQL 5.7 "Waiting for table metadata lock"
6.1 Descrição do problema
Ao realizar operações DDL como alt table no MySQL 5.7, a operação é bloqueada e não pode ser executada.Use show processlist para ver e descobrir que a operação alt table da tabela mostra Waiting for table metadata lock.
6.2 Causa do problema
Ao realizar operações DDL, como tabela alt no MySQL 5.7, se houver transações não confirmadas na tabela, o estado de bloqueio de metadados da tabela Aguardando aparecerá
6.3 Solução
- Use o seguinte comando para visualizar as transações não confirmadas de information_schema.innodb_trx. Geralmente, enquanto esses threads forem eliminados, as operações DDL não estarão Aguardando bloqueio de metadados da tabela
select trx_state, trx_started, trx_mysql_thread_id, trx_query from information_schema.innodb_trx \G
# 字段说明：
# trx_state: 事务状态，一般为RUNNING
# trx_started: 事务执行的起始时间，若时间较长，则要分析该事务是否合理
# trx_mysql_thread_id: MySQL的线程ID，用于kill
# trx_query: 事务中的sql
- Ajuste o limite de tempo limite de bloqueio. lock_wait_timeout representa o tempo limite (em segundos) para adquirir o bloqueio de metadados e o intervalo de valor permitido é de 1 a 31536000 (1 ano). O valor padrão é 31536000, ajuste-o para 30 minutos
set session lock_wait_timeout = 1800;
set global lock_wait_timeout = 1800;
Link original deste artigo: https://blog.csdn.net/xzk9381/article/details/114872726
7. Solução para o erro 1418 do MySQL (HY000)
7.1 Descrição do problema
Depois que o MySQL abre bin-log, um erro com o número de erro 1418 ocorrerá ao chamar procedimentos armazenados ou funções e gatilhos:
ERROR 1418 (HY000): Esta função não tem DETERMINISTIC, NO SQL ou READS SQL DATA em sua declaração e o registro binário está habilitado (você pode querer usar a variável log_bin_trust_function_creators menos segura)
7.2 Causa do problema
Porque CREATE PROCEDURE, CREATE FUNCTION, ALTER PROCEDURE, ALTER FUNCTION, CALL, DROP PROCEDURE, DROP FUNCTION e outras instruções serão gravadas no log binário e depois executadas no servidor escravo. No entanto, uma sub-rotina indeterminada (procedimento armazenado, função, gatilho) que executa uma atualização não é repetível. A execução no servidor escravo (em relação ao servidor mestre é a execução repetida) pode fazer com que os dados restaurados sejam diferentes dos dados originais. situação em que o servidor é diferente do servidor principal.
Para resolver este problema, o MySQL determina que no servidor principal, a menos que o subprograma seja declarado determinístico ou não mude os dados, a criação ou substituição do subprograma será rejeitada. Isso significa que ao criar uma sub-rotina, você deve declarar que ela é determinística ou que não altera os dados.
Existem duas maneiras de declarar:
- A declaração é determinística: DETERMINISTIC e NOT DETERMINISTIC indicam se uma sub-rotina sempre produz o mesmo resultado para uma determinada entrada. Se nenhum recurso for fornecido, o padrão é NOT DETERMINISTIC, então DETERMINISTIC deve ser especificado explicitamente para declarar que uma sub-rotina é determinística. O que quero explicar aqui é: usar a função NOW () (ou seus sinônimos) ou a função RAND () não tornará uma sub-rotina não determinística. Para NOW (), o log binário inclui um carimbo de data / hora e será executado corretamente. RAND () pode ser copiado corretamente, desde que seja chamado uma vez em uma sub-rotina. Portanto, pode-se considerar que o timestamp e a semente do número aleatório são entradas determinísticas para a sub-rotina, e são iguais no servidor mestre e no servidor escravo.
- Declare se os dados serão alterados: CONTAINS SQL, NO SQL, READS SQL DATA, MODIFIES SQL é usado para indicar se a sub-rotina lê ou grava dados.
Ambos NO SQL e READS SQL DATA indicam que a sub-rotina não altera os dados, mas um deles deve ser especificado explicitamente, porque se algum for especificado, a especificação padrão é CONTAINS SQL.
Em outras palavras, quando bin-log está ativado, você deve especificar se a função criada é dos seguintes tipos:
- DETERMINISTIC: Incerto
- SEM SQL: não há instrução SQl e, claro, os dados não serão modificados
- READS SQL DATA: apenas leia os dados, é claro que não irá modificar os dados
- MODIFICA DADOS SQL: Para modificar os dados
- CONTAINS SQL: contém instruções SQL
Por padrão, se as instruções CREATE PROCEDURE ou CREATE FUNCTION puderem ser aceitas, um de DETERMINISTIC ou NO SQL e READS SQL DATA deve ser especificado explicitamente, caso contrário, um erro 1418 será gerado.
7.3 Solução
Existem duas soluções:
- Ao criar uma sub-rotina (procedimento armazenado, função, gatilho), declare-o como DETERMINISTIC ou NO SQL e READS SQL DATA
CREATE DEFINER = CURRENT_USER PROCEDURE `NewProc`()
DETERMINISTIC
BEGIN
#Routine body goes here...
END;
- Confie no criador da sub-rotina, proíba o requisito de autoridade SUPER ao criar ou modificar a sub-rotina, defina log_bin_trust_routine_creators = 1
# 方法1，在mysql控制台中直接修改（临时生效）
SET GLOBAL log_bin_trust_function_creators = 1;
# 方法二，在MySQL启动时，加上--log-bin-trust-function-creators选项，参数设置为1
# 方法三，在my.cnf配置文件[mysqld]中添加如下内容，重启后生效
log-bin-trust-function-creators = 1
8. Soluções para erro de MySQL Falha no link de comunicação
8.1 Descrição do problema
O processo tomcat relata um erro após conectar-se ao banco de dados:
Causado por: org.apache.commons.dbcp.SQLNestedException: Não é possível criar PoolableConnectionFactory (falha no link de comunicações. O último pacote enviado com sucesso para o servidor foi de 0 milissegundos atrás. O driver não recebeu nenhum pacote do servidor).
8.2 Causas do problema
De acordo com a mensagem de erro, pode ser considerado que a conexão no pool de conexão é inválida, ou seja, o tempo válido wait_timeout expirou. Após efetuar login no mysql, verifique se o tempo válido de wait_timeout é 28800, que é de 8 horas.
mysql> show global variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout | 28800 |
+---------------+-------+
1 row in set (0.01 sec)
8.3 Solução
Modifique o atributo wait_timeout e aumente o valor para 31536000 (365 dias, o valor máximo do Linux é um ano)
# 在my.cnf配置文件中，[mysqlId]下添加wati_timeout、interactive_timeout属性，重启mysql
wait_timeout = 31536000
interactive_timeout = 31536000
9. ERROR 1129 (00000) ... está bloqueado devido a muitos erros de conexão
9.1 Descrição do problema
Um erro é relatado ao conectar ao banco de dados:
ERROR 1129 (00000): # HY000Host '192.168.31.242' está bloqueado devido a muitos erros de conexão; desbloquear com 'mysqladmin flush-hosts'
9.2 Causa do problema
Existem muitos erros de conexão (muitas tentativas de conexão), excedendo o número de itens de configuração max_connection_errors no arquivo de configuração.
9.3 Solução
- Digite o seguinte comando no servidor mysql para limpar o cache
mysqladmin flush-hosts -uroot -p
- Adicione a seguinte configuração no arquivo de configuração my.cnf [mysqld] e reinicie o banco de dados
max_connection_errors = 1000
10. MySQL5.7 查询 时 报错 ： [Err] 1055 - A expressão # 1 da lista SELECT não está na cláusula GROUP BY ... isso é incompatível com sql_mode = only_full_group_by
10.1 Descrição do problema
Migre o banco de dados da versão 5.5 para a versão 5.7 e a mensagem de erro detalhada ao executar a instrução de consulta é a seguinte:
[Err] 1055 - A expressão # 1 da lista SELECT não está na cláusula GROUP BY e contém a coluna não agregada 'cdxc.a.id' que não é funcionalmente dependente das colunas na cláusula GROUP BY; isso é incompatível com sql_mode = only_full_group_by
10.2 Causa do problema
No MySQL 5.7, sql_mode é definido como ONLY_FULL_GROUP_BY por padrão. Para usar isso, use as mesmas regras de grupo do Oracle. As colunas selecionadas devem estar no grupo ou devem ser colunas agregadas (SUM, AVG, MAX, MIN).
10.3 Solução
- Consultar a configuração sql_mode atual
mysql> select @@sql_mode;
+--------------------------------+
| @@sql_mode |
+--------------------------------+
|ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+--------------------------------+
1 row in set (0.04 sec)
- Remova ONLY_FULL_GROUP_BY da configuração, escreva o resto da configuração em [mysqld] no arquivo de configuração e reinicie o serviço de banco de dados, o formato é o seguinte
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
- Ou insira diretamente o seguinte conteúdo no banco de dados (é necessário sair do banco de dados e entrar novamente para ter efeito)
set global sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,
NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
11. MySQL5.7 报错 Valor de data e hora incorreto: '0000-00-00 00:00:00' para a coluna
11.1 Descrição do problema
mysql5.7 relata um erro ao executar a importação da instrução sql: mysql 5.7 Erro: Valor de data e hora incorreto: '0000-00-00 00:00:00' para a coluna xxx
11.2 Causas do problema
A partir da versão 5.7, datetime não suporta mais o formato '0000-00-00 00:00:00'.
11.3 Solução
- Substitua a instrução SQL que contém '0000-00-00 00:00:00' por '1970-01-01 00:00:01' na instrução SQL a ser importada
sed -i 's/0000-00-00 00:00:00/1970-01-01 00:00:01/g' test.sql
- Modifique sql_mode, exclua NO_ZERO_IN_DATE e NO_ZERO_DATE em sql_mode
# 查询sql_mode
select @@sql_mode;
# 在控制台中重新设置sql_mode
set global sql_mode='STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,
NO_ENGINE_SUBSTITUTION';
# 在配置文件[mysqld]中添加如下内容重新设置sql_mode
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
12. MySQL 5.7 报错 ： A transação com várias instruções requer mais do que 'max_binlog_cache_size' bytes de armazenamento; aumente esta variável do mysqld e tente novamente
12.1 Descrição do problema
Quando grandes transações, como atualizações em lote ou exclusões do MySQL, são realizadas, os seguintes erros serão relatados:
Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage; increase this mysqld variable and try again
12.2 Causa do problema
Isso ocorre porque grandes transações de atualizações e exclusões gravam um grande número de binlogs, o que pode fazer com que o cache binlog seja muito pequeno e causar falhas de execução. Também haverá casos em que a biblioteca mestre é executada com êxito, mas a biblioteca escrava está fora de sincronia. Isso ocorre porque embora os parâmetros max_binlog_cache_size do mestre e do escravo sejam configurados da mesma forma, o cache binlog real usado não é necessariamente o mesmo, o que faz com que a replicação mestre-escravo seja interrompida porque o cache binlog é muito pequeno.
12.3 Solução
Primeiro verifique o max_binlog_cache_size atualmente definido no MySQL:
mysql> show variables like 'max_binlog_cache_size';
+-----------------------+-----------+
| Variable_name | Value |
+-----------------------+-----------+
| max_binlog_cache_size | 134217728 |
+-----------------------+-----------+
Verifique se o valor desta configuração de parâmetro é 134217728, que é 128M (128 * 1024 * 1024), e defina-o para um tamanho adequado, por exemplo, 256M:
# 在控制台中设置
mysql> set global max_binlog_cache_size=268435456;
Query OK, 0 rows affected (0.05 sec)
# 在配置文件 [mysqld] 中添加如下内容进行设置
max_binlog_cache_size = 256M
Link original deste artigo: https://blog.csdn.net/xzk9381/article/details/114872726