MySQL 各类问题及解决办法汇总

推荐阅读

Helm3（K8S 资源对象管理工具）视频教程：https://edu.csdn.net/course/detail/32506

Helm3（K8S 资源对象管理工具）博客专栏：https://blog.csdn.net/xzk9381/category_10895812.html

本文原文链接：https://blog.csdn.net/xzk9381/article/details/114872726，转载请注明出处。如有发现文章中的任何问题，欢迎评论区留言。

1. MySQL 5.7 线程阻塞的解决办法

---

1.1 问题说明

在数据库中执行语句报错： ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction。

1.2 解决办法

1. 查看当前数据库中的线程

show full processlist;

2. 如果没有看到正在执行的慢sql记录线程，再查看 innodb的事务表INNODB_TRX，看下里面是否有正在锁定的事务线程，看看trx_mysql_thread_id是否在show full processlist里面的sleep线程中，如果是，就证明这个sleep的线程事务一直没有commit 或者 rollback而是卡住了，我们需要手动kill掉，例如kill 32735

2. MySQL 5.7远程连接数据库时速度慢的解决办法

---

2.1 问题说明

使用mysql命令远程访问数据库，输入密码后需要等待5s-10s才可完成连接，导致后台服务抛出异常。

2.2 问题原因

每次访问数据库，mysql就会试图去解析来访问的机器的domain name，如果这时无法解析，等一段时间会失败，数据才能被取过来。

2.3 解决办法

在mysql配置文件中[mysqld]下面添加skip-name-resolve配置项来禁止解析域名，重启数据库即可生效

3. MySQL 5.7 二进制安装报错

---

3.1 问题说明

在centos6.8（最小化安装）中使用二进制安装包安装MySQL 5.7报错：

error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory

3.2 解决办法

CentOS最小化安装时默认不安装libaio库，需要手动进行安装

yum install libaio-devel

4. MySQL 5.7中使用group concat函数数据被截断问题的解决方法

---

4.1 问题说明

调用GROUP_CONCAT函数进行查询时，查询没有停止且没有返回任何数据（也有一种情况是查询出来的数据被截断了，最长长度不超过1024字节）

4.2 问题原因

该问题的原因是由于官方给出的默认group_concat_max_len配置为1024，这个配置会限制GROUP_CONCAT数据的长度。可以使用如下命令查询：

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 解决办法

可以将group_concat_max_len调整到最大值18446744073709551615（或根据业务实际返回的最大长度进行设置）

1. 修改MySQL的配置文件，在[mysqld]下面添加group_concat_max_len = 18446744073709551615（永久生效）
2. 在控制台中进行设置（临时生效）

SET GLOBAL group_concat_max_len=18446744073709551615;
SET SESSION group_concat_max_len=18446744073709551615;

5. MySQL 报 ERROR: Packet for query is too large (2034> 1024)

---

5.1 问题说明

数据存储的时候报错：

ERROR: Packet for query is too large (2034> 1024). You can change this value on the server by setting the max_allowed_packet’ variable.

5.2 解决办法

1. 使用如下命令查看当前数据库中的max_allowed_packet设置

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

2. 在my.cnf配置文件[mysqld]中添加或修改max_allowed_packet=128M，重启mysql即可生效。如果过一段时间查询max_allowed_packet的值又恢复为1024，则需要查询当前服务器的内存是否不足，这会导致MySQL自动重新设置参数为1024，预留出足够的内存即可解决该问题。

6. MySQL 5.7报错Waiting for table metadata lock的解决办法

---

6.1 问题说明

在MySQL5.7中执行alt table等DDL操作时，操作被阻塞无法执行，使用 show processlist查看发现对该表的alt table操作显示Waiting for table metadata lock。

6.2 问题原因

在MySQL5.7中执行alt table等DDL操作时，如果该表中有未提交的事务则会出现 Waiting for table metadata lock状态

6.3 解决办法

1. 使用如下命令从information_schema.innodb_trx 查看未提交事务， 一般只要kill掉这些线程，DDL操作就不会Waiting for table metadata lock

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

2. 调整锁超时阈值。lock_wait_timeout 表示获取metadata lock的超时（单位为秒），允许的值范围为1到31536000（1年）。 默认值为31536000，将其调整为30分钟

set session lock_wait_timeout = 1800;
set global lock_wait_timeout = 1800;

本文原文链接：https://blog.csdn.net/xzk9381/article/details/114872726，转载请注明出处。如有发现文章中的任何问题，欢迎评论区留言。

7. MySQL报错ERROR 1418 (HY000)的解决办法

7.1 问题说明

MySQL开启bin-log后，调用存储过程或者函数以及触发器时会出现错误号为1418的错误:

ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable)

7.2 问题原因

因为CREATE PROCEDURE, CREATE FUNCTION, ALTER PROCEDURE,ALTER FUNCTION,CALL, DROP PROCEDURE, DROP FUNCTION等语句都会被写进二进制日志,然后在从服务器上执行。但是，一个执行更新的不确定子程序(存储过程、函数、触发器)是不可重复的，在从服务器上执行(相对与主服务器是重复执行)可能会造成恢复的数据与原始数据不同，从服务器不同于主服务器的情况。

为了解决这个问题，MySQL强制要求在主服务器上，除非子程序被声明为确定性的或者不更改数据，否则创建或者替换子程序将被拒绝。这意味着当创建一个子程序的时候，必须要么声明它是确定性的，要么它不改变数据。

声明方式有两种：

1. 声明是否是确定性的： DETERMINISTIC和NOT DETERMINISTIC指出一个子程序是否对给定的输入总是产生同样的结果。如果没有给定任一特征，默认是NOT DETERMINISTIC，所以必须明确指定DETERMINISTIC来声明一个子程序是确定性的。这里要说明的是:使用NOW() 函数（或它的同义）或者RAND() 函数不会使一个子程序变成非确定性的。对NOW()而言，二进制日志包括时间戳并会被正确的执行。RAND()只要在一个子程序内被调用一次也可以被正确的复制。所以，可以认为时间戳和随机数种子是子程序的确定性输入，它们在主服务器和从服务器上是一样的。
2. 声明是否会改变数据：CONTAINS SQL, NO SQL, READS SQL DATA, MODIFIES SQL用来指出子程序是读还是写数据的。
   无论NO SQL还是READS SQL DATA都指出，子程序没有改变数据，但是必须明确地指定其中一个，因为如果任何指定，默认的指定是CONTAINS SQL。

也就是说，在开启bin-log的情况下，必须指定创建的函数是否是如下几种类型：

1. DETERMINISTIC：不确定的
2. NO SQL：没有SQl语句，当然也不会修改数据
3. READS SQL DATA：只是读取数据，当然也不会修改数据
4. MODIFIES SQL DATA：要修改数据
5. CONTAINS SQL：包含了SQL语句

默认情况下，如果允许CREATE PROCEDURE 或CREATE FUNCTION 语句被接受，就必须明确地指定DETERMINISTIC 或 NO SQL与READS SQL DATA 中的一个，否则就会产生1418错误。

7.3 解决办法

解决办法有两种：

1. 创建子程序(存储过程、函数、触发器)时，声明为DETERMINISTIC或NO SQL与READS SQL DATA中的一个

CREATE DEFINER = CURRENT_USER PROCEDURE `NewProc`()
    DETERMINISTIC
BEGIN
 #Routine body goes here...
END;

2. 信任子程序的创建者，禁止创建、修改子程序时对SUPER权限的要求，设置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. MySQL报错Communications link failure的解决办法

---

8.1 问题说明

tomcat进程连接数据库后报错：

Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.)

8.2 问题原因

根据报错信息可以判断连接池中的连接Connection失效，即超过了有效时间wait_timeout。登录mysql后查看wait_timeout有效时间为28800，即8小时。

mysql> show global variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.01 sec)

8.3 解决办法

修改wait_timeout属性，调大数值为31536000（365天，linux最大值为一年）

# 在my.cnf配置文件中，[mysqlId]下添加wati_timeout、interactive_timeout属性，重启mysql
wait_timeout = 31536000
interactive_timeout = 31536000

9. 数据库连接时报错ERROR 1129 (00000)…is blocked because of many connection errors

---

9.1 问题说明

连接数据库时报错：

ERROR 1129 (00000): #HY000Host ‘192.168.31.242’ is blocked because of many connection errors; unblock with ‘mysqladmin flush-hosts’

9.2 问题原因

连接错误次数过多（尝试连接次数过多），超出配置文件中max_connection_errors配置项次数。

9.3 解决办法

1. 在mysql服务器上输入如下命令来清除缓存

mysqladmin flush-hosts -uroot -p

2. 在my.cnf配置文件[mysqld]中添加如下配置并重启数据库

max_connection_errors = 1000

10. MySQL5.7查询时报错：[Err] 1055 - Expression #1 of SELECT list is not in GROUP BY clause…this is incompatible with sql_mode=only_full_group_by

---

10.1 问题说明

将数据库从5.5版本迁移至5.7版本，执行查询语句时详细报错信息如下：

[Err] 1055 - Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column ‘cdxc.a.id’ which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

10.2 问题原因

MySQL5.7中，sql_mode默认设置了ONLY_FULL_GROUP_BY，使用这个就是使用和oracle一样的group 规则, select的列都要在group中,或者本身是聚合列(SUM,AVG,MAX,MIN) 才行。

10.3 解决办法

1. 查询当前sql_mode的配置

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)

2. 将配置中的ONLY_FULL_GROUP_BY去掉，将其余配置写入配置文件中的[mysqld]下面，并重启数据库服务，格式如下

sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

3. 或者直接在数据库中输入如下内容（需要退出数据库重新进入才能生效）

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报错Incorrect datetime value: ‘0000-00-00 00:00:00’ for column

---

11.1 问题说明

mysql5.7执行sql语句导入时报错:mysql 5.7 Error : Incorrect datetime value: ‘0000-00-00 00:00:00’ for column xxx

11.2 问题原因

mysql从5.7版本开始，datetime不再支持’0000-00-00 00:00:00’ 的格式。

11.3 解决办法

1. 将即将导入的sql语句中包含’0000-00-00 00:00:00’ 的替换为’1970-01-01 00:00:01’即可

sed -i 's/0000-00-00 00:00:00/1970-01-01 00:00:01/g' test.sql

2. 修改sql_mode，将sql_mode中的NO_ZERO_IN_DATE,NO_ZERO_DATE删除即可

# 查询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 报错：Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage; increase this mysqld variable and try again

---

12.1 问题说明

在对 MySQL 批量更新或删除等大事务时，会导致报如下错误：

Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage; increase this mysqld variable and try again

12.2 问题原因

这是由于更新和删除的大事务会写入大量binlog，可能会造成binlog cache过小而导致执行失败。也会遇到主库执行成功而从库不同步的情况。这是因为虽然主从的max_binlog_cache_size参数虽然设置的一样，但是实际使用的binlog cache不一定相同，从而导致binlog cache因为过小而主从复制中断。

12.3 解决办法

首先查看 MySQL 中当前设置的 max_binlog_cache_size 大小：

mysql> show variables like 'max_binlog_cache_size';
+-----------------------+-----------+
| Variable_name         | Value     |
+-----------------------+-----------+
| max_binlog_cache_size | 134217728 |
+-----------------------+-----------+

查看到该参数设置的值为 134217728，也就是 128M （ 128 * 1024 * 1024 ），将其设置为合适的大小，例如 256M：

# 在控制台中设置
mysql> set global max_binlog_cache_size=268435456;
Query OK, 0 rows affected (0.05 sec)

# 在配置文件 [mysqld] 中添加如下内容进行设置
max_binlog_cache_size = 256M

本文原文链接：https://blog.csdn.net/xzk9381/article/details/114872726，转载请注明出处。如有发现文章中的任何问题，欢迎评论区留言。