1. Too many connections

连接数过多, 导致连接不上数据库, 业务无法正常进行)
问题还原:

mysql>show variables like '%max_connect%';
+--------------------+-------+
|Variable_name|Value|
+--------------------+-------+
|max_connect_errors|10|
|max_connections|151|
+--------------------+-------+

解决问题的思路:

• 1.首先先要考虑在我们 MySQL 数据库参数文件里面, 对应的max_connections 这个参数值是不是设置的太小了, 导致客户端连接数超过了数据库所承受的最大值。

  • 该值默认大小是151, 我们可以根据实际情况进行调整。
  • 对应解决办法: set global max_connections=500
    但这样调整会有隐患, 因为我们无法确认数据库是否可以承担这么大的连接压力, 就好比原来一个人只能吃一个馒头, 但现在却非要让他吃 10 个, 他肯定接受不了。反应到服务器上面, 就有可能会出现宕机的可能。所以这又反应出了, 我们在新上线一个业务系统的时候, 要做好压力测试。保证后期对数据库进行优化调整。

• 其次可以限制Innodb 的并发处理数量
  如果 innodb_thread_concurrency = 0(这种代表不受限制) 可以先改成 16或是64 看服务器压力。如果非常大, 可以先改的小一点让服务器的压力下来之后,然后再慢慢增大,根据自己的业务而定。个人建议可以先调整为 16 即可。

mysql>show variables like '%innodb_thread_concurrency%';
+---------------------------+-------+
|Variable_name|Value|
+---------------------------+-------+
|innodb_thread_concurrency|0|
+---------------------------+-------+

MySQL 随着连接数的增加性能是会下降的, 可以让开发配合设置 thread pool, 连接复用。在MySQL商业版中加入了thread pool这项功能,另外对于有的监控程序会读取 information_schema 下面的表, 可以考虑关闭下面的参数

2. 主从复制报错类型

2.1 Last_SQL_Errno: 1062 (从库与主库数据冲突)

针对这个报错, 我们首先要考虑是不是在从库中误操作导致的。结果发现, 我们在从库中进行了一条针对有主键表的 sql 语句的插入, 导致主库再插入相同 sql 的时候, 主从状态出现异常。发生主键冲突的报错。

解决方法:
在确保主从数据一致性的前提下, 可以在从库进行错误跳过。一般使用 percona-toolkit 中的 pt-slave-restart 进行。在从库完成如下操作:

之后最好在从库中开启 read_only 参数, 禁止在从库进行写入操作

2.2 Last_IO_Errno: 1593(server-id冲突)

在搭建主从复制的过程中, 我们要确保两台机器的 server-id 是唯一的。这里再强调一下 server-id 的命名规则(服务器 ip 地址的最后一位+本 MySQL 服务的端口号)
解决方法:
在主从两台机器上设置不同的 server-id。

2.3 Last_SQL_Errno: 1032(从库少数据, 主库更新的时候, 从库报错)

解决问题的办法:
根据报错信息, 我们可以获取到报错日志和position号, 然后就能找到主库执行的哪条sql, 导致的主从报错。
在主库执行:

获取到 sql 语句之后, 就可以在从库反向执行 sql 语句。把从库缺少的 sql 语句补全, 解决报错信息。
在从库依次执行:

3. MySQL安装过程中的报错

解决思路:
遇到这样的报错信息, 我们要学会时时去关注错误日志 error log 里面的内容。看见了关键的报错点Permission denied。证明当前 MySQL 数据库的数据目录没有权限。
解决方法:

如何避免这类问题, 个人建议在安装MySQL初始化的时候, 一定加上–user=mysql, 这样就可以避免权限问题。

4. 数据库密码忘记的问题

解决思路:
目前是进入不了数据库的情况, 所以我们要考虑是不是可以跳过权限。因为在数据库中, mysql数据库中user表记录着我们用户的信息。
解决方法:
启动 MySQL 数据库的过程中, 可以这样执行:

5. truncate 删除数据, 导致自动清空自增ID, 前端返回报错 not found。

这个问题的出现, 就要考虑下truncate 和 delete 的区别了。
看下实验演练:

结果发现truncate把自增初始值重置了, 自增属性从1开始记录了。当前端用主键id进行查询时, 就会报没有这条数据的错误。
个人建议不要使用truncate对表进行删除操作, 虽然可以回收表空间, 但是会涉及自增属性问题。这些坑, 我们不要轻易钻进去。

6. 阿里云 MySQL 的配置文件中, 需要注意一个参数设置就是:

7. 数据库总会出现中文乱码的情况

解决思路:
对于中文乱码的情况, 记住老师告诉你的三个统一就可以。还要知道在目前的mysql数据库中字符集编码都是默认的UTF8. 处理办法:

• 数据终端, 也就是我们连接数据库的工具设置为 utf8
• 操作系统层面; 可以通过 cat /etc/sysconfig/i18n 查看; 也要设置为 utf8
• 数据库层面; 在参数文件中的 mysqld 下, 加入 character-set-server=utf8

Emoji 表情符号录入 mysql 数据库中报错.

解决思路: 针对表情插入的问题, 一定还是字符集的问题。
处理方法: 我们可以直接在参数文件中, 加入

8. 使用 binlog_format=statement 这种格式, 跨库操作, 导致从库丢失数据, 用户访问导致出现错误数据信息。

9. MySQL 数据库连接超时的报错

这个问题是由两个参数影响的, wait_timeout 和 interactive_timeout。数据默认的配置时间是28800(8小时)意味着, 超过这个时间之后, MySQL 数据库为了节省资源, 就会在数据库端断开这个连接, Mysql服务器端将其断开了, 但是我们的程序再次使用这个连接时没有做任何判断, 所以就挂了。
解决思路:
先要了解这两个参数的特性; 这两个参数必须同时设置, 而且必须要保证值一致才可以。
我们可以适当加大这个值, 8小时太长了, 不适用于生产环境。因为一个连接长时间不工作, 还占用我们的连接数, 会消耗我们的系统资源。

解决方法:
可以适当在程序中做判断; 强烈建议在操作结束时更改应用程序逻辑以正确关闭连接; 然后设置一个比较合理的timeout的值(根据业务情况来判断)

10. can’t open file (errno:24)

有的时候, 数据库跑得好好的, 突然报不能打开数据库文件的错误了。
解决思路:
首先我们要先查看数据库的error log。然后判断是表损坏, 还是权限问题。还有可能磁盘空间不足导致的不能正常访问表; 操作系统的限制也要关注下; 用 perror 工具查看具体错误！

perror 24
OSerrorcode24:Toomanyopenfiles

超出最大打开文件数限制！ulimit -n查看系统的最大打开文件数是65535, 不可能超出！那必然是数据库的最大打开文件数超出限制！
在MySQL里查看最大打开文件数限制命令:

show variables like 'open_files_limit';

处理方法: