在服务器运维和数据库优化工作中，直接通过命令行评估MySQL的读处理能力是最基础也最可靠的手段。不同于图形化监控工具，命令行方式不受网络传输额外开销影响，能够更纯粹地反映存储引擎、缓冲池以及索引设计对查询效率的作用。常用的方案包括MySQL自带的mysqlslap压测工具，以及手工编写SQL配合时间戳统计的方式，两者各有适用场景。
使用mysqlslap进行并发读压测
mysqlslap是MySQL发行包中自带的基准测试客户端，它通过模拟多个客户端连接并执行指定的SQL语句，输出平均耗时、每秒查询数等关键指标。在测试读性能时，我们通常让工具自动生成测试表，或者指向已有的业务表，然后以--concurrency参数设定并发线程数，以--iterations设定每轮重复次数，从而获得稳定的统计值。这种方式最大的优势是无需自己写脚本即可完成多并发模拟。
例如，下面的命令会对本地MySQL发起50个并发连接，每个连接执行200次简单的SELECT查询，测试表由工具自动创建并填入数据：
mysqlslap --user=root --password=yourpass --concurrency=50 --iterations=10 --auto-generate-sql --auto-generate-sql-load-type=read --number-of-queries=10000 --engine=innodb
在输出结果中，Average number of seconds to run all queries反映了整体耗时，而Minimum、Maximum和Average值能帮我们判断延迟的波动范围。如果平均耗时随并发数线性上升，往往说明磁盘IO或锁竞争成为瓶颈；若低并发时很快、高并发时骤降，则可能是缓冲池命中率不足。需要注意的是，--auto-generate-sql生成的表结构非常简单，仅适合做粗粒度容量评估，不能完全代替真实业务语句的测试。
为了更贴近实际，我们可以改用--query参数指定自己的SELECT语句，并用--create-schema指向已有库。这样能测出特定索引路径下的读取表现。比如针对用户表按主键查询和按非索引字段查询，对比两者的每秒查询数，就能直观看出缺失索引对读性能的影响程度。
通过SQL语句与计时函数手工统计
当目标环境不允许安装额外工具，或者需要精确测量某一条复杂查询的读取开销时，使用MySQL自带的SQL命令是最直接的方法。借助SHOW PROFILES或SYSTEM_USER级别的计时，我们可以在一次会话内反复执行查询并取平均值。这种方法虽然无法原生支持高并发，但能通过脚本外层循环弥补部分不足。
在MySQL 5.7及之前版本，可先执行SET profiling = 1;，然后运行目标SELECT语句，再通过SHOW PROFILES;查看该语句的耗时明细。以下示例展示了如何测量一次全表扫描读操作的时间：
SET profiling = 1; SELECT * FROM orders WHERE customer_id = 10023; SHOW PROFILES; SET profiling = 0;
从结果中的Duration列能够看到该查询消耗了多少秒。如果这个值在百万行表中高达数秒，而加上索引后降到毫秒级，就证明了读性能问题的根因。对于MySQL 8.0，performance_schema中的events_statements_history表也能提供类似数据，且不需要开启会话级profiling，更适合长期采样。
我们还可以利用BENCHMARK函数对表达式做重复计算来观察CPU层面的读处理极限，但它不反映磁盘IO，仅适合判断函数或简单条件过滤的开销。例如SELECT BENCHMARK(1000000, (SELECT count(*) FROM small_table));可让服务器反复执行计数，从命令行返回时间推断单轮成本。这种手段常作为辅助验证，而不是主要压测方式。
解读指标与常见误区
命令行测试输出的核心指标一般包括QPS（每秒查询数）、平均延迟、连接建立耗时以及错误率。读性能测试中最容易被误读的是QPS绝对值：许多新手直接拿笔记本上的mysqlslap结果去等同生产环境能力，却忽略了本地磁盘、内存和CPU核数与服务器的差距。正确做法是在相同硬件配置或至少同代云主机规格下做横向对比，并且固定缓冲池大小等变量。
另一个常见误区是只测主键点查而忽略范围扫描。真实业务中像SELECT * FROM log WHERE create_time > '2023-01-01'这类范围读，会涉及大量页读取，若innodb_buffer_pool_size设置过小，就会引发频繁换页，命令行测出的延迟会远高于点查。因此测试方案应覆盖点查、范围查、多表关联等典型读路径，才能全面评估。
最后要留意命令行客户端本身的解析开销。当使用mysql命令循环执行上千次远程查询时，网络往返和客户端打印结果也会占用时间，此时可在脚本中将输出重定向到/dev/null，或者改用mysqlslap的批量模式，确保测量结果主要体现服务端读能力而非客户端瓶颈。通过合理设计命令参数与场景，我们便能稳定、可重复地掌握MySQL在真实负载下的读性能表现。