mysql 错误代码1217 MYSQL外键约束检查失败,删除或修改主表记录失败 怎么解决啊

mysql 错误代码1217 MYSQL外键约束检查失败,删除或修改主表记录失败 怎么解决啊,第1张

这是一项新功能,用于指定在插入或更新到一行之前检查值的条件。如果表的任何行的搜索条件的结果为 FALSE,则约束可能返回错误(但如果结果为 UNKNOWN 或 TRUE,则约束不会返回错误)。此功能开始在 MySQL 8.0.16 上运行,在以前的版本中,我们可以创建它,但它不起作用,这意味着支持语法,但不起作用。要牢记的使用规则:

AUTO_INCREMENT 自增列不允许使用

引用另一个表中的另一列不允许使用

存储的函数和用户定义的函数不允许使用

存储过程和函数参数不允许使用

子查询不允许使用

在外键中用于后续 *** 作(ON UPDATE,ON DELETE)的列不允许使用

为下一条语句 INSERT,UPDATE,REPLACE,LOAD DATA 和 LOAD XML 评估此次监测。此外,还会为 INSERT IGNORE,UPDATE IGNORE,LOAD DATA…IGNORE 和 LOAD XML…IGNORE 评估此监测约束。对于这些语句,如果约束的评估结果为 FALSE,则会发生警告。插入或更新被跳过。

我们可以使用此功能在表中添加更多的逻辑,但是根据我以前作为程序员的经验,我不建议在表中添加逻辑,因为除非您无法访问应用程序代码,否则很难找到或调试错误。

使用命令行方式登陆到MySQL服务器, 建立一个数据库,数据库编码设为UTF-8。此时,如果直接在命令行窗口使用insert语句插入中文,就遇到类似 ERROR 1406 (22001): Data too long for column 'name' at row 1 错误。乍一看,是字段长度引起的问题,但是实际是字符编码的问题。可是尝试以下解决方法:

1、在Linux中,使用终端方式登陆MySQL服务器,运行以下命令:

set names utf8

该命令将终端的字符编码设为了UTF-8。此后再插入数据库中的内容都会按照UTF-8的编码来处理。

2、在Windows下,命令行窗口不支持UTF-8编码,所以使用“set names utf8”不会达到转化中文的效果。

所以在windows命令窗口下 使用:set names gbk

告之mysql你是以gbk编码方式来 *** 作的

然后再把你上面插入的代码在记事本等编辑器里面吧字符编码改为gbk编码;

在记事本中保存的编码我 ANSI

一、无法访问系统资源

MySQL 不能访问启动需要的资源是造成而 MySQL 无法启动的一个常见原因,如:文件,端口等。由于 linux 中用于启动 mysqld 进程的 mysql 用户通常是不能登陆的,可以使用类似下面的命令检查文件的访问权限。

sudo -u mysql touch /var/lib/mysql/b

找出问题后,修改对应文件或目录的权限或属主后通常可以解决问题。但有时 mysql 用户有访问文件和目录的权限,但仍然会被拒绝访问,例如下面这个例子:

mysql>system sudo -u mysql touch /home/mysql/data/a

mysql>create table t1 (

id int primary key,n varchar(10

) data directory

ERROR 1030 (HY000): Got error 168 from storage engine

测试说明 mysql 用户有这个目录的访问权限,但创建文件还是失败,这种情况让很多人困惑,这个时候通常是 mysqld 进程的访问被 linux 的 selinux 或 apparmor 给阻止了,大家可以看到创建的表不是在 mysql 的默认目录下面,因此 selinux 或 apparmor 的 policy 里面没有包含这个目录的访问权限,此时只要对应的修改 policy 就行了,当然把 selinux 或 apparmor 停了也行。

有时虽然对系统资源有访问的权限,但系统资源已经被占用:

mysqld --no-defaults --console --user mysql

2020-11-03T03:36:07.519419Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.19) starting as process 21171

2020-11-03T03:36:07.740347Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11

这个故障产生的原因是另外一个 mysqld 进程已经启动并占用了对应的文件。

二、参数设置错误

参数设置错误造成 MySQL 无法启动的原因也非常常见,此时先要检查 MySQL 启动时会调用的参数,下面的命令可以查询 MySQL 启动时调用参数文件的顺序:

$ mysqld --verbose --help | grep "Default options " -A 1

Default options are read from the following files in the given order:

/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf

知道了 MySQL 参数文件的调用顺序,我们就可以检查对应的参数文件,找出其中的错误,如果觉得参数文件的可读性不强,可以使用下面的命令显示 mysqld 程序将要调用的参数:

$ mysqld --print-defaults

/usr/sbin/mysqld would have been started with the following arguments:

......

注意这个命令显示完参数后就退出,不会真正运行 mysqld。这个命令和 my_print_defaults mysqld 完全是等价的,只不过后者的显示方式是一行一个参数。

然后开始对可疑的参数进行调试,我个人喜欢加的参数和顺序如下:

1. 在 mysqld 后加上第一个参数 --no-defaults ,这个参数的作用是通知 mysqld 在启动的时候不要读任何参数文件;

2. 第二个参数是 --console,这个参数会把错误信息输出到屏幕上,这个参数带来的一个弊端是所有的信息都输出到屏幕上,让屏幕显得比较乱,但对于我们调试却是很方便的;

3. 第三个参数是 --log-error-verbosity=3,这个参数会显示详细的日志;

4. 然后再在后面加上有把握的参数,可以一次只加一个参数,然后启动 mysqld,采用排除法逐步找出错误的参数。


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/zaji/8642116.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-19
下一篇2023-04-19

发表评论

登录后才能评论

评论列表(0条)

    保存