mysql中1146提示_Mysql数据库的使用总结之ERROR 1146 (42S02)

本文详细介绍了在使用MySQL数据库时遇到ERROR1146(42S02): Table doesn’t exist错误的原因及解决方案。错误源于直接复制包含InnoDB引擎的数据库文件夹,特别是ibdata1文件的问题。文章提供了两种解决方法:一是确保源服务停止后再进行文件夹复制;二是创建空数据库并替换特定文件。

在使用mysql数据库过程中,遇到了错误ERROR 1146 (42S02):Table doesn’t exist,经过了两天,终于解决了这个问题。引起该错误的原因不同,对应的解决方法也不同。这里只针对我的情况进行一下说明。可能写的比较乱,希望你慢慢看,下面是我整个从犯错误到解决问题的整个过程,有助于你更好的了解相关知识。

先说一下发生该错误的情形。我是将别人的数据库目录下的data文件夹直接复制过来的,里面有三个数据库mysql、test和backupctrl,主要想要backupctrl数据库,记住不是备份,是拷贝,而且backupctrl是使用innodb作为存储引擎的,这两方面综合起来就导致了1146这个错误。

因为要使用innodb做存储引擎,所以要对my.ini文件进行相应的修改。在my.ini文件中,你可以找到关于innodb的相关设置,但是被注释掉了。因为mysql5.1版本后,innodb不在作为默认的设置了。首先将skip-innodb注释掉,然后需要设置正确innodb的相关参数。

采用innodb存储引擎,关系到data文件夹下面的一些文件:ib_logfile0、ib_logfile1和ibdata1,另外还有一个就是数据库名下面的众多.frm文件。先对这几个文件作简要介绍。

ib_logfile0和ib_logfile1是关于数据库的一些日志文件;

.frm文件是数据库中很多的表的结构描述文件;

ibdata1文件时数据库的真实数据存放文件。

在将别人的data文件夹整个复制过来后,你到mysql目录下的bin文件夹下运行命令:

mysql  --console

此时,你会发现很多的错误提示,该命令就是对环境进行测试的。如果你不理会这些错误,进入数据库,用show tables;命令发现数据库表存在,但是执行select等操作就会出现1146:Table doesn’t exist这个错误了。

其实这是由ibdata1文件的错误引起的,这个应该在日志文件ib_logfile0和ib_logfile1中找到(这个本人没有验证),于是把ibdata1文件删除掉,再次执行该命令,发现没有提示错误了,但进入数据库以后,操作仍就导致1146这个错误。后来仔细一下,也是,你说你把ibdata1文件删除,相当于把数据库的真实数据删除了,这时你就会问为什么数据库表还存在呢,都能看到(其实我当初就是这么想的),因为数据库表结构的描述是在.frm的众多文件中的,所以能通过show tables;查看到。

那么下一个问题就出来了:ibdata1文件是从别人那里拷贝过来的,为什么在那边能用,到我这边就不能用了呢?这就是最核心的问题所在,因为mysql是采用缓冲方式来讲数据写入到ibdata1文件中的,这正是fflush()函数存在的理由。因此当别人的mysql在运行时,你对data文件夹进行拷贝,即对ibdata1进行拷贝肯定会导致该文件中的数据出错的(具体错误原因没有深入学习)。

知道了上面的问题,解决就简单多了,呵呵。首先,将别人的mysql服务停止(这个就不用说了吧,我的前两篇博文中有,你可以参考),然后在拷贝data文件夹,替换到你的相应目录下。这样,你再按照我的博文http://jazka.blog.51cto.com/809003/329423中介绍的方法对数据库进行操作就可以了。

网上查找解决办法时,发现也有不少人有这个问题,而按照停止服务再拷贝的方式还是不行(我刚开始也不行,不过后来就好了,怪了,不知道为什么)。所以这里再说一种方法。首先在自己的mysql下,建立一个你即将要拷贝的数据库(数据库名要一样,里面不需要建表),然后将所有的.frm文件拷贝到你建的数据库文件夹下,此时再次进入mysql,用show  tables查看表是否已经建立起来了。然后停止你自己的mysql服务,发现在data文件下面已经有ib_logfile0、ib_logfile1和ibdata1三个文件了(免安装版解压后是没有的),之后停掉别人的mysql服务,只将ibdata1文件拷贝过来进行覆盖,最后启动你自己的mysql服务就可以对数据库进行正常操作了。

注:需要一个mysql innodb‘ 环境没有问题的 服务器 然后按照 红色字体写的,复制过去后,重新启动mysql 即可得到 正确 的表,然后到处sql文件,就可以随意使用了。

<think> 我们正在解决MySQL报错:ERROR 1146 (42S02): Table 'mysql.procs_priv' doesn't exist 根据引用内容,类似的错误(例如mysql.user表不存在、mysql.servers表不存在)通常是由于数据库系统表缺失或损坏,以及配置文件指向的数据目录错误导致的。 引用[1]中提到,由于没有正确配置my.cnf文件(特别是datadir配置项),导致MySQL无法找到系统表(如mysql.user)。解决方法是确保my.cnf中的datadir指向正确的数据目录。 引用[4]中提到了另一种解决方法:从其他正常MySQL实例中复制缺失的ibdata1和ib_logfile*等文件(这些文件是InnoDB系统表空间和日志文件)到当前数据目录,并设置正确的权限。 现在的问题是Table 'mysql.procs_priv' doesn't exist,这个表也是系统表(存储过程和函数权限相关)。因此,我们可以采用类似的思路解决: 步骤1:检查MySQL配置文件my.cnf(或my.ini)中的datadir配置项,确保指向的数据目录是正确的(即包含完整系统表的数据目录)。 步骤2:如果确认数据目录正确,但表仍然缺失,则可能是系统表损坏或丢失。此时,我们可以尝试以下方法: 方法A:从另一个正常运行的相同版本的MySQL实例中复制mysql数据库的表文件(主要是procs_priv.frm和procs_priv.ibd,但注意MySQL 5.6以上版本使用InnoDB存储系统表,所以需要复制整个mysql库的文件,并注意权限)到当前数据目录的mysql子目录下。但这种方式需要谨慎,因为版本必须严格一致,且最好在MySQL停止时操作。 方法B:使用mysql_upgrade工具修复。该工具可以检查并升级系统表。但注意,如果系统表已经损坏严重,可能无法运行。 步骤3:如果上述方法无效,考虑重新初始化数据目录(但注意备份原有数据)。 由于引用[1]中通过修正datadir解决了问题,我们应首先检查这一点。 详细步骤: 1. 定位my.cnf文件并检查datadir配置: - Linux系统通常位于/etc/my.cnf或/etc/mysql/my.cnf,也可能在数据目录或用户主目录下。 - 使用命令:`mysql --help | grep "my.cnf"` 查看MySQL读取配置文件的顺序。 - 检查datadir配置项,确保它指向正确的数据目录(该目录下应有mysql子目录,里面包含系统表文件)。 2. 如果datadir配置错误,修改为正确的路径,然后重启MySQL。 3. 如果datadir配置正确,但表仍然缺失,则尝试修复系统表: a) 停止MySQL服务:`systemctl stop mysqld` 或 `service mysql stop` b) 备份当前数据目录(整个目录) c) 从相同版本(最好是小版本号也一致)的MySQL实例中复制mysql数据库的procs_priv表文件(注意:对于InnoDB表,需要复制procs_priv.frm和procs_priv.ibd,同时还要注意系统表空间文件ibdata1可能也包含系统表信息,但直接复制ibdata1风险较大,因为可能包含其他表的数据)到当前数据目录的mysql子目录下。然而,更安全的做法是复制整个mysql数据库目录(但要注意,这样会覆盖现有的mysql库,所以必须先备份)。 d) 修改文件权限:确保复制的文件所属用户和组为mysql(或其他运行MySQL的用户),并设置合适的权限(通常是660,目录为700)。 例如:`chown -R mysql:mysql /var/lib/mysql/mysql` e) 启动MySQL服务并检查。 4. 如果表文件复制方法不可行,可以尝试使用mysql_upgrade工具(在MySQL 5.6及以上版本): 首先确保MySQL服务已启动,然后运行:`mysql_upgrade -u root -p`,输入密码。该命令会检查并更新系统表。 5. 如果以上方法都无效,可能需要重新初始化数据目录(注意:这将清空所有数据,包括用户数据库,所以必须提前备份所有数据): a) 停止MySQL服务 b) 备份整个数据目录(例如:/var/lib/mysql) c) 删除数据目录下的所有文件(或者移动到一个备份位置) d) 使用mysqld --initialize命令初始化数据目录(MySQL 5.7及以上版本) 例如:`mysqld --initialize --user=mysql --basedir=/usr --datadir=/var/lib/mysql` e) 启动MySQL服务,此时会生成新的系统表。然后恢复之前备份的用户数据库(注意:mysql系统库不要恢复,否则问题可能再次出现。只恢复用户数据库)。 注意:重新初始化数据目录是最后的手段,因为需要重新创建用户和权限等。 根据引用[4]中提到的,还可以尝试复制ib*文件(ibdata1, ib_logfile0, ib_logfile1等)。这些文件是InnoDB的系统表空间和日志文件,如果这些文件损坏,也会导致系统表无法访问。因此,如果之前有备份,可以尝试用备份的ib*文件替换(同样要注意版本一致)。 总结:优先检查配置文件,然后考虑修复系统表(复制文件或使用mysql_upgrade),最后考虑重新初始化。 由于用户提到是“源码新装的mysql”,很可能是因为安装过程中未正确初始化数据库(或者初始化后配置文件指向了错误的数据目录),所以重点检查配置和数据目录。 请根据实际情况选择合适的方法,并在操作前做好备份。 生成相关问题: 1. 如何正确配置MySQL的datadir? 2. 如何使用mysql_upgrade工具修复系统表? 3. 重新初始化MySQL数据目录的步骤是什么? </think> ### 解决 MySQL ERROR 1146 (42S02): Table 'mysql.procs_priv' doesn't exist 的方法 该错误通常由 **系统表缺失或损坏** 或 **数据目录配置错误** 引起。以下是分步解决方案: --- #### 第一步:检查配置文件 `my.cnf` 1. **定位配置文件** 执行命令查找配置文件路径: ```bash mysql --help | grep "my.cnf" ``` 典型路径:`/etc/my.cnf` 或 `/etc/mysql/my.cnf` 2. **验证 `datadir` 路径** 确保 `datadir` 指向正确的数据目录(含完整系统表): ```bash grep "datadir" /etc/my.cnf ``` ```cnf [mysqld] datadir=/var/lib/mysql # 需与实际数据目录一致 ``` 3. **修正路径后重启** 若路径错误(如编译安装路径与默认路径不符): ```bash systemctl restart mysqld ``` --- #### 第二步:修复系统表 若配置正确仍报错,需手动修复系统表: 1. **停止 MySQL 服务** ```bash systemctl stop mysqld ``` 2. **从其他实例复制系统表** - 从**同版本 MySQL** 的数据目录复制以下文件到当前 `datadir/mysql/`: ``` procs_priv.frm procs_priv.ibd ``` - 同时复制关键 InnoDB 文件(防止表空间损坏): ``` ibdata1 ib_logfile0 ib_logfile1 ``` 3. **修复权限** ```bash chown -R mysql:mysql /var/lib/mysql # 修改为你的datadir路径 chmod 640 /var/lib/mysql/mysql/procs_priv.* ``` 4. **启动服务验证** ```bash systemctl start mysqld mysql -e "SHOW TABLES FROM mysql LIKE 'procs_priv';" # 确认表存在 ``` --- #### 第三步:使用 `mysql_upgrade` 工具 若表仍缺失,运行升级工具修复系统表: ```bash mysql_upgrade -u root -p --force # 强制修复系统表 systemctl restart mysqld ``` --- #### 终极方案:重新初始化数据目录 > 💡 **警告:此操作会清空所有数据,务必先备份!** 1. 备份数据: ```bash mysqldump --all-databases > full_backup.sql ``` 2. 停止服务并删除数据目录: ```bash systemctl stop mysqld rm -rf /var/lib/mysql/* ``` 3. 重新初始化: ```bash mysqld --initialize --user=mysql --datadir=/var/lib/mysql ``` 4. 恢复权限并启动: ```bash chown -R mysql:mysql /var/lib/mysql systemctl start mysqld ``` --- ### 原因分析 - **根本原因**:MySQL 系统表(如 `procs_priv`)未正确初始化或配置指向了空/错误的数据目录[^1][^4]。 - **常见场景**: - 源码编译安装时未指定正确 `datadir`[^1] - 意外删除 `ibdata1` 等 InnoDB 系统表空间文件[^4] - 跨版本升级未执行 `mysql_upgrade`[^2] --- ### 相关问题 1. 如何避免 MySQL 系统表损坏? 2. `mysql_upgrade` 工具的具体作用和使用场景是什么? 3. 重新初始化 MySQL 数据目录后如何恢复用户数据库? [^1]: 配置文件错误导致找不到系统表 [^2]: 系统表缺失引发权限校验失败 [^4]: InnoDB 表空间文件损坏解决方案
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值