MySQL数据库错误十大经典示例

MySQL数据库错误十大经典示例列表以及解决问题的思路和方法。希望对刚入行的人或者数据库爱好者有所帮助。以后我会再尝试。如果遇到错误，我们可以冷静地解决。
学习任何技术其实都是一个自我修养的过程。保持冷静，尝试拥抱数据的世界！ ？ |变量名 |值 |
max_connections | 151 |
mysql> set global max_connections=1;查询正常，0 行受影响（秒）
[root@node4 ~]# mysql -uzs -p123 456-h 192.168.56.132
ERROR 1040 (00000 ) ): 连接数太多
解决问题的思路：
1、首先我们需要考虑我们的MySQL数据库参数文件中是否设置了合适的max_connections参数值。它太小，导致客户端连接数超过数据库可以处理的最大值。
该值默认大小为151，可以根据实际情况进行调整。对应的解决方法：set global max_connections=500
但是这样的调整是存在隐患的，因为我们无法确认数据库是否能够承受这么大的连接压力。就好像一个男人只能吃一个馒头，现在却不得不放开她一样。如果他吃10个，他肯定受不了。如果反映在服务器上，则可能存在宕机的可能。
所以这体现了我们推出一个新的业务系统的时候，我们要做压力测试。确保稍后对数据库进行优化和定制。
2. 其次，可以限制并发Innodb进程的数量。如果innodb_thread_concurrency = 0（即无限制），可以先改为16或64，看看服务器压力。如果很大，可以先减小到较小的尺寸，以减轻服务器的压力，然后根据业务情况慢慢增加。我个人建议先调整为16，
MySQL性能会随着连接数的增加而下降。开发人员可以设置线程池来重用连接。 MySQL 商业版已添加线程池功能
另外，有些监控程序会读取 information_schema 下的表，可以考虑关闭以下参数
innodb_stats_on_metadata=0
set global innodb_stats_on_metadata= 0
Top 2: (主从复制错误类型)
Last_SQL_Errno: 1062 (从库与主库数据冲突)
Last_Errno: 1062
Last_Error: 无法在表上执行 Write_rows 事件
键“PRIMARY”重复输入“4”，
Error_code：1062； handler error HA_ERR_FOUND_DUPP_KEY;
主事件日志，end_log_pos 1505
对于这个错误，我们首先需要考虑是否是子库故障导致的。原来我们在从库中插入一条带有主键的表的sql语句，导致同一条sql插入到主库时主从状态出现异常。发生主键冲突时报告错误。
解决方案：
假设主从数据一致，从库错误可以跳过。一般使用percona-toolkit中的pt-slave-restart。
在从库上执行以下操作

[root@zs bin]# ./pt-slave-restart -uroot -proot123
2017-07-20T14:05:30 p=…,u=root node4-relay-bin.000002 1506 1062

之后最好在子库中开启read_only参数，禁止子库中的写操作库
Last_IO_Errno：1593（服务器 ID 冲突）
Last_IO_Error：
致命错误：子 I/O 线程停止，因为主服务器和子服务器具有相同的 MySQL 服务器 ID；
这些 ID 必须不同才能复制用于工作
（或者应在子服务器上使用--replicate-same-server-id选项，但这
并不总是有意义；使用前请检查手册）
发生此错误时，一眼就能看出两台机器的server-id是一样的。
在设置主从复制的过程中，我们必须保证两台机器的服务器ID是唯一的。这里再次强调一下服务器ID的命名规则（服务器IP地址最后一个数字+这个MySQL服务的端口号）
解决方案：
在主从机上设置不同的服务器ID 。

Last_SQL_Errno: 1032（从库数据较少，主库更新时从库报错）
Last_SQL_Error:
对表执行Update_rows事件失败。在 't' 中找不到记录
，Error_code: 1032;处理程序错误 HA_ERR_KEY_NOT_FOUND； main event log
, end_log_pos 1708
问题解决：
根据错误信息，我们可以得到错误日志和位置号，然后找到主库执行的是哪条sql导致了主从错误。
在主图书馆查找：
/usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=解码行 /data/mysql/ |grep -A 10 1708 > 1.log
cat 1.log
#170720 14:20:15 服务器 ID 3 end_log_pos 1708 CRC32 0x97b6bdec Update_rows：表 ID 113 标志：STMT_END_F
### 更新 test 测试。哪里
### @1=4 /* INT meta=0 nullable=0 is_null=0 /
### @2='dd' / VARSTRING(60) meta=60 nullable=1 is_null=0 /
### SET
### @1=4 / INT meta=0 nullable=0 is_null=0 /
## # @2='ddd' / VARSTRING(60) meta=60 nullable=1 is_null=0 /
# 在 1708
#170720 14:20:15 end_log_pos 1739 服务器 ID 3 CRC32 0xecaf1922 Xid = 65 4
COMMIT/!/;
DELIMITER;
#日志文件结束
ROLLBACK /添加了mysqlbin日志/;
/ ！50003套COMPLETION_TYPE=@OLD_COMPLETION_TYPE*​​/;
/!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0/;
获取sql语句之后就可以使用从库执行语句sql反之亦然。完成库中缺少的 sql 语句以解决错误消息。
在子库中依次执行：
mysql> insert into t (b) values ('ddd');
查询正常，1 行受影响 (0.01s)
mysql> stop child;
查询正常，0 行受影响 (s )
mysql> 退出
再见
[root@node4 bin]# ./pt-slave-restart -uroot -proot123
2017-07-20T14:31:37 p=…,u= root node4-relay-bin.000005 283 1032
Top 3: MySQL安装过程中出错
[root@zs data]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/ & [ 1] 3758
[data root@zs]# 170720 14:41:24 mysqld_safe 记录到 '/data/mysql/'。
170720 14:41:24 mysqld_safe 使用 /data /my 中的数据库启动 mysqld 守护进程sql170720
14:41:25 mysqld_safe mysqld 来自 pid 文件 /data/mysql/ 完成
170720 14:41:24 mysqld_safe 使用 /data/mysql 中的数据库启动 mysqld 守护进程2017-07-20
14:41 : 25 0 [警告] 不推荐使用带有隐式 DEFAULT 的 TIMESTAMP。
使用 --explicit_defaults_for_timestamp
服务器选项（有关更多详细信息，请参阅文档）。/usr/local/mysql/bin/mysqld :
找不到文件 '/data/mysql/' (错误代码: 13 - 权限被拒绝)
2017-07-20 14:41:25 4388 [ERROR] Aborting
解决方案:
遇到这样的错误信息，我们一定要学会时常关注错误日志的内容。我看到了关键错误消息“权限被拒绝”。证明当前MySQL数据库的数据目录没有权限。
解决方案：
[data root@zs]# chown mysql:mysql -R mysql
[data root@zs]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/ etc / &
[1] 4402
[data root@zs]# 170720 14:45:56 mysqld_safe 记录到 '/data/mysql/'。
170720 14:45:56 mysqld_safe 启动守护进程 mysqld z /data/mysql
中的数据库已成功启动。
为了避免此类问题，我个人建议大家在安装MySQL初始化时一定要加上--user=mysql，以避免权限问题。
./mysql_install_db --basedir=/usr/local/mysql/ --datadir=/data/mysql/ --defaults-file=/etc/ --user=mysql
Top 4: 忘记数据库密码数据问题
[root@zs ~]# mysql -uroot -p
输入密码:
ERROR 1045 (28000): Access Beenied for user 'root'@'localhost' (using password: YES)
[root@zs ~]# mysql -uroot -p
输入密码：
ERROR 1045 (28000): Access Denied for user 'root'@'localhost' (using password: YES)
我们可能刚刚接管了别人的MySQL数据库，并且没有完整的提交文档。 root 密码可能会丢失或忘记。
解决方案：
目前无法进入数据库，需要考虑是否可以跳过权限。因为在数据库中mysql数据库中的users表记录了我们的用户数据。
解决方案：
启动MySQL数据库后，可以这样操作：
/usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/ --skip-grant-tables &
这样启动后，就可以直接进入mysql数据库，无需输入密码。然后更改您要更改的root密码。
update mysql.user set password=password('root123') where user='root';
Top 5: 截断数据删除
导致自增ID自动删除，前端返回无法找到的错误。
出现这个问题时，我们需要考虑截断和删除的区别。 ？自动增量，
b varchar(20) 默认为 NULL，
主键 (a)，
密钥 b b )
) ENGINE=InnoDB AUTO_INCRMENT=300 DEFAULT CHARSET=utf8
插入三条数据：
mysql> insert into t(b)values​​('aa');
查询到ok 1行受影响的(s)
mysql>插入到t(b)值('bb');
查询正常，影响 1 行 (s)
mysql> insert into t (b) values ('cc');
查询正常，影响 1 行 (s)
mysql> select * from t ;
±----±-----+
|一个 | b |
±----±-----+
| 300 | 300啊 |
| 301 | 301 bb |
| 302 | 302 cc |
±----±-----+
连续3行（秒）
首先使用delete删除整个表信息，然后插入新值。

原来truncate重置了自增初始值，自增属性从1开始记录，前端使用主键ID查询时会报错此数据不可用。
个人建议不要使用truncate函数来删除表。虽然表空间可以回收，但是这会涉及到属性自增的问题。我们不应该轻易掉进这些坑。 ？如果找不到表名，请将远程数据库表名更改为小写，反之亦然。请注意，Mybatis Mapper 文件中的所有表名称也应相应更改。一堆？ ？ ？ ？我不知道情况如何。写入数据库建表插入汉字时出现此问题。此错误可能包括数据库字符集问题。
解决方法：
对于汉字乱码的问题，记住老师告诉你的三统一就可以了。又知道当前mysql数据库中的字符集编码默认为UTF8
解决方案：
1、数据终端，也就是我们用来连接数据库的工具，设置为utf82，操作系统的级别；您可以通过 cat /etc/sysconfig/i18n 查看它；还必须设置为utf83，数据库级别；在mysqld下的参数文件中添加-set-server=utf8字符。
Emoji表情插入mysql数据库，报错。
原因：java.sql.SQLException：无效的字符串值：第 1 行中的列“CONTENT”
at ()
at ()
at () at ()
at ()
at ()
at ()
at ()
解决方案：对于表情符号插入问题，肯定还是字符集问题。
处理方法：我们可以直接在参数文件中添加
vim /etc/[mysqld]
init-connect='SET NAMES utf8mb4'
character-set-server=utf8mb4
注意：utf8mb4 是 utf8 的超集。
Top 8：使用binlog_format=语句格式
数据库之间的操作会导致数据库数据丢失，用户访问会导致数据信息不正确。
数据库当前二进制日志格式为：binlog_format=statement

在主库设置binlog-do-db=mydb1（仅同步mydb1库）
在主库执行use mydb2；
插入mydb1.t1值('bb');该语句不会与子数据库同步。
不过这个操作没问题；
使用mydb1；
插入mydb1.t1值('bb');因为是在同一个库中完成的操作。
在生产环境中，建议使用binlog格式行，并谨慎使用binlog-to-db参数。
前 9 名：MySQL 数据库连接超时错误
- SQL 错误：0，SQLState：08S01
- 从服务器成功接收到的最后一个数据包花费了 43200 毫秒。最后一个数据包成功发送到服务器是在 43200 毫秒前，这比服务器配置的“wait_timeout”值要长。在应用程序中使用连接之前，请考虑超时和/或验证连接，增加客户端超时配置的服务器值，或使用 Connector/J 'autoReconnect=true' 来避免此问题。
org. hibernate.event.def.AbstractFlushingEventListener - 无法将数据库状态与会话同步
org.hibernate.exception.JDBCConnectionException：无法执行 JDBC 批量更新
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnection 异常：()已经被调用了。在此状态下操作无效。
- SQL 错误：0，SQLState：08003
- 断开连接后不允许执行任何操作。由于底层异常/错误，连接被隐式终止：
** 嵌套异常的开始 **
大多数 DBA 学生、开发人员都知道您的数据库引发了此错误。快速找出问题所在。
此问题受 wait_timeout 和 Interactive_timeout 两个参数影响。默认的数据配置时间是28800（8小时），也就是说过了这个时间，MySQL数据库就会断开数据库端的连接以节省资源，MySQL服务器也会断开连接，但是我们的程序又会被使用。这次连接过程中没有进行任何判断，所以中止了。

解决方法：
首先要了解这两个参数的特点；这两个参数必须同时设置，并且值必须一致。
该值可以相应增加。 8小时太长，不适合生产环境。由于连接长时间空闲，仍然占用我们的连接数，所以会消耗我们的系统资源。
解决方法：
可以在程序中进行相应判断；强烈建议在操作结束时修改应用程序逻辑以正确关闭连接；然后设置一个比较合理的超时值（根据业务情况判断）
Top 10: 文件打不开（errno:24）
有时候数据库工作正常，但是突然报打不开的错误数据库文件。
解决方案：
首先我们需要检查数据库错误日志。然后确定表是否已损坏或是否存在权限问题。也有可能是由于磁盘空间不足导致表无法正常访问；还要注意操作系统的限制；使用 perror 工具检查具体错误！
linux:/usr/local/mysql/bin # ./perror 24OS 错误代码24: 打开文件太多

已超出最大打开文件数！ ulimit -n 检查系统上打开文件的最大数量，为65535。不能超过！这肯定是因为数据库的最大打开文件数超过了限制！ ？修理台； chown mysql权限清理磁盘垃圾数据

以后会继续总结MySQL处理错误的各种思路和方法。希望与各位退伍军人、同学们一起努力。