前言

高并发时报 Too many connections，是当前连接数达到了 max_connections 上限。这个参数控制 MySQL 同时接受的连接数量，临时改和永久改方式不同。本文讲解查看当前值与使用量、临时调大、写入配置永久生效、合理设置的方法。

操作步骤

1. 查看当前最大连接数

SHOW VARIABLES LIKE 'max_connections';

2. 查看当前已用连接和上限

SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';

3. 临时调大（重启失效）

SET GLOBAL max_connections = 1000;

4. 永久写入配置

编辑 my.cnf：

[mysqld]
max_connections = 1000

重启生效：

systemctl restart mysqld

5. 查看连接占用情况

SHOW PROCESSLIST;

6. 合理评估

每连接占用内存，max_connections 不是越大越好，结合内存计算。

常见坑

1. 只 SET GLOBAL 不改 my.cnf，重启后回到默认值。
2. 盲目调大到上万，内存不够导致 OOM。
3. 连接数被占满多是连接泄漏，光调大不解决根因。
4. 应用连接池配置超过数据库上限，反复拒绝连接。
5. 重启 MySQL 中断现有连接，线上低峰操作。
6. max_user_connections 限制单用户连接，别混淆。
7. 监控 Threads_connected 趋势再决定数值。

总结

max_connections 用 SHOW VARIABLES 查看，SET GLOBAL 临时调，my.cnf 永久写。调大前看 Threads_connected 历史和服务器内存，优先排查连接泄漏。应用连接池上限要低于数据库上限，避免频繁被拒。

遇到问题加QQ23979811 协助处理

前言

数据库变慢想分析慢 SQL，却不知道慢查询日志文件存在哪里，也不确定是否开启。MySQL 的慢日志路径由 slow_query_log_file 参数控制，是否记录由 slow_query_log 和 long_query_time 决定。本文讲解查看参数、确认开关、定位日志文件路径、查看日志内容的完整命令，适配 Linux 下 MySQL5.7 与 MySQL8.0。

操作步骤

1. 登录 MySQL

mysql -uroot -p

2. 查看慢日志相关参数

SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';

slow_query_log 为 ON 表示已开启；slow_query_log_file 显示日志文件路径。

3. 临时开启慢查询日志（无需重启）

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;

long_query_time=1 表示超过 1 秒的语句记录，生产可按需要设 0.5。

4. 找到日志文件在系统中的位置

ls -lh /var/lib/mysql/*.log

常见默认路径：/var/lib/mysql/主机名-slow.log，也可直接用参数返回的路径。

5. 实时查看慢日志内容

tail -f /var/lib/mysql/你的主机名-slow.log

6. 永久开启（写入配置）

编辑 my.cnf：

[mysqld]
slow_query_log = ON
slow_query_log_file = /var/lib/mysql/slow.log
long_query_time = 1

重启生效：

systemctl restart mysqld

常见坑

1. slow_query_log 是 OFF，日志文件根本不生成，查路径也没用。
2. long_query_time 默认 10 秒，普通慢语句记录不到，排查期调小。
3. 日志在 datadir 下，不知道 datadir 时用 SHOW VARIABLES LIKE 'datadir'。
4. 只临时开启，重启 MySQL 后失效，长期用要写 my.cnf。
5. 慢日志持续增长占满磁盘，需配合 logrotate 切割。
6. binlog 和 slow log 混淆，binlog 是复制恢复用，不是慢分析日志。
7. 从库默认不记录慢查询，需要单独配置。

总结

定位慢日志三句话：SHOW VARIABLES 看开关和路径，SET GLOBAL 临时开启，my.cnf 永久生效。拿到日志后用 mysqldumpslow 聚合分析高频慢 SQL。排查结束记得把 long_query_time 调回合理值，避免日志过量。

遇到问题加QQ23979811 协助处理