mysqlslap：你真的测准了数据库的连接性能吗？
开门见山，很多朋友在用 mysqlslap 做基准测试时，可能都忽略了一个关键点：它默认测的是查询性能，而非连接性能。直接跑一个默认命令，结果往往风平浪静，但真到了高并发场景，连接池瞬间被打满，问题才暴露出来。今天，我们就来聊聊如何用 mysqlslap 精准地“拷打”数据库的连接层。
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
mysqlslap测连接性能需用--concurrency控制并发建连、--iterations=1避免复用、--query="SELECT 1"禁用复杂SQL；其耗时含TCP握手、认证、查询三阶段，processlist快照与统计不一致因连接动态生命周期及系统级限制（如ulimit）。
为什么 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这些参数是否设置得太短，导致连接还没来得及执行操作，就被服务端主动断开了。 - 系统级限制先于MySQL生效：错误提示
Too many connections，但查SHOW VARIABLES LIKE 'max_connections'发现值还很大。别急，问题可能出在操作系统层面。Linux 的用户级资源限制（通过ulimit -n查看）可能率先耗尽，导致 socket 文件描述符不够用，连接在系统层面就被拒绝了。
mysqlslap 测出来的时间包含哪些开销
mysqlslap 最终输出的那个 “A verage number of seconds to run all queries” 平均时间，可不是简单的网络往返延迟。它度量的是一个“总包干”时间：从客户端调用 mysql_real_connect() 函数开始，一直到收到最后一条查询响应并关闭连接为止的全流程耗时。
这个时间里，混杂着至少三个阶段的延迟：
- TCP连接建立：经典的三次握手（SYN, SYN-ACK, ACK）过程。
- MySQL认证流程：包括用户名密码验证，如果启用了SSL（例如使用了
--ssl-mode=REQUIRED参数），那么耗时的SSL握手过程也包含在内。 - 查询执行与返回：即便你只是发一条
SELECT 1，它也需要走完权限检查、SQL解析、优化器选择执行路径等一整套轻量级流程。
所以，如果你发现平均耗时超过了100毫秒，先别急着怪罪网络延迟。更靠谱的做法是：第一，去查看MySQL的错误日志，有没有大量的 Aborted connection 记录；第二，确认是否没有配置 skip-name-resolve 参数。如果没配置，每个新连接都可能触发一次耗时的DNS反向解析，那速度慢下来可就一点都不奇怪了。
替代方案：比 mysqlslap 更准的连接层测试方式
坦白说，mysqlslap 本质上还是一个SQL基准测试工具，连接建立只是它执行测试的一个附带步骤。如果你想要更纯粹、更精准地测试MySQL的连接建立与承受能力，可以考虑下面这些更专业的工具或方法：
- 使用 sysbench：利用其
oltp_common模式，配合--threads=N --events=1 --time=0参数。这样可以严格地按指定线程数创建连接，并且不发送任何SQL语句，真正做到只压连接。 - 编写定制化脚本：比如用Python写一个循环，反复调用
pymysql.connect()并精确计时。加上timeout=3这样的参数可以防止脚本卡死，而且相比Shell脚本，它能更清晰地捕获并区分不同类型的连接异常（例如OperationalError(1040, 'Too many connections')）。 - 避开不合适的工具：像
ab(Apache Bench) 或wrk这类HTTP压测工具，它们根本不理解MySQL协议，无法用于数据库连接层测试。
最后，还有一个至关重要的点：MySQL的实际连接接受能力，不仅仅由 max_connections 这个众所周知的参数决定。它还受到 table_open_cache、thread_cache_size 等内部缓存大小，甚至操作系统 epoll 就绪队列长度的影响。当你把连接压到瓶颈时，不妨先看看 SHOW STATUS LIKE 'Threads_created' 这个状态值是否在飙升。如果是的，那说明线程缓存（thread cache）没起作用，导致连接线程在不断创建和销毁，这通常才是需要优先优化的性能瓶颈所在。
