mysqlslap测连接性能需用--concurrency控制并发建连、--iterations=1避免复用、--query="select 1"禁用复杂sql；其耗时含tcp握手、认证、查询三阶段，processlist快照与统计不一致因连接动态生命周期及系统级限制（如ulimit）。
mysqlslap 连接数压测怎么写命令
直接跑默认参数的 mysqlslap 没意义，它默认只建 1 个连接、执行 1 次查询，完全测不出连接层瓶颈。真要测连接性能，核心是控制并发连接建立行为，而不是查数据。
实操建议：
- 用
--concurrency控制并发连接数（不是查询并发），比如--concurrency=100表示同时发起 100 次 TCP 连接 + 认证 - 必须加
--iterations=1，否则默认跑多次会复用连接，测的就不是“建连开销” - 禁用查询执行：用
--query="SELECT 1"最简语句，或更彻底地用--no-defaults --skip-secure-auth避免额外握手开销 - 加上
--auto-generate-sql反而干扰结果——它会建临时表、触发元数据锁，测的是 SQL 引擎启动成本，不是连接本身
典型命令：mysqlslap --host=localhost --user=root --password=xxx --concurrency=200 --iterations=1 --query="SELECT 1" --create-schema=test
为什么 show processlist 看到的连接数和 mysqlslap 报的不一致
因为 mysqlslap 统计的是“成功完成一次完整连接+查询+断开”的次数，而 SHOW PROCESSLIST 是某一毫秒的瞬时快照。压测过程中连接是动态创建又销毁的，尤其高并发下大量连接可能在认证阶段失败或超时，根本进不了 processlist。
常见错误现象：
-
mysqlslap报 “Failed to connect” 但SHOW PROCESSLIST里没看到对应连接——说明连接在 TCP 握手后、MySQL 认证前就被拒绝（如 max_connections 达到、max_connect_errors 触发） - 实际 processlist 连接数远低于
--concurrency设置值——可能是wait_timeout或connect_timeout太短，连接还没执行完就被服务端主动踢掉 - 报错
Too many connections却发现SHOW VARIABLES LIKE 'max_connections'显示值很大——注意：Linux 用户级限制（ulimit -n）可能先于 MySQL 限制生效，socket 文件描述符耗尽会导致连接被系统拒绝
mysqlslap 测出来的时间包含哪些开销
它报告的 “Average number of seconds to run all queries” 不是纯网络 RTT，而是从客户端调用 mysql_real_connect() 开始，到收到最后一条查询响应并关闭连接为止的总耗时。中间混着三类延迟：
- TCP 连接建立（SYN/SYN-ACK/ACK）
- MySQL 认证流程（包括 SSL 握手，如果启用了
--ssl-mode=REQUIRED） - 单次简单查询执行 + 结果返回（哪怕只是
SELECT 1，也要走权限检查、解析、优化器轻量路径）
所以如果你发现平均耗时 >100ms，别急着怀疑网络——先查 MySQL 错误日志有没有 Aborted connection，再确认是否启用了 DNS 反向解析（skip-name-resolve 未配置时，每个新连接都会触发 hostname lookup，慢得离谱）。
替代方案：比 mysqlslap 更准的连接层测试方式
mysqlslap 本质是个 SQL 压测工具，连接只是副产品。真要单独压连接建立性能，用原生工具更干净：
- 用
sysbench的oltp_common模式配合--threads=N --events=1 --time=0，它会严格按线程数起连接且不发 SQL - 写个 Python 脚本循环调用
pymysql.connect()并计时，加timeout=3防卡死，比 shell 脚本更容易捕获异常类型（如OperationalError(1040, 'Too many connections')） - 用
ab或wrk完全不行——它们不理解 MySQL 协议，只能测 HTTP 接口
真正容易被忽略的是：MySQL 的连接接受能力不仅取决于 max_connections，还受 table_open_cache、thread_cache_size 和操作系统 epoll 就绪队列长度影响。压到瓶颈时，先看 SHOW STATUS LIKE 'Threads_created' 是否飙升——如果是，说明线程缓存没起作用，连接反复创建销毁，这才是第一要调的点。
