MySQL数据库常见的出错代码及出错信息[1]

本文介绍的MySQL数据库的出错代码表 依据MySQL数据库头文件mysql/include/mysqld_error h整理而成 详细内容请大家参考下文

创建表失败

创建数据库失败

数据库已存在 创建数据库失败

数据库不存在 删除数据库失败

不能删除数据库文件导致删除数据库失败

不能删除数据目录导致删除数据库失败

删除数据库文件失败

不能读取系统表中的记录

记录已被其他用户修改

硬盘剩余空间不足 请加大硬盘可用空间

关键字重复 更改记录失败

关闭时发生错误

读文件错误

更改名字时发生错误

写文件错误

记录不存在

数据表是只读的 不能对它进行修改

系统内存不足 请重启数据库或重启服务器

用于排序的内存不足 请增大排序缓冲区

已到达数据库的最大连接数 请加大数据库可用连接数

系统内存不足

无效的主机名

无效连接

当前用户没有访问数据库的权限

不能连接数据库 用户名或密码错误

字段不能为空

数据库不存在

数据表已存在

数据表不存在

字段不存在

无效的SQL语句 SQL语句为空

不能建立Socket连接

数据表已满 不能容纳任何记录

打开的数据表太多

数据库出现异常 请重启数据库

连接数据库失败 没有连接数据库的权限

数据库用户不存在

当前用户无权访问数据库

当前用户无权访问数据表

当前用户无权访问数据表中的字段

数据表不存在

未定义用户对数据表的访问权限

SQL语句语法错误

lishixinzhi/Article/program/MySQL/201311/29663

MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。

如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。

临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。

今天晚上运营同事反馈了系统有个列表数据查询不出来，筛选某个条件又能查出数据来。当运营反馈时，立马收到线上报警邮件提示如下：

也就是抛出 MySQLDataException异常，由于定性思维的原因，一直在排查sql问题，不断尝试替换某个字段的数据拼接查询，最终还是失败了。由于经验较少，不断尝试column '15'这一列，心想没有15这个字段呀（思维方向错误了）。导致问题排查了两个小时；最后联想到INTEGER类型出错，干脆就直接查找mode里的对象与sql查询查询出来的字段作比较，最终发现其实是某个字段数据值长度突然大增（部门其他同事对接大厂时，修改了字段长度，然后我们这边的系统无意识到字段长度，还是使用Integer类型，最终导致异常出现），修改成long类型后解决，但这种修改方法也会随着时间问题变成一个坑。

总结今晚遇到的问题，就是以前菜的坑太少了，导致问题定位错误。错误日志：'1.00000539598E11' in column '15' is outside valid range for the datatype INTEGER翻译过来也就是“15”列中的“1.00000539598E11”超出了数据类型整数的有效范围。不是15那个字段，而是第15列（MB   太SB了）。因此在此做个笔记，以防以后继续犯类似思维错误。

---