A、修改root用户口令，删除空口令
B、删除默认数据库和数据库用户
C、改变默认mysql管理员帐号
D、关于密码的管理
密码是数据库安全管理的一个很重要因素，不要将纯文本密码保存到数据库中。如果你的计算机有安全危险，***者可以获得所有的密码并使用它们。相反，应使用 MD5()、SHA1()或单向哈希函数。也不要从词典中选择密码，有专门的程序可以破解它们，请选用至少八位，由字母、数字和符号组成的强密码。在存取密码时，使用mysql的内置函数password()的sql语句，对密码进行加密后存储。例如以下方式在users表中加入新用户。
#mysql> insert into users values (1,password(1234),’test’);
E、使用独立用户运行msyql
#vi /etc/my.cnf
[mysqld]
user=mysql
F、禁止远程连接数据库
# vi /etc/my.cf
将#skip-networking注释去掉。
G、限制连接用户的数量
#vi /etc/my.cnf
[mysqld]
max_user_connections 2
H、用户目录权限限制
# chown -R root /usr/local/mysql/ //mysql主目录给root
# chown -R mysql /usr/local/mysql/var //确保数据库目录权限所属mysql用户
I、命令历史记录保护
# rm .bash_history .mysql_history //删除历史记录
# ln -s /dev/null .bash_history //将shell记录文件置空
# ln -s /dev/null .mysql_history //将mysql记录文件置空
J、禁止MySQL对本地文件存取
可以在my.cnf中添加local-infile=0，或者加参数local-infile=0启动mysql。
#/usr/local/mysql/bin/mysqld_safe –user=mysql –local-infile=0 &
K、MySQL服务器权限控制
L、使用chroot方式来控制MySQL的运行目录
M、 Mysqld安全相关启动选项
–local-infile[={0|1}]
如果用–local-infile=0启动服务器，则客户端不能使用LOCAL in LOAD DATA语句。
–old-passwords
强制服务器为新密码生成短(pre-4.1)密码哈希。当服务器必须支持旧版本客户端程序时，为了保证兼容性这很有用。
(OBSOLETE) –safe-show-database
在以前版本的MySQL中，该选项使SHOW DATABASES语句只显示用户具有部分权限的数据库名。在MySQL 5.1中，该选项不再作为现在的 默认行为使用，有一个SHOW DATABASES权限可以用来控制每个账户对数据库名的访问。
–safe-user-create
如果启用，用户不能用GRANT语句创建新用户，除非用户有mysql.user表的INSERT权限。如果你想让用户具有授权权限来创建新用户，你应给用户授予下面的权限：
mysql> GRANT INSERT(user) ON mysql.user TO ‘user_name’@'host_name’;
这样确保用户不能直接更改权限列，必须使用GRANT语句给其它用户授予该权限。
–secure-auth
不允许鉴定有旧(pre-4.1)密码的账户。
N、information_schema 安全
在用户角度来看，INFORMATION_SCHEMA只是一个以插件方式存在的存储引擎，编译安装的时候
–disable-information-schema 就行了
O、Too many connections
解决问题的思路：
1、首先先要考虑在我们 MySQL 数据库参数文件里面，对应的 max_connections 这个参数值是不是设置的太小了，导致客户端连接数超过了数据库所承受的最大值。
对应解决办法：set global max_connections=500
2、其次可以限制 InnoDB的并发处理数量，如果 innodb_thread_concurrency = 0(这种代表不受限制) 可以先改成 16 或是 64 看服务器压力。
另外对于有的监控程序会读取 information_schema 下面的表，可以考虑关闭下面的参数：
innodb_stats_on_metadata=0
set global innodb_stats_on_metadata=0
P、主从复制报错类型
Last_SQL_Errno: 1062 (从库与主库数据冲突)
解决方法：
在确保主从数据一致性的前提下，可以在从库进行错误跳过。一般使用 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冲突)
这个报错出现之后，就能一目了然看到两台机器的 server-id 是一样的。
在搭建主从复制的过程中，我们要确保两台机器的 server-id 是唯一的。这里再强调一下 server-id 的命名规则(服务器 ip 地址的最后一位+本 MySQL 服务的端口号)。
解决方法：在主从两台机器上设置不同的 server-id。
Last_SQL_Errno: 1032(从库少数据，主库更新的时候，从库报错)
解决问题的办法：
根据报错信息，我们可以获取到报错日志和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
获取到SQL语句之后，就可以在从库反向执行SQL语句。把从库缺少的SQL语句补全，解决报错信息。
Q、truncate 删除数据，导致自动清空自增 ID，前端返回报错 not found
个人建议不要使用 truncate 对表进行删除操作，虽然可以回收表空间，但是会涉及自增属性问题。这些坑，我们不要轻易钻进去。
R、阿里云 MySQL 的配置文件
阿里云 MySQL 的配置文件中，需要注意一个参数设置就是：
lower_case_table_names = 0;默认情况。
lower_case_table_names = 1;是不是区分大小写。
如果报你小写的表名找不到，那你就把远端数据库的表名改成小写，反之亦然。注意 Mybatis 的 Mapper 文件的所有表名也要相应修改。
S、数据库总会出现中文乱码的情况
解决思路：对于中文乱码的情况，记住老师告诉你的三个统一就可以。还要知道在目前的 MySQL 数据库中字符集编码都是默认的 UTF8。
处理办法：
数据终端，也就是我们连接数据库的工具设置为 utf8。
操作系统层面，可以通过 cat /etc/sysconfig/i18n 查看，也要设置为 utf8。
数据库层面，在参数文件中的 mysqld 下，加入 character-set-server=utf8。
Emoji 表情符号录入 MySQL 数据库中报错：
解决思路：针对表情插入的问题，一定还是字符集的问题。
处理方法：我们可以直接在参数文件中，加入：
vim /etc/my.cnf
[mysqld]
init-connect=’SET NAMES utf8mb4′
character-set-server=utf8mb4
注：utf8mb4 是 utf8 的超集。
T、使用 binlog_format=statement 这种格式，跨库操作，导致从库丢失数据，用户访问导致出现错误数据信息
当前数据库二进制日志的格式为：binlog_format=statement
在主库设置 binlog-do-db=mydb1(只同步mydb1这一个库)。
在主库执行 use mydb2;
在生产环境中建议使用binlog的格式为row，而且慎用 binlog-do-db 参数。
U、MySQL 数据库连接超时的报错
这个问题是由两个参数影响的，wait_timeout 和 interactive_timeout。
数据默认的配置时间是 28800(8小时)意味着，超过这个时间之后，MySQL 数据库为了节省资源，就会在数据库端断开这个连接，MySQL 服务器端将其断开了，但是我们的程序再次使用这个连接时没有做任何判断，所以就挂了。
解决思路：先要了解这两个参数的特性，这两个参数必须同时设置，而且必须要保证值一致才可以。
我们可以适当加大这个值，8 小时太长了，不适用于生产环境。因为一个连接长时间不工作，还占用我们的连接数，会消耗我们的系统资源。
解决方法：可以适当在程序中做判断，强烈建议在操作结束时更改应用程序逻辑以正确关闭连接，然后设置一个比较合理的 timeout 的值(根据业务情况来判断)。
V、can’t open file (errno:24)
解决思路：首先我们要先查看数据库的 error log。然后判断是表损坏，还是权限问题。还有可能磁盘空间不足导致的不能正常访问表;操作系统的限制也要关注下;用 perror 工具查看具体错误!
超出最大打开文件数限制!ulimit -n 查看系统的最大打开文件数是 65535，不可能超出!那必然是数据库的最大打开文件数超出限制!
在 MySQL 里查看最大打开文件数限制命令：show variables like 'open_files_limit';
发现该数值过小，改为 2048，重启 MySQL，应用正常。
处理方法：
repair table ;
chown mysql 权限
清理磁盘中的垃圾数据