Rows_sent是否影响Query_time？两次LIKE查询耗时差异原因咨询

问题背景 #

表中包含50000行数据，执行两条带LIKE子句的SQL语句，两者的Rows_examined均为50000，但执行时间差异显著：

# Query_time: 4.575865  Lock_time: 0.000120 Rows_sent: 50000  Rows_examined: 50000
SELECT * FROM `XXXX` WHERE `XXXX` LIKE "%Tom%";


# Query_time: 0.163456  Lock_time: 0.000128 Rows_sent: 0  Rows_examined: 50000
SELECT * FROM `XXXX` WHERE `XXXX` LIKE "%TTTTTTTTOOOOOOOOOOOMMMMMMMMM%";

使用的是Amazon Aurora MySQL3（兼容MySQL 8.0），疑问在于：为何第二条SQL的Query_time远快于第一条？Rows_sent是否会影响Query_time？具体如何影响？

核心原因解析 #

1. Rows_sent是执行时间差异的关键因素 #

当查询返回大量数据时，MySQL需要完成一系列高开销的额外操作：

• 从Aurora共享存储层读取匹配行的所有字段数据（因使用SELECT *）；
• 将行数据序列化，转换成适合网络传输的格式；
• 通过网络把序列化后的数据发送给客户端，且服务器需等待数据发送完成才会终止计时；

而返回0行的查询，仅需完成全表扫描和条件匹配，无需执行上述数据读取、序列化和传输步骤，这是两者耗时差距的核心原因。

2. LIKE匹配的细节优化 #

两条语句都因前置通配符%无法利用索引，必须全表扫描，但第二条的匹配字符串长度更长、特征更特殊：

• MySQL的模式匹配引擎在处理长串匹配时，可能比对前几个字符就快速判定不匹配，提前终止当前行的匹配逻辑，减少单条行的处理耗时，累积后进一步缩短总执行时间。

3. Aurora存储层的特性影响 #

Aurora采用共享分布式存储架构，仅做条件判断时，可能只需要读取用于匹配的单个字段数据，无需加载整行的所有字段；而返回大量数据时，需要从存储层拉取更多数据块，IO开销大幅增加，进一步拉大了耗时差异。

总结 #

两条语句的执行时间差异主要由Rows_sent带来的后续数据处理、传输开销决定，同时LIKE匹配的细节优化和Aurora的存储特性也起到了辅助作用。

内容的提问来源于stack exchange，提问作者tesnirs