mysql数据库运用mysqldump命令过后没有反应是什么情况。如图。

通用规律只有使用 --all-databases (-A) 会 ERROR 1356，那就看看他到底备份了什么东西。于是喊上同事一起 less 看了下，上下扫了两眼。突然发现：1. 备份 SQL 文件里 DROP 掉了 mysql.proc；2. 后CREATE了一个新的 mysql.proc；3. LOCK TABLES 和 UNLOCK TABLES 中间居然没有备份 CREATE ROUTINE 任何数据？这不就是相当于每次导入全备都给我一个没有任何 sys schema routines 的全新 mysql.proc 表？那这不就异常的尴尬？

---- Table structure for table `proc`--

---- Dumping data for table `proc`-

真相大白在官方文档【sys-schema-usage】官方文档明确的告诉我们不会备份 sys 库。但在使用 mysqldump 在执行 --all-databases 会清空 mysql.proc 导致 sys 无法正常使用；这是一个 BUG，并且只存在于 MySQL 5.7.x ！

1、mysql_upgrade install or upgrade sys schema

这个方案适用于 sys 库已经因为 mysqldump 导入而损坏的情况下使用。

注意：mysql_upgrade 在修理 sys 库的同时，还修理 mysql 库和用户库表（期间加锁且速度一般），有极小可能会误伤；使用 mysql_upgrade 的时候要加上 --upgrade-system-tables，不然会扫描用户库表。

2、全备时同时备份 sys 库

这个方案适用于需要还原的数据库，sys 库也不太正常的情况下使用；在全备后额外再备份一份 sys 库用于修复。

注意：不适用于做主从时使用它。

3、使用 databases 全备

这个方案适用于所有场景的全备需求，100% 安全。

4、使用 mysql-sys 开源代码

如果你的数据库 sys 全部中招了，又是生产库。那你只能用这个方法；

mysql-sys：https://github.com/mysql/mysql-sys

中记录了 sys 库的创建语句将文件下载到本地，然后根据数据库版本，执行以下命令即可。

在出现数据库无响应故障后，首先确认系统的影响范围，如上节所描述的，是部分业务系统或模块还是所有的业务系统都受影响，是不是整个实例或多个实例都无响应。 同时应询问系统维护和开发人员，受影响的系统在出现故障前是否有过变动，包括主机硬件、 *** 作系统、网络、数据库以及应用等。 有时一个细小的变动就可能导致出现数据库Hang住这样严重的故障。 曾经遇到一个库

解决方法：

1、使用service启动—命令为：service mysqld start，service mysql start，mysql 5 以后就用mysqld来启动。

2、使用mysqld脚本启动—命令为：/etc/init.d/mysqld start/etc/init.d/mysqld 为mysql安装路径。

3、使用service关闭—命令为：service mysqld stopservice mysql stop，mysql 5 以后就用mysqld来关闭。

4、使用mysqld脚本关闭—命令为：/etc/init.d/mysqld stop/etc/init.d/mysqld 为mysql安装路径。

5、使用service重启—命令为：。service mysqld restart。service mysql restart。mysql 5 以后就用mysqld来重启。

6、使用mysqld脚本重启—命令为：/etc/init.d/mysqld restart/etc/init.d/mysqld 为mysql安装路径。

---