MySQL迁移后max_connections没生效，先查配置加载顺序：执行mysqld --help --verbose | grep "Default options"确认实际读取路径，检查所有配置文件中[mysqld]段的max_connections是否唯一、未被覆盖或写错段落，并同步验证wait_timeout、系统ulimit及连接池参数匹配性。
MySQL迁移后max_connections没生效，先查配置加载顺序
迁移后SHOW VARIABLES LIKE 'max_connections'还是显示151，不是配置没改，而是MySQL根本没读到你写的值。它按固定顺序加载多个配置文件，后读的会覆盖前读的——迁移常导致路径变化或引入新默认片段（比如Ubuntu 22.04+把配置拆进/etc/mysql/conf.d/），你改的my.cnf可能被后面某个mysqld.cnf里的同名设置覆盖了。
立刻执行：mysqld --help --verbose | grep "Default options"，看实际加载了哪些路径；再逐个检查这些文件里[mysqld]段落，确认max_connections只在一处定义，且没被注释或拼错。
常见坑：
- 写到了
[client]或[mysql]段下——完全不生效 - 用了
sudo vim /etc/my.cnf改，但MySQL实际加载的是/etc/mysql/mysql.conf.d/mysqld.cnf - 云数据库（如阿里云RDS）根本不允许改配置文件，只能通过控制台或API调参
迁移后连接数暴增，重点查wait_timeout是否被重置
迁移常导致wait_timeout和interactive_timeout回退到默认8小时（28800秒）。旧环境可能已调低到300秒，应用靠连接池复用，迁移后空闲连接长期挂起，SHOW PROCESSLIST里一堆Sleep状态、Time值超万秒的连接，很快就把max_connections占满。
执行：SHOW VARIABLES LIKE 'wait_timeout';，如果返回28800，立刻补救：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 临时生效：
SET GLOBAL wait_timeout = 300;（需SUPER权限） - 永久生效：在
[mysqld]段加wait_timeout = 300，重启服务 - 注意：PHP等短连接场景下，
wait_timeout设太短会导致连接池取到已断开的连接，报Lost connection to MySQL server
系统级限制在迁移后暴露，别只盯MySQL配置
迁移后换了服务器或容器环境，ulimit -n或systemd的LimitNOFILE可能比MySQL的max_connections还小。MySQL启动时发现文件描述符不够，会静默截断连接数——你设了2000，实际生效可能只有1024，cat /proc/$(pidof mysqld)/limits | grep "Max open files"能直接看到上限。
必须同步检查：
- OS层：
ulimit -n（当前shell限制），cat /etc/security/limits.conf（用户级限制） - systemd服务：检查
/usr/lib/systemd/system/mysqld.service里是否有LimitNOFILE=65536，且该值 ≥max_connections + 100 - 容器环境：Docker要加
--ulimit nofile=65536:65536，K8s需在securityContext里配ulimits
连接池参数在迁移后失配，应用层比数据库更关键
迁移后应用没重配连接池，比如Java用HikariCP，maximumPoolSize仍设为100，但MySQL的max_connections只设了200——看起来够用，可监控发现Threads_connected稳定在195以上。问题出在：HikariCP默认connection-timeout是30秒，而MySQL的wait_timeout是28800秒，连接池以为连接还活着，MySQL却早把它标记为可回收，结果大量连接卡在“半死”状态。
必须核对三组参数是否匹配：
- HikariCP：
maximumPoolSize≤ MySQLmax_connections− 系统保留连接（复制线程、监控工具等） - DBUtils.PooledDB（Python）：
mincached和maxcached不能远超MySQL上限 - 所有池子都要设
maxLifetime（建议≤wait_timeout * 0.75）和idleTimeout（建议≤wait_timeout − 60）
最易忽略的一点：迁移后应用日志里Connection reset by peer或Communications link failure变多，大概率是连接池复用的连接已被MySQL主动断开，但池子没及时检测并剔除——这时光调max_connections毫无意义。
