MySQL 常见错误

1. Too many connections

ERROR 1040 (HY000): Too many connections

导致结果：

连接数过多，导致连接不上数据库，业务无法正常进行

该错误发生在有max_connections个客户连接了mysqld服务器， 应该重启mysqld， 用更大的max_connections变量值

#默认连接数
mysql> show variables like '%max_connection%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
1 row in set (0.00 sec)

　　

解决问题思路：

1、首先先要考虑在我们 MySQL 数据库参数文件里面，对应的 max_connections 这个参数值是不是设置的太小了，导致客户端连接数超过了数据库所承受的最大值。

• 该值默认大小是 151，可以根据实际情况进行调整。

• 对应解决办法：set global max_connections=500

这样调整会有隐患，因为我们无法确认数据库是否可以承担这么大的连接压力，就好比原来一个人只能吃一斤牛肉，但现在却非要让他吃 10斤牛肉，他肯定接受不了。反应到服务器上面，就有可能会出现宕机的可能。

所以这又反映出了，在新上线一个业务系统的时候，要做好压力测试。保证后期对数据库进行优化调整。

2. Packet too large

结果：

如果写入大数据时，因为默认的配置太小，插入和更新操作会因为 max_allowed_packet 参数限制，而导致失败。

mysql根据max_allowed_packet参数来限制server接受的数据包大小。

当一个MySQL客户或mysqld服务器得到一个max_allowed_packet个字节长的包， 它发出一个Packet too large错误并终止连接。

mysql> show variables like 'max_allowed_packet';
+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 4194304 |
+--------------------+---------+

默认是4M大小

可以使用mysqld的命令行选项设置max_allowed_packet为一个更大的尺寸。 例如， 如果将一个全长的BLOB存入一张表中， 需要用max_allowed_packet=24M选项来启动mysql。

Max_allowed_packet的取值范围是1024B~1GB

当然不要乱设置，根据具体环境要求，设置太大业务

# 具体设置max_allowed_packet大小
mysql> set @@global.max_allowed_packet=
#在my.cnf 加入这个 
max_allowed_packet= 10M

　

3. 线上要修改mysql参数，怎么避免mysql 重启

首先确定改参数是动态参数还是静态参数

如果是静态参数还是要重启服务才会生效，动态参数则不用

这时候要修改全局变量, 必须要显示指定"GLOBAL"或者"@@global.", 同时必须要有SUPER权限.

例如修改最大连接数

#默认连接数
mysql> show variables like '%max_connection%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
1 row in set (0.00 sec)

#修改连接数为500
mysql> set @@global.max_connections=500;
Query OK, 0 rows affected (0.00 sec)

#查看是否修改成功
mysql> show variables like '%max_connection%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 500   |
+-----------------+-------+

# 在my.cnf 的[mysqld]下面加上 max_connections=500就可以了，也不用重启服务

　　

4. root密码忘了怎么办

 

忘记了MySQL的root用户的口令 在my.cnf中添加skip-grant-tables=1选项重启mysqld

[root@mysql-150 ~]# mysql -u root -h 127.0.0.1
mysql> flush privileges;
mysql> grant all privileges on *.* to root@'localhost' identified by '456789';
mysql> exit
# 在my.cnf 将skip-grant-tables=1选项去掉
# 重启mysqld之后就可以用最新的密码登录
[root@mysql-150 ~]# vim /etc/my.cnf
[root@mysql-150 ~]# service mysql restart
Shutting down MySQL............ SUCCESS! 
Starting MySQL. SUCCESS! 
[root@mysql-150 ~]# mysql -u root -p456789 -h 127.0.0.1

　　

5. 账号被锁定

# 创建一个用户
mysql> create user keme@'localhost' identified by '123456';
# 给一个只读权限
mysql> grant select on *.* to keme@'localhost';

# 可以从本地登录
[root@mysql-150 ~]# mysql -u keme -p123456

# 把keme@'localhost' 给lock住，不让其使用
mysql> alter user keme@'localhost' account lock;

# 在看看能不能从本地登录
[root@mysql-150 ~]# mysql -u keme -p123456
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 3118 (HY000): Access denied for user 'keme'@'localhost'. Account is locked.

# 查看该用户是否锁定
mysql> select host,user,account_locked from mysql.user where user='keme';
+-----------+------+----------------+
| host      | user | account_locked |
+-----------+------+----------------+
| localhost | keme | Y              |
+-----------+------+----------------+
Y已锁定
# 然后解锁该keme用户
mysql> alter user keme@'localhost' account unlock;

# 再去登录keme用户
[root@mysql-150 ~]# mysql -u keme -p123456

　　

6. 环境变量未设置

例如执行： mysqldump提示： -bash： command not found 是 环境变量设置的问题

 

临时添加：

# 首先要确定mysql 的安装位置
shell> export PATH=$PATH:/usr/local/mysql/bin

　　

永久设置：

# 在/etc/profile 中末尾添加
PATH=$PATH:$HOME/bin:/usr/local/mysql/bin
export PATH
保存退出后执行： source /etc/bash_profile即可。

　　

7. SQL MODE

MySQL服务器可以以不同的SQL模式来操作， 并且可以为不同客户端应用不同模式。 这样每个应用程序可以根据自己的需求来定制服务器的操作模式

模式定义MySQL应支持哪些SQL语法， 以及应执行哪种数据验证检查。 这样可以更容易地在不同的环境中使用MySQL， 并结合其它数据库服务器使用MySQL。

查看当前的sql_mode

mysql> show variables like 'sql_mode';
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                                                     |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| 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.00 sec)

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 |
+-------------------------------------------------------------------------------------------------------------------------------------------+

　　

7.1 主要的SQL_Mode值包括：

• ANSI

更改语法和行为， 使其更符合标准SQL。

• STRICT_TRANS_TABLES
• TRADITIONAL

使MySQL的行为象“传统”SQL数据库系统。 该模式的简单描述是当在列中插入不正确的值时“给 出 错误 而不是警告” 等同STRICT_TRANS_TABLES、 STRICT_ALL_TABLES、NO_ZERO_IN_DATE、 NO_ZERO_DATE、 ERROR_FOR_DIVISION_BY_ZERO、 NO_AUTO_CREATE_USER。

sql mode常用值

•  ONLY_FULL_GROUP_BY

对于GROUP BY聚合操作，如果在SELECT中的列，没有在GROUP BY中出现，那么这个SQL是不合法的，因为列不在GROUP BY从句中

但这有个条件：如果查询是主键列或是唯一索引且非空列，分组列根据主键列或者唯一索引且空（null）则sql 分组查询有效

• NO_AUTO_VALUE_ON_ZERO

 该值影响自增长列的插入。默认设置下，插入0或NULL代表生成下一个自增长值。如果用户希望插入的值为0，而该列又是自增长的，那么这个选项就有用了。

• STRICT_TRANS_TABLES

在该模式下，如果一个值不能插入到一个事务表中，则中断当前的操作，对非事务表不做限制

为事务存储引擎启用严格模式， 也可能为非事务存储引擎启用严格模式。

严格模式控制MySQL如何处理非法或丢失的输入值。 有几种原因可以使一个值为非法。 例如， 数据类型错 误， 不适合列， 或超出范围。 当新插入的行不包含某列的没有显示定义DEFAULT子句的值，则该值被丢失。 对于事务表， 当启用STRICT_ALL_TABLES或STRICT_TRANS_TABLES模式时， 如果语句中有非法或丢失值， 则会出现错误。 语句被放弃并回滚。

•  NO_ZERO_IN_DATE

在严格模式下，不允许日期和月份为零

• NO_ZERO_DATE

设置该值，mysql数据库不允许插入零日期，插入零日期会抛出错误而不是警告。

• ERROR_FOR_DIVISION_BY_ZERO

在INSERT或UPDATE过程中，如果数据被零除，则产生错误而非警告。如果未给出该模式，那么数据被零除时MySQL返回NULL

• NO_AUTO_CREATE_USER

禁止GRANT创建密码为空的用户

• NO_ENGINE_SUBSTITUTION

如果需要的存储引擎被禁用或未编译，那么抛出错误。不设置此值时，用默认的存储引擎替代，并抛出一个异常

• PIPES_AS_CONCAT

将”||”视为字符串的连接操作符而非或运算符，这和Oracle数据库是一样的，也和字符串的拼接函数Concat相类似

举例：

# 创建一个测试表
CREATE TABLE `employee` (
`eid` int(11) NOT NULL,
`ename` varchar(64) DEFAULT NULL,
`sex` int(11) DEFAULT NULL,
PRIMARY KEY (`eid`)
) ENGINE=InnoDB;
# 插入几条数据
insert into employee (eid,ename,sex) values (1,'keme',18),(2,'xixi',22),(3,'yj',18),(4,'kk',18),(5,'yy',18),(6,'xx',35);

# 设置当前会话的sql_mode为如下
mysql> set @@sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';

mysql> select eid,ename,count(*) from employee group by ename;
+-----+-------+----------+
| eid | ename | count(*) |
+-----+-------+----------+
|   1 | keme  |        1 |
|   4 | kk    |        1 |
|   2 | xixi  |        1 |
|   6 | xx    |        1 |
|   3 | yj    |        1 |
|   5 | yy    |        1 |
+-----+-------+----------+

# 重新设置当前的sql_mode 为如下
mysql> set @@sql_mode='ONLY_FULL_GROUP_BY';
mysql> select eid,ename,count(*) from employee group by ename;
ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'beta.employee.eid' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
mysql> select eid,ename ,count(*) from employee group by eid;
+-----+-------+----------+
| eid | ename | count(*) |
+-----+-------+----------+
|   1 | keme  |        1 |
|   2 | xixi  |        1 |
|   3 | yj    |        1 |
|   4 | kk    |        1 |
|   5 | yy    |        1 |
|   6 | xx    |        1 |
+-----+-------+----------+
6 rows in set (0.00 sec)



mysql> set @@sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';
mysql> insert into employee values(7,'ke','male');
ERROR 1366 (HY000): Incorrect integer value: 'male' for column 'sex' at row 1

mysql> set @@sql_mode='ANSI';
Query OK, 0 rows affected (0.00 sec)

mysql> select @@sql_mode;
+--------------------------------------------------------------------------------+
| @@sql_mode                                                                     |
+--------------------------------------------------------------------------------+
| REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY,ANSI |
+--------------------------------------------------------------------------------+

#改成ANSI模式就可以插入成功了，只不过识别成了0
mysql> insert into employee values(7,'ke','male');
Query OK, 1 row affected, 1 warning (0.01 sec)

mysql> select * from employee where eid=7;
+-----+-------+------+
| eid | ename | sex  |
+-----+-------+------+
|   7 | ke    |    0 |
+-----+-------+------+
1 row in set (0.00 sec)


mysql> set @@sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> select @@sql_mode;
+--------------------------------------------+
| @@sql_mode                                 |
+--------------------------------------------+
| STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+--------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into employee values (8,'ww',17/0);
Query OK, 1 row affected (0.00 sec)

mysql> select * from employee  where eid=8;
+-----+-------+------+
| eid | ename | sex  |
+-----+-------+------+
|   8 | ww    | NULL |
+-----+-------+------+


mysql> set @@sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,ERROR_FOR_DIVISION_BY_ZERO';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> select @@sql_mode;
+-----------------------------------------------------------------------+
| @@sql_mode                                                            |
+-----------------------------------------------------------------------+
| STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into employee values (9,'ee',18/0);
ERROR 1365 (22012): Division by 0

mysql> alter table employee modify ename varchar(5);
mysql> set @@sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';
mysql> insert into employee values (9,'qweradsf',11);
ERROR 1406 (22001): Data too long for column 'ename' at row 1

mysql> set @@sql_mode='ANSI';
mysql> insert into employee values (9,'qweradsf',11);
mysql> select * from employee where eid=9;
+-----+-------+------+
| eid | ename | sex  |
+-----+-------+------+
|   9 | qwera |   11 |
+-----+-------+------+


mysql> set @@sql_mode='TRADITIONAL';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> select @@sql_mode;
TRADITIONAL模式有如下值：
|STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |

　　

8. 用户的资源限制

MySQL提供了对每个用户的资源限制管理

MAX_QUERIES_PER_HOUR ： 一个用户在一个小时内可以执行查询的次数（基本包含 所 有 语 句 ）

MAX_UPDATES_PER_HOUR：一个用户在一个小时内可以执行修改的次数（仅包含修 改数据库或表的语句）

MAX_CONNECTIONS_PER_HOUR：允许用户每小时连接的次数

MAX_USER_CONNECTIONS：一个用户可以在同一时间连MySQL实例的数量

通过执行create user/alter user设置/修改用户的资源限制

# 创建一个用户并设置其资源限制
CREATE USER 'keme1'@'localhost' IDENTIFIED BY
'123456' WITH MAX_QUERIES_PER_HOUR 20
MAX_UPDATES_PER_HOUR 10
MAX_CONNECTIONS_PER_HOUR 5
MAX_USER_CONNECTIONS 2;
#keme1 这个用户 一个小时可以查询20次， 修改10次，一个小时可以连接5次，同一时刻只允许两个用户

#取消某项资源限制既是把原先的值修改成0
mysql> alter user 'keme1'@'localhost' WITH MAX_CONNECTIONS_PER_HOUR 0;

# 当针对某个用户的max_user_connections非0时， 则忽略全局系统参数max_user_connections， 反之则全局系统参数生效

　　

9. 主从同步错误

一般主从同步错误首先要考虑是不是在从库中误操作导致的。结果发现，有人在从库中进行了一条针对有主键表的 sql 语句的插入，导致主库再插入相同 sql 的时候，主从状态出现异常。发生主键冲突的报错。

解决方法：

在确保主从数据一致性的前提下，可以在从库进行错误跳过。

像从库如果不提供什么服务的话可以在从库中开启 read_only 参数，禁止在从库进行写入操作，还有用户必须没有super 权限，设置read_only才会生效。

9.1 一般主从复制错误的解决办法

这是正常的状态

10.0.0.150 是主

10.0.0.151 是从

先模拟故障

# 这是本次的表结构
mysql> show create table students;
| students | CREATE TABLE `students` (
  `sid` int(11) NOT NULL,
  `sname` varchar(20) DEFAULT NULL,
  `sex` int(11) DEFAULT NULL,
  PRIMARY KEY (`sid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 
#主库执行，是个空表
mysql> select * from students;
Empty set (0.00 sec)

#在从库 ，给students 加1条数据： 
mysql> insert into students  values (1,'keme',0);
mysql> show slave status\G;
...
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
...
看主从状态是正常的
# 从库查看students 数据
mysql> select * from students;
+-----+-------+------+
| sid | sname | sex  |
+-----+-------+------+
|   1 | keme  |    0 |
+-----+-------+------+


# 在主库查看students 表
mysql> select * from students;
Empty set (0.00 sec)

# 插入相同主键的值
mysql> insert into students values (1,'keme',1);

# 查看students表
mysql> select * from students;
+-----+-------+------+
| sid | sname | sex  |
+-----+-------+------+
|   1 | keme  |    1 |
+-----+-------+------+


# 查看从库状态
mysql> show slave status\G;
...
Slave_IO_Running: Yes
Slave_SQL_Running: No
Last_SQL_Error: Could not execute Write_rows event on table beta.students; Duplicate entry '1' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000023, end_log_pos 11789
...
# 主从状态不一致了，造成的原因是主键冲突

　　

解决办法

# 停止从库
mysql> stop slave;

# 在从库删除主键冲突的那条语句， 把主库执行的那条语句在从库执行
mysql> delete from students where sid=1;
mysql> insert into students values (1,'keme',1);

# 同步跳过临时错误
mysql> set global sql_slave_skip_counter = 1;
mysql> start slave;
mysql> show slave status\G;
...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
...

# 主库再次插入数据，看看从库是不是能够同步
mysql> insert into students  values (2,'keme',1);

# 从库查看
mysql> select * from students;
+-----+-------+------+
| sid | sname | sex  |
+-----+-------+------+
|   1 | keme  |    1 |
|   2 | keme  |    1 |
+-----+-------+------+
2 rows in set (0.00 sec)

# OK,同步成功了， 一般主从错误也就解决了

　　

那这时候有问题，主从问题不一致了， 主上面插入了很多数据， 这时候该怎么解决了。

首先主从问题不一致了，你的监控预警机制了，给你发短信或者钉钉，这时候你应该尽快去修复从库，比如就像上面跳过临时同步错误，暂时让其恢复正常同步。

其次 后期就是用pt工具：比如用pt-table-checksum 找出主从表数据不一致的， pt-table-sync进行修复从库

 

9.2 GTID 主从复制错误解决办法

现在修改我的主从模式为GTID，这是我的测试环境随便改，

生产环境不能这样瞎改

搭建GTID主从时，需要注意的 mysql 参数：

server_id：设置 mysql 实例的 server_id,每个实例的server_id必须不一样

gtid_mode=on：MYSQL 实例开启GTID 模式。

enforce_gtid_consitency=on ：使用GTID模式复制时，需要开启此参数，用来保证GTID的一致性。

log-bin=on ：Msql 做主从必须开启binlog

log-slave-updates=1 ：觉得slave 从master 接收到的更新且执行完之后，执行的binlog是否记录到slave的binlog中，建议开启

binlog_format=row ：强烈建议binlog_format使用row格式 在mysql 5.7.6 版本以后默认就是row

skip-slave-start=1 ：当slave 数据库启动的时候，slave 不会自动开启复制

 

主库操作，在[mysqld] 加一下参数，我这个做过主从， 只加一部分参数

# my.cnf 中内容 
[mysqld]
gtid-mode=on
enforce-gtid-consistency=on
log-slave-updates=1

　　

从库操作

# my.cnf 中内容
[mysqld]
gtid-mode=on
enforce-gtid-consistency=on
log-slave-updates=1
skip-slave-start=1

重启主从数据库

 

　

在从库 操作重新设置主从库的复制关系

mysql> CHANGE MASTER TO
MASTER_HOST = '10.0.0.150',
MASTER_PORT = 3306,
MASTER_USER = 'repl',
MASTER_PASSWORD = '123456',
MASTER_AUTO_POSITION = 1;
mysql> start slave;

#查看主从状态
mysql> show slave status\G;
...
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
...

　　

 

如果是在GTID模式下出现复制报错， 则使用SQL_SLAVE_SKIP_COUNTER语句会报错

在GTID 模式的复制情况下，如果slave 发生错误，则可以通过跳过该事务的方式恢复主从复制。

 

 现在人为制造slave错误

# 在从库的sutdents 表插入一条数据
mysql> select * from students;
+-----+-------+------+
| sid | sname | sex  |
+-----+-------+------+
|   1 | keme  |    1 |
|   2 | keme  |    1 |
+-----+-------+------+
mysql> insert into students values (3,'keme',0);

# 在查看从库的数据
mysql> select * from students;
+-----+-------+------+
| sid | sname | sex  |
+-----+-------+------+
|   1 | keme  |    1 |
|   2 | keme  |    1 |
|   3 | keme  |    0 |
+-----+-------+------+

# 主库也插入主键为3这条数据，引发主从同步错误
mysql> insert into students values (3,'keme',1);

　　

 

 主从报错了：

 

 从图中可以看出，出错事务的binlog文件为mysql-bin.000026

开始位置(Exec_Master_Log_Pos)是154 ，结束位置是(end_log_pos ) 395,可以去主库分析下binlog ，看一下发生冲突的事务是哪个。

可以看到接收并且执行了GTID事件 是

从库执行了这些
5a13910d-1496-11e9-8375-000c29f859ce:1-3,
f6c31435-38dd-11e9-ac93-000c299bcbee:1-53096

收到却没执行的事务号：
Retrieved_Gtid_Set: f6c31435-38dd-11e9-ac93-000c299bcbee:53097

　　

可以看出发现冲突的事务号是：f6c31435-38dd-11e9-ac93-000c299bcbee:53097，这时候就要确定哪一个事务发生了冲突，还可以直接从show slave status\G;结果中通过比对的方式找到冲突位置。

严谨起见，通过对binlog 内容分析得知冲突事务是插入了一条数据，主键为3。在从库中查看这条记录是否真的存在

mysql> select * from students where sid=3;
+-----+-------+------+
| sid | sname | sex  |
+-----+-------+------+
|   3 | keme  |    0 |
+-----+-------+------+

　　

发现slave 中存在这条记录了，这时，可以通过跳过该事务的方式来放弃该事务在slave上的执行，使slave 能够正常运行。

基于GTID模式的复制，跳过一个事务，需要利用一个空事务来完成。

mysql> stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> set GTID_NEXT='f6c31435-38dd-11e9-ac93-000c299bcbee:53097';
Query OK, 0 rows affected (0.00 sec)

mysql> begin;commit;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

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

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

　　

查看slave 状态

 

 哪主从库数据是否一致，就看3那条

# 主库数据
mysql> select * from students where sid=3;
+-----+-------+------+
| sid | sname | sex  |
+-----+-------+------+
|   3 | keme  |    1 |
+-----+-------+------+

#从库数据
mysql> select * from students where sid=3;
+-----+-------+------+
| sid | sname | sex  |
+-----+-------+------+
|   3 | keme  |    0 |
+-----+-------+------+

　　

解决不一致数据：

1 手动修改或者插入

2 用pt用具 来修复或者检查不一致数据

 

由于我这是我的本地环境，我只手动修改数据,再看主从状态

mysql> update students set  sex=1 where sid=3;
Query OK, 1 row affected (0.03 sec)
Rows matched: 1  Changed: 1  Warnings: 0

 

注：不止是要主从解决错误，还要主从数据的一致性　

如果是生产的核心库主从不一致，一定要查明原因，不然老是 dba 或者运维 背锅

还有如果主从不一致性实在是太多太多不一致了，就重做数据库吧

如果检查的数据某几张表不一致的情况下，可以把这几张道出来，恢复到从库

 

10. 数据库总会出现中文乱码的情况

为什么我的数据库总会出现中文乱码的情况。一堆中文乱码不知道怎么回事?当向数据库中写入创建表，并插入中文时，会出现这种问题。此报错会涉及数据库字符集的问题。

10.1 解决乱码的几个方面

对于中文乱码的情况，从三个方面

• 数据终端： 就是我们连接数据库的工具设置为utf8
• 操作系统层面：linux 系统通过 在命令争端查看当前编码echo $LANG或者locale

如何修改了系统编码了：

# centos 6.x 版本是/etc/sysconfig/i18n
修改这个文件
shell> vim /etc/sysconfig/i18n
# 这一行改为utf8
LANG=en_US.UTF-8
# 修改完，不要重启，立即生效如下
shell> source /etc/sysconfig/i18n


# centos 7.x 版本是/etc/locale.conf 这个文件
[root@mysql-150 ~]# vim /etc/locale.conf
LANG="en_US.UTF-8"
#立即生效
[root@mysql-150 ~]# source /etc/locale.conf

　　

• 数据库层面：

在参数文件中的[mysqld] 下，加入相应utf8字符集

# 注意数据库的系统版本
5.6.x 和 5.7.x设置字符集参数不一样，8.x和5.7.x设置是一样的
#查看当前数据库的字符集参数，查看当前字符集参数
mysql> show variables like '%character%';

# 查看数据库支持的字符编码，和编码的排序规则
mysql> show character set;

# 修改sutdents表中sname 字段的字符编码
mysql> alter table students modify sname varchar(66) character set gbk;
Query OK, 3 rows affected (0.06 sec)
Records: 3  Duplicates: 0  Warnings: 0

#看看表结构
mysql> show create table students;
...
| students | CREATE TABLE `students` (
  `sid` int(11) NOT NULL,
  `sname` varchar(66) CHARACTER SET gbk DEFAULT NULL,
  `sex` int(11) DEFAULT NULL,
  PRIMARY KEY (`sid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
...

# 查看连接级字符集和排序规则
mysql> show variables like '%collation%';
+----------------------+-----------------+
| Variable_name        | Value           |
+----------------------+-----------------+
| collation_connection | utf8_general_ci |
| collation_database   | utf8_general_ci |
| collation_server     | utf8_general_ci |
+----------------------+-----------------+

　　

从上面示例可以得出：

如果修改数据库字符集，需要从以下考

• 列级别字符集

• 表级别字符集

• 库级别字符集

• mysql 实例字符集

10.2 怎么合理修改mysql字符集了

在/etc/my.cnf 加一下参数

vim /etc/my.cnf 
[mysqld] 
init-connect='SET NAMES utf8' 
character-set-server=utf8 
然后去数据库操作：
mysql> set @@global.character_set_server=utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set @@global.init_connect='SET NAMES utf8';
Query OK, 0 rows affected (0.00 sec)
# 注 用户操作的时候看看有没有super权限，对super用户权限 set names 不生效

　　

有人说，修改完还是乱码， 这时候就乱码是哪个库的字符集，哪个表的字符集，哪个字段的字符集，还有操作系统字符集，程序连接的字符集，这些都的查看。

在/etc/my.cnf中init-connect='SET NAMES utf8'是什么意思:

让每个客户端连接都自动设置字符集，但缺点是对拥有super权限的用户不生效

init_connect表示服务器为每个连接的客户端执行的字符串。字符串由一个或多个SQL语句组成。要想指定多个语句，用分号间隔开 。

 比如：

# 举例init_connect
mysql> SET @@GLOBAL.init_connect='SET AUTOCOMMIT=0;set names
utf8';
shell> vim my.cnf
[mysqld]
init_connect='SET AUTOCOMMIT=0;set names utf8'

10.3 连接级字符集和排序规则

• 每个数据库客户端连接都有自己的字符集和排序规则属性，

  客户端发送的语句的字符集是由character_set_client决定，

  而与服务端交互时会根据character_set_connection和collation_connection两个参数将接收到的语句转化。当涉及到显示字符串的比较时，由collation_connection参数决定，

  而当比较的是字段里的字符串时则根据字段本身的排序规则决定

• character_set_result参数决定了语句的执行结果以什么字符集返回给客户端

• 客户端可以很方便的调整字符集和排序规则，比如使用SET NAMES 'charset_name' [COLLATE 'collation_name']表明后续的语句都以该字符集格式传送给服务端，而执行结果也以此字符集格式返回。

　　

set names 字符集

set names charset_name 语句相当于执行了以下三行语句：
SET character_set_client = charset_name;
SET character_set_results = charset_name;
SET character_set_connection = charset_name;

　　

或者执行SET CHARACTER SET 'charset_name'命令 :此命令和set names非常类似，唯一不同是将connection的字符集设置为当前数据库的字符集，所以相当于执行以下三行语句：

SET character_set_client = charset_name;
SET character_set_results = charset_name;
SET character_set_connection = @@character_set_database;

小结: 中文乱码从：数据终端，操作系统，数据库

数据库从： 全局数据库server字符集——>数据库字符集——> 表字符集——> 列字符集

10.4 表情乱码不能识别

修改存表情字段的字符集为utf8mb4　　

11 can't opet file(errno:24)

有的时候，数据库跑得好好的，突然报不能打开数据库文件的错误了。

解决思路：

首先我们要先查看数据库的 error log。然后判断是表损坏，还是权限问题。还有可能磁盘空间不足导致的不能正常访问表，操作系统的限制也要关注下,相关应用限制也要关注下;

#ulimit -n 查看系统的最大打开文件数
[root@mysql-150 ~]# ulimit -n
65535

查看数据库的打开文件数

mysql> show variables like 'open_files_limit';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 5000  |
+------------------+-------+
# 根据业务实际情况修改打开文件数一般足够用了，低版本的打开文件数，可能有点小， 注意一下

哪就是其他的问题了，可能是表的权限，也可能是表出问题，根据错误日志，具体分析　　

处理方法

• repair table tablename

• chown mysql.mysql 权限 目录

• 清理磁盘中的垃圾数据

12. sleep 线程过多怎么解决

结果：严重消耗mysql服务器资源(主要是cpu, 内存)，并可能导致mysql崩溃。

12.1 知道 sleep 线程过多原因

首先要知道到底是什么原因导致的 sleep 线程过多的：

1. 程序逻辑问题，导致连接一直不释放；

2. mysql 参数的问题，是不是参数配置的不合理，一直不释放连接；

3. mysql 语句的问题，数据库查询不够优化，过度耗时。

4. 大并发情况问题，导致 sleep 情况过多；

12.2 临时解决 sleep 线程

很多人都是重启大法，重启大法确实好， 能够释放，生产重启对业务有影响的，不能随便重启的

shell脚本+cron计划任务，来kill sleep 线程，这个不靠谱啊， 你不知道 sleep 线程，里面是不是还有事务还在执行没有提交，也是sleep 状态，这个kill 操作有点莽夫，对生产数据数据库还是要理智啊。

我临时解决的办法：

1. 对用户资源做限制，看看那个用户连接的sleep线程比较多，对这个用户连接多的做一些限制，比如一个小时可以连接多少次啊等等

2. 修改 mysql 参数问题 ，修改wait_timeout 和interactive_timeout默认都是28800秒有，也就是8个小时以后才释放空链接。

例子：

 

　

不同用户登录到数据库，wait_timeout和interactive_timeout都是28800秒

修改参数，我生产环境设置的是半个小时，也就是1800秒

mysql> set global wait_timeout=1800;
mysql> set global interactive_timeout=1800;

shell> vim my.cnf
[mysqld]
wait_timeout=1800
interactive_timeout=1800

　　

这样修改完，由于已近保持的会话连接需要等到8个小时才会释放， 所以修改了wait_timeout和interactive_timeout不会立即生效的原因，这时候就要修改连接过多的用户资源了来释放sleep线程了

如下：

#开启两个会话窗口
mysql> # 重新登录了会话，wait_timeout和interactive会生效
mysql> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 1800  |
+---------------+-------+
1 row in set (0.00 sec)

mysql> show variables like 'interactive_timeout';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| interactive_timeout | 1800  |
+---------------------+-------+
1 row in set (0.00 sec)

#session2
mysql> #这个是其他用户连接的mysql，这个会话一直没有断开，参数还是28800
mysql> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.01 sec)

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

 

　

13.3 怎么根本解决了

这时候就要知道 造成 sleep 线程过多的原因来解决：

1. 程序执行完毕，应该显式调用mysql_close

2. 程序中根据业务访问情况，选择长连接还是短连接

3. 能逐步分析系统的SQL查询，找到查询过慢的SQL优化

4. 合理设置mysql参数值