本文目录一览：
- 1、求助！mysql数据库打不开了显示 1286 - Unknown storage engine 'InnoDB'
- 2、为什么启动mysql数据库之后，过几分钟又显示数据库没有连接，又要重新启动，之前是win8系统没有
- 3、zabbix添加mysql监控后没数据怎么办
- 4、如何实现监控mysql，并将有变动的数据表写入指定的文件夹？
- 5、数据库mysql创建表格老是出错，看不懂英文提示？
求助！mysql数据库打不开了显示 1286 - Unknown storage engine 'InnoDB'
你把INNODB日志弄坏了吧！
别随便修改存储引擎，启动不起来你认真查一下配置文件，对不对。
mysql配置只要随便一个配置参数错误就启不来。
如果配置参数都对，能否先运行一下修复命令。
都不行，检查一下磁盘，磁道是不是坏了。
但愿你修改的不是生产环境，要不老板估计要让你下课，最轻也会被训。
为什么启动mysql数据库之后，过几分钟又显示数据库没有连接，又要重新启动，之前是win8系统没有
解决办法：
第一步
删除c:\windows\下面的my.ini
第二步
打开c:\mysql\bin\winmysqladmin.exe 输入用户名 和密码
第三步 在dos下 输入 mysqld-nt -remove 删除服务
在接着输入 mysqld-nt -install
第四步 输入mysql 启动成功。
其它可参考的方法：
1.看看hosts文件中localhost是不是指向127.0.0.1
2.如果是没启动mysql服务，则可运行net start mysql。
3.一些相关命令：
mysqld-nt --install #启动Mysql
mysql #运行Mysql
mysql -h ipAddress -u username -p
或者：直接去bin里点mysqld.exe或mysqld-nt.exe，看下它的进程能否正常运行，如不行，再去控制面板，服务里去启动它，看下是什么错误。如果不行，就在添加删除里删去mysql，然后再重装mysql，一般都能解决问题，可以在安装前备份一下DATA。
Error: Can't connect to MySQL server on 'localhost' (10061)
Errno.: 2003
错误编号：2003
问题分析：
无法连接到 MySQL 服务器，可能的情况为：
1、MySQL 服务没有启动，一般是在异常的情况下 MySQL 无法启动导致的，比如无可用的磁盘空间，my.ini 里 MySQL 的 basedir 路径设置错误等；
2、MySQL 服务器资源紧张，导致无法连接。
解决方法：
1、如果你是虚拟主机用户（购买的空间），则联系空间商检查 MySQL 是否正常启动，并确认 MySQL 的配置信息（是否为 localhost）；
2、如果你是独立主机用户（拥有管理主机权限），则按下面步骤检查：
1）检查磁盘空间是否还有剩余可用空间，尽量保持有足够的磁盘空间可用。
2）检查 my.ini 里的 basedir （MySQL 安装地址） 和 datadir （数据目录存放地址）等参数设置是否正确，然后重新启动下 MySQL 服务。
还有一种方法是将服务器的windows补丁。
微软9月9日发布了TCP/IP更新补丁（KB967723），如果服务器开启自动更新或者有自动更新软件下载更新了这个补丁，那么就会出现这个问题。
有人可能会问，为什么9号出现的补丁，到现在才发现问题？
大家都知道，服务器不是每天都重启的，有的服务器可能一个月或者一年半载重启一次，有的可能在9月9日以后重启过服务器，所以补丁生效了（我个人这么认为）。
补丁卸载方法：登录服务器，进入控制面板 --- 添加和删除程序 -- （勾选上方的“显示更新”）
在里面可以看到更新的KB967723这个补丁，然后就想卸载普通软件一样卸载，卸载中会提示你，如果卸载可能导致程序运行出错，没关系，选择“是”，继续卸载。
卸载完成后程序服务器，一切正常！
至于该补丁修补什么漏洞，卸载后是否会出现服务器安全隐患，这个先不说，要MYSQL正常运行，临时的解决办法只有如此。
还有种情况下，你可以这样解决
Discuz! info: Can not connect to MySQL server
Time: 2007-11-13 6:25pm
Script: /bbs/index.php
Error: Can't connect to MySQL server on 'localhost' (10061)
Errno.: 2003
Similar error report has beed dispatched to administrator before.
正常情况下原因如下:
网站论坛访问量过大,数据库连接超过最大连接数.MYSQL数据库服务停止了.
解决方法(针对WIN系统):
1, 首先到系统服务里面找到MYSQL服务并启动MYSQL服务.
2, 到MYSQL安装目录找到MY.INI文件,打开MY.INI查找max_connections 修改连接数为1000 重启IIS与MYSQL服务.
window 下
命令行下输入：
cd E:\mysql\bin
mysqladmin -u root password 你的密码
mysql -u root -p
Enter password: 你的密码
便可以
、、、、、、、、、、、、、、、、、
找到了根本原因，在此凉一下：
导致此问题的根源在：因为给mysql的root设置了密码，而不是最初安装好时的密码为空，所以使用
mysqladmin version这样子不行了，必须这样子：mysqladmin -uroot -p version，回车后按照提示要求输入
root密码即可成功运行命令。
第一种方法其实就是在不知道root密码的情况下的一种解决办法，那样子启动不用密码即可进mysql
里面并进行root密码的修改，解决忘记了root密码的问题。
输入命令“mysqladmin -u root password 你的密码”作用是修改root用户的密码，这条命令能够不经
提示输入原密码而成功执行，也说明了原密码是空。之后使用修改后的密码自然能够成功登录。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。怎么更改密码？
首先要声明一点，大部分情况下，修改MySQL是需要有mysql里的root权限的，所以一般用户无法更改密码
，除非请求管理员。
方法一
使用phpmyadmin，这是最简单的了，修改mysql库的user表，
不过别忘了使用PASSWORD函数。
方法二
使用mysqladmin，这是前面声明的一个特例。
mysqladmin -u root -p password mypasswd
输入这个命令后，需要输入root的原密码，然后root的密码将改为mypasswd。
把命令里的root改为你的用户名，你就可以改你自己的密码了。
当然如果你的mysqladmin连接不上mysql server，或者你没有办法执行mysqladmin，
那么这种方法就是无效的。
而且mysqladmin无法把密码清空。
下面的方法都在mysql提示符下使用，且必须有mysql的root权限：
方法三
mysql INSERT INTO mysql.user (Host,User,Password)
VALUES('%','jeffrey',PASSWORD('biscuit'));
mysql FLUSH PRIVILEGES
确切地说这是在增加一个用户，用户名为jeffrey，密码为biscuit。
在《mysql中文参考手册》里有这个例子，所以我也就写出来了。
注意要使用PASSWORD函数，然后还要使用FLUSH PRIVILEGES。
方法四
和方法三一样，只是使用了REPLACE语句
mysql REPLACE INTO mysql.user (Host,User,Password)
VALUES('%','jeffrey',PASSWORD('biscuit'));
mysql FLUSH PRIVILEGES
方法五
使用SET PASSWORD语句，
mysql SET PASSWORD FOR " = PASSWORD('biscuit');
拟也必须使用PASSWORD()函数，
但是不需要使用FLUSH PRIVILEGES。
方法六
使用GRANT ... IDENTIFIED BY语句
mysql GRANT USAGE ON *.* TO " IDENTIFIED BY 'biscuit';
这里PASSWORD()函数是不必要的，也不需要使用FLUSH PRIVILEGES。
注意： PASSWORD() [不是]以在Unix口令加密的同样方法施行口令加密。
MySQL 忘记口令的解决办法
如果 MySQL 正在运行，首先杀之： killall -TERM mysqld。
启动 MySQL ：bin/safe_mysqld --skip-grant-tables
就可以不需要密码就进入 MySQL 了。
然后就是
use mysql
update user set password=password("new_pass") where user="root";
flush privileges;
重新杀 MySQL ，用正常方法启动 MySQL 。
linux下
方法一：
# /etc/init.d/mysql stop
# mysqld_safe --user=mysql --skip-grant-tables --skip-networking
# mysql -u root mysql
mysql UPDATE user SET Password=PASSWORD('newpassword') where USER='root';
mysql FLUSH PRIVILE
zabbix添加mysql监控后没数据怎么办
有两种方法，一种方法使用mysql的check table和repair table 的sql语句，另一种方法是使用MySQL提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。
1. check table 和 repair table
登陆mysql 终端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出现的结果说Status是OK，则不用修复，如果有Error，可以用：
repair table tabTest;
进行修复，修复之后可以在用check table命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk适用于MYISAM类型的数据表，而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同，一般新的系统都使用MYISAM作为缺省的数据表类型，这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用：
myisamchk tablename.MYI
进行检测，如果需要修复的话，可以使用：
myisamchk -of tablename.MYI
关于myisamchk的详细参数说明，可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL服务器没有访问这个数据表，保险的情况下是最好在进行检测时把MySQL服务器Shutdown掉。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
另外可以把下面的命令放在你的rc.local里面启动MySQL服务器前：
[ -x /tmp/mysql.sock ] /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL监听的Sock文件位置，对于使用RPM安装的用户应该是/var/lib/mysql/mysql.sock，对于使用源码安装则是/tmp/mysql.sock可以根据自己的实际情况进行变更，而pathtochk则是myisamchk所在的位置，DATA_DIR是你的MySQL数据库存放的位置。
需要注意的时，如果你打算把这条命令放在你的rc.local里面，必须确认在执行这条指令时MySQL服务器必须没有启动！检测修复所有数据库(表)
如何实现监控mysql，并将有变动的数据表写入指定的文件夹？
首先介绍下 pt-stalk，它是 Percona-Toolkit 工具包中的一个工具，说起 PT 工具包大家都不陌生，平时常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于这个工具包，这里就不多介绍了。
pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息，这其中包括：
1. OS 层面的 CPU、IO、内存、磁盘、网络等信息；
2. MySQL 层面的行锁等待、会话连接、主从复制，状态参数等信息。
而且 pt-stalk 是一个 Shell脚本，对于我这种看不懂 perl 的人来说比较友好，脚本里面的监控逻辑与监控命令也可以拿来参考，用于构建自己的监控体系。
三、使用
接着我们来看下如何使用这个工具。
pt-stalk 通常以后台服务形式监控 MySQL 并等待触发条件，当触发条件时收集相关诊断数据。
触发条件相关的参数有以下几个：
function：
∘ 默认为 status，代表监控 SHOW GLOBAL STATUS 的输出；
∘ 也可以设置为 processlist，代表监控 show processlist 的输出；
variable：
∘ 默认为 Threads_running，代表 监控参数，根据上述监控输出指定具体的监控项；
threshold：
∘ 默认为 25，代表 监控阈值，监控参数超过阈值，则满足触发条件；
∘ 监控参数的值非数字时，需要配合 match 参数一起使用，如 processlist 的 state 列；
cycles：
∘ 默认为 5，表示连续观察到五次满足触发条件时，才触发收集；
连接参数：host、password、port、socket。
其他一些重要参数：
iterations：该参数指定 pt-stalk 在触发收集几次后退出，默认会一直运行。
run-time：触发收集后，该参数指定收集多长时间的数据，默认 30 秒。
sleep：该参数指定在触发收集后，sleep 多久后继续监控，默认 300 秒。
interval：指定状态参数的检查频率，判断是否需要触发收集，默认 1 秒。
dest：监控数据存放路径，默认为 /var/lib/pt-stalk。
retention-time ：监控数据保留时长，默认 30 天。
daemonize：以后台服务运行，默认不开启。
log：后台运行日志，默认为 /var/log/pt-stalk.log。
collect：触发发生时收集诊断数据，默认开启。
∘ collect-gdb：收集 GDB 堆栈跟踪，需要 gdb 工具。
∘ collect-strace：收集跟踪数据，需要 strace 工具。
∘ collect-tcpdump：收集 tcpdump 数据，需要 tcpdump 工具。
数据库mysql创建表格老是出错，看不懂英文提示？
来自：51CTO（作者：superZS）
我在刚开始学习数据库的时候，没少走弯路。经常会遇到各种稀奇古怪的 error 信息，遇到报错会很慌张，急需一个解决问题的办法。跟无头苍蝇一样，会不加思索地把错误粘到百度上，希望赶紧查找一下有没有好的处理问题的方法。我想这个应该是刚从事数据库的小白，都会遇到窘境。
今天就给大家列举 MySQL 数据库中，最经典的十大错误案例，并附有处理问题的解决思路和方法，希望能给刚入行，或数据库爱好者一些帮助，今后再遇到任何报错，我们都可以很淡定地去处理。
学习任何一门技术的同时，其实就是自我修炼的过程。沉下心，尝试去拥抱数据的世界！
Top 1：
Too many connections（连接数过多，导致连接不上数据库，业务无法正常进行）
问题还原
解决问题的思路：
1、首先先要考虑在我们 MySQL 数据库参数文件里面，对应的 max_connections 这个参数值是不是设置的太小了，导致客户端连接数超过了数据库所承受的最大值。
● 该值默认大小是151，我们可以根据实际情况进行调整。
● 对应解决办法：set global max_connections=500
但这样调整会有隐患，因为我们无法确认数据库是否可以承担这么大的连接压力，就好比原来一个人只能吃一个馒头，但现在却非要让他吃 10 个，他肯定接受不了。反应到服务器上面，就有可能会出现宕机的可能。
所以这又反应出了，我们在新上线一个业务系统的时候，要做好压力测试。保证后期对数据库进行优化调整。
2、其次可以限制 Innodb 的并发处理数量，如果 innodb_thread_concurrency = 0（这种代表不受限制） 可以先改成 16或是64 看服务器压力。如果非常大，可以先改的小一点让服务器的压力下来之后,然后再慢慢增大,根据自己的业务而定。个人建议可以先调整为 16 即可。
MySQL 随着连接数的增加性能是会下降的，可以让开发配合设置 thread pool，连接复用。在MySQL商业版中加入了thread pool这项功能
另外对于有的监控程序会读取 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: Could not execute Write_rows event on table test.t;
Duplicate entry '4' for key 'PRIMARY',
Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY;
the event's master log mysql-bin.000014, 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（server-id冲突）
Last_IO_Error:
Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids;
these ids must be different for replication to work
(or the --replicate-same-server-id option must be used on slave but this
does not always make sense; please check the manual before using it)
这个报错出现之后，就看一目了然看到两台机器的 server-id 是一样的。
在搭建主从复制的过程中，我们要确保两台机器的 server-id 是唯一的。这里再强调一下 server-id 的命名规则（服务器 ip 地址的最后一位+本 MySQL 服务的端口号）
解决方法：
在主从两台机器上设置不同的 server-id。
Last_SQL_Errno: 1032（从库少数据，主库更新的时候，从库报错）
Last_SQL_Error:
Could not execute Update_rows event on table test.t; Can't find record
in 't', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the
event's master log mysql-bin.000014, end_log_pos 1708
解决问题的办法：
根据报错信息，我们可以获取到报错日志和position号，然后就能找到主库执行的哪条sql，导致的主从报错。
在主库执行：
/usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=decode-rows /data/mysql/mysql-bin.000014 |grep -A 10 1708 1.log
cat 1.log
#170720 14:20:15 server id 3 end_log_pos 1708 CRC32 0x97b6bdec Update_rows: table id 113 flags: STMT_END_F
### UPDATE `test`.`t`
### WHERE
### @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 */
# at 1708
#170720 14:20:15 server id 3 end_log_pos 1739 CRC32 0xecaf1922 Xid = 654
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
获取到 sql 语句之后，就可以在从库反向执行 sql 语句。把从库缺少的 sql 语句补全，解决报错信息。
在从库依次执行：
mysql insert into t (b) values ('ddd');
Query OK, 1 row affected (0.01 sec)
mysql stop slave;
Query OK, 0 rows affected (0.00 sec)
mysql exit
Bye
[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/my.cnf [1] 3758
[root@zs data]# 170720 14:41:24 mysqld_safe Logging to '/data/mysql/error.log'.
170720 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql170720
14:41:25 mysqld_safe mysqld from pid file /data/mysql/node4.pid ended
170720 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql2017-07-20
14:41:25 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated.
Please use --explicit_defaults_for_timestamp server option
(see documentation for more details)./usr/local/mysql/bin/mysqld:
File '/data/mysql/mysql-bin.index' not found (Errcode: 13 - Permission denied)
2017-07-20 14:41:25 4388 [ERROR] Aborting
解决思路：
遇到这样的报错信息，我们要学会时时去关注错误日志 error log 里面的内容。看见了关键的报错点 Permission denied。证明当前 MySQL 数据库的数据目录没有权限。
解决方法：
[root@zs data]# chown mysql:mysql -R mysql
[root@zs data]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf
[1] 4402
[root@zs data]# 170720 14:45:56 mysqld_safe Logging to '/data/mysql/error.log'.
170720 14:45:56 mysqld_safe Starting mysqld daemon with databases from /data/mysql
启动成功。
如何避免这类问题，个人建议在安装 MySQL 初始化的时候，一定加上--user=mysql，这样就可以避免权限问题。
./mysql_install_db --basedir=/usr/local/mysql/ --datadir=/data/mysql/ --defaults-file=/etc/my.cnf --user=mysql
Top 4：数据库密码忘记的问题
[root@zs ~]# mysql -uroot -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
[root@zs ~]# mysql -uroot -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
我们有可能刚刚接手别人的 MySQL 数据库，而且没有完善的交接文档。root 密码可以丢失或者忘记了。
解决思路：
目前是进入不了数据库的情况，所以我们要考虑是不是可以跳过权限。因为在数据库中，mysql数据库中user表记录着我们用户的信息。
解决方法：
启动 MySQL 数据库的过程中，可以这样执行：
/usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf --skip-grant-tables
这样启动，就可以不用输入密码，直接进入 mysql 数据库了。然后在修改你自己想要改的root密码即可。
update mysql.user set password=password('root123') where user='root';
Top 5：truncate 删除数据，导致自动清空自增ID，前端返回报错 not found。
这个问题的出现，就要考虑下 truncate 和 delete 的区别了。
看下实验演练：
首先先创建一张表；
CREATE TABLE `t` (
`a` int(11) NOT NULL AUTO_INCREMENT,
`b` varchar(20) DEFAULT NULL,
PRIMARY KEY (`a`),
KEY `b` (`b`)
) ENGINE=InnoDB AUTO_INCREMENT=300 DEFAULT CHARSET=utf8
插入三条数据：
mysql insert into t (b) values ('aa');
Query OK, 1 row affected (0.00 sec)
mysql insert into t (b) values ('bb');
Query OK, 1 row affected (0.00 sec)
mysql insert into t (b) values ('cc');
Query OK, 1 row affected (0.00 sec)
mysql select * from t;
+-----+------+
| a | b |
+-----+------+
| 300 | aa |
| 301 | bb |
| 302 | cc |
+-----+------+
3 rows in set (0.00 sec)
先用 delete 进行删除全表信息，再插入新值。
结果发现 truncate 把自增初始值重置了，自增属性从1开始记录了。当前端用主键id进行查询时，就会报没有这条数据的错误。
个人建议不要使用 truncate 对表进行删除操作，虽然可以回收表空间，但是会涉及自增属性问题。这些坑，我们不要轻易钻进去。
Top 6：
阿里云 MySQL 的配置文件中，需要注意一个参数设置就是：
lower_case_table_names = 0;默认情况
lower_case_table_names = 1;是不区分大小写 . 如果报你小写的表名找不到, 那你就把远端数据库的表名改成小写 , 反之亦然 . 注意 Mybatis 的 Mapper 文件的所有表名也要相应修改
Top 7：
有同学经常会问张老师，为什么我的数据库总会出现中文乱码的情况。一堆？？？？不知道怎么回事。当向数据库中写入创建表，并插入中文时，会出现这种问题。此报错会涉及数据库字符集的问题。
解决思路：
对于中文乱码的情况，记住老师告诉你的三个统一就可以。还要知道在目前的mysql数据库中字符集编码都是默认的UTF8
处理办法：
1、数据终端，也就是我们连接数据库的工具设置为 utf8
2、操作系统层面；可以通过 cat /etc/sysconfig/i18n 查看；也要设置为 utf8
3、数据库层面；在参数文件中的 mysqld 下，加入 character-set-server=utf8。
Emoji 表情符号录入 mysql 数据库中报错。
Caused by: java.sql.SQLException: Incorrect string value: '\xF0\x9F\x98\x97\xF0\x9F...' for column 'CONTENT' at row 1
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1074)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4096)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4028)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2734)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2155)
at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1379)
解决思路：针对表情插入的问题，一定还是字符集的问题。
处理方法：我们可以直接在参数文件中，加入
vim /etc/my.cnf
[mysqld]
init-connect='SET NAMES utf8mb4'
character-set-server=utf8mb4
注：utf8mb4 是 utf8 的超集。
Top 8：使用 binlog_format=statement 这种格式，跨库操作，导致从库丢失数据，用户访问导致出现错误数据信息。
当前数据库二进制日志的格式为：binlog_format=statement
在主库设置binlog-do-db=mydb1（只同步mydb1这一个库）
在主库执行use mydb2；
insert into mydb1.t1 values ('bb');这条语句不会同步到从库。
但是这样操作就可以；
use mydb1;
insert into mydb1.t1 values ('bb');因为这是在同一个库中完成的操作。
在生产环境中建议使用binlog的格式为row，而且慎用binlog-do-db参数。
Top 9：MySQL 数据库连接超时的报错 ；
org.hibernate.util.JDBCExceptionReporter - SQL Error:0, SQLState: 08S01
org.hibernate.util.JDBCExceptionReporter - The last packet successfully received from the server was43200 milliseconds ago.The last packet sent successfully to the server was 43200 milliseconds ago, which is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection 'autoReconnect=true' to avoid this problem.
org.hibernate.event.def.AbstractFlushingEventListener - Could not synchronize database state with session
org.hibernate.exception.JDBCConnectionException: Could not execute JDBC batch update
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Connection.close() has already been called. Invalid operation in this state.
org.hibernate.util.JDBCExceptionReporter - SQL Error:0, SQLState: 08003
org.hibernate.util.JDBCExceptionReporter - No operations allowed after connection closed. Connection was implicitly closed due to underlying exception/error:
** BEGIN NESTED EXCEPTION **
大多数做 DBA 的同学，可能都会被开发人员告知，你们的数据库报了这个错误了。赶紧看看是哪里的问题。
这个问题是由两个参数影响的，wait_timeout 和 interactive_timeout。数据默认的配置时间是28800（8小时）意味着，超过这个时间之后，MySQL 数据库为了节省资源，就会在数据库端断开这个连接，Mysql服务器端将其断开了，但是我们的程序再次使用这个连接时没有做任何判断，所以就挂了。
解决思路：
先要了解这两个参数的特性；这两个参数必须同时设置，而且必须要保证值一致才可以。
我们可以适当加大这个值，8小时太长了，不适用于生产环境。因为一个连接长时间不工作，还占用我们的连接数，会消耗我们的系统资源。
解决方法：
可以适当在程序中做判断；强烈建议在操作结束时更改应用程序逻辑以正确关闭连接；然后设置一个比较合理的timeout的值（根据业务情况来判断）
Top 10 ：can't open file (errno:24)
有的时候，数据库跑得好好的，突然报不能打开数据库文件的错误了。
解决思路：
首先我们要先查看数据库的 error log。然后判断是表损坏，还是权限问题。还有可能磁盘空间不足导致的不能正常访问表；操作系统的限制也要关注下；用 perror 工具查看具体错误！
linux:/usr/local/mysql/bin # ./perror 24
OS error code 24: Too many open files
超出最大打开文件数限制！ulimit -n查看系统的最大打开文件数是65535，不可能超出！那必然是数据库的最大打开文件数超出限制！
在 MySQL 里查看最大打开文件数限制命令：show variables like 'open_files_limit';
发现该数值过小，改为2048，重启 MySQL，应用正常
处理方法：
repair table ；
chown mysql权限
清理磁盘中的垃圾数据
