“适合高并发”的max_connections无固定值，需结合内存与负载：16核32GB服务器常见设为2000–3000，激进场景可达5000–8000；但须同步调优thread_cache_size、wait_timeout、innodb_buffer_pool_size及应用层连接池，并监控Max_used_connections与Threads_created。
max_connections设多少才算“适合高并发”
没有固定值，得看内存和实际负载。16核32GB服务器上，max_connections设到2000–3000是常见起点；若应用大量短连接或连接池配置激进，可能要提到5000甚至8000。但盲目拉高会吃光内存——每个连接至少占用256KB线程栈+其他开销，8000连接光线程栈就超2GB。
更稳妥的做法是先查当前峰值：SHOW GLOBAL STATUS LIKE 'Max_used_connections';。如果它长期稳定在max_connections的70%以下，说明当前值偏高；如果频繁触顶，再按10%–20%步长往上加，同时监控Threads_created是否飙升（说明线程创建太频繁，该调thread_cache_size了）。
SET GLOBAL max_connections只临时生效，必须改配置文件才持久
SET GLOBAL max_connections = 3000;能立刻提升上限，但MySQL重启后就回退到默认151。生产环境必须写进my.cnf（Linux）或my.ini（Windows）的[mysqld]段里：
[mysqld] max_connections = 3000
改完要重启MySQL服务，不是reload。Windows下注意路径通常是C:\ProgramData\MySQL\MySQL Server 5.7\my.ini，别去Program Files目录下找——那里是安装包，不是运行时配置。
别只调max_connections，配套参数不跟上照样崩
单改max_connections就像给水管换粗管子却不加固水塔承重——容易出事。必须同步检查：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
thread_cache_size：建议设为max_connections的10%–20%，比如3000对应设20–50。查现状用SHOW VARIABLES LIKE 'thread_cache_size'; -
wait_timeout和interactive_timeout：默认28800秒（8小时），空闲连接堆着不放，很快占满配额。建议压到300–600秒，写进配置文件生效 -
innodb_buffer_pool_size：它和连接数抢内存。32GB机器上设10GB是安全线，别超过物理内存的70%
连接池maximumPoolSize必须≤max_connections × 用户配比
很多人调高了max_connections，却忘了应用层连接池还在猛开连接。HikariCP的maximumPoolSize、Druid的maxActive，如果总和超过max_connections，一压测就报ERROR 1040 (HY000): Too many connections。
真实场景中还要考虑多应用共用实例的情况。比如你有App、Admin、Report三个服务，各自连接池都设了100，那max_connections至少得350起步（留50给监控/运维连接）。更精细的做法是配合MAX_USER_CONNECTIONS做用户级隔离——但那是另一层控制，和全局max_connections不互斥，而是叠加生效。
最容易被忽略的是：连接池的minimumIdle或idleTimeout没配好，导致低峰期也维持大量空闲连接，把配额悄悄占满。上线前务必用SELECT COUNT(*) FROM information_schema.processlist;实测连接数分布。
