mysql最大并发查询数由哪些参数控制
MySQL 没有直接叫“最大并发查询数”的配置项，实际起作用的是
max_connections（最大允许连接数）和
max_connect_errors（影响连接建立），而真正限制“同时执行的查询”数量的，还取决于
innodb_thread_concurrency（已弃用）、
innodb_read_io_threads/
innodb_write_io_threads（IO线程数），以及操作系统级资源（如文件描述符、内存、CPU）。用户常误以为调大
max_connections就能撑住更多并发查询，但真实瓶颈往往在锁等待、慢查询或缓冲区不足。
如何安全设置 max_connections
该参数决定 MySQL 允许多少个客户端连接同时存在（包括空闲连接和正在执行查询的连接），不是“并发查询数”的精确等价。设置过大会导致内存耗尽（每个连接至少占用 256KB～1MB 内存），设置过小则出现
Too many connections错误。 查看当前值：
SHOW VARIABLES LIKE 'max_connections';临时修改（重启失效）：
SET GLOBAL max_connections = 500;永久修改：在
my.cnf的
[mysqld]段下添加：
max_connections = 300需同步检查系统限制：
ulimit -n应 ≥
max_connections + 100（预留系统连接） 若使用云数据库（如阿里云 RDS、AWS RDS），
max_connections通常受实例规格硬限制，无法突破，需升级规格而非改配置
真正影响并发查询性能的关键配置
单纯调高
max_connections不解决查询排队、响应变慢的问题。以下参数更直接影响“有多少查询能真正并行跑起来”：
innodb_buffer_pool_size：应设为物理内存的 50%～75%，太小会导致频繁刷盘，查询卡在 IO 上
innodb_log_file_size和
innodb_log_buffer_size：影响写密集型并发事务的吞吐，过小会引发日志等待
table_open_cache和
open_files_limit：高并发下大量表访问时，缓存不足会反复打开/关闭文件，拖慢查询
wait_timeout和
interactive_timeout：及时回收空闲连接，避免连接数被僵尸连接占满 注意：MySQL 8.0+ 已移除
innodb_thread_concurrency，不再推荐设为非 0 值；其并发调度由内部线程池（需企业版）或 OS 调度接管
验证并发能力不能只看配置
配置改完不等于效果落地。必须结合实际负载验证：
用SHOW PROCESSLIST;观察
State列：大量
Sending data、
Locked、
Copying to tmp table表示查询本身有瓶颈，不是连接数问题 监控
Threads_running（当前活跃线程数）：
SHOW STATUS LIKE 'Threads_running';—— 这个值才接近你关心的“正在执行的查询数” 配合
slow_query_log = ON和
long_query_time = 1找出拖慢整体并发的慢查询 压测时用
sysbench或
mysqlslap，但注意模拟真实查询模式（读写比、事务长度），否则结果失真
最常被忽略的一点：应用层连接池（如 HikariCP、Druid）的最大连接数必须 ≤ MySQL 的
max_connections，且最好留出 20% 余量给 DBA 维护连接。两者不匹配时，错误不会立刻暴露，而是表现为随机超时或连接拒绝。
