为何查询经应用服务器执行慢，在MySQL终端执行速度却很快？

• 字符集/排序规则不匹配触发隐式转换，导致索引失效
  这是该类问题最高发的诱因：MySQL/MariaDB终端连接默认使用的字符集、排序规则，大概率和应用侧驱动的连接配置不一致。比如终端默认用utf8mb4_*排序规则，但是NodeJS的MySQL驱动、Spring Boot JDBC连接串中配置的是旧版utf8编码，或是排序规则和表结构定义不匹配，当查询携带字符串类型的查询参数时，数据库会对字段做隐式类型转换，直接导致索引失效触发全表扫描。
  这类问题刚好匹配你描述的「仅特定用户的少量查询异常」特征：你在终端手动执行时，参数和字段字符集匹配，正常走索引耗时极短；应用侧传参触发隐式转换，仅当查询命中数据量较大的特定用户记录时，扫描开销会被放大到几十秒级别。可以直接在应用侧占用一个业务连接执行show variables like 'character_set%';show variables like 'collation%';，和终端执行的结果做对比，配置不一致的概率超过80%。
• 耗时统计口径差异，实际慢在网络传输/驱动缓冲，而非数据库执行
  你在数据库本地终端、副本上测得的<1s耗时，仅统计了数据库层面生成结果集的执行时间，没有覆盖两段开销：
  1. 结果集从数据库服务器传输到应用服务器的网络耗时：尤其是你提到NodeJS负责初始同步拉取，如果特定用户关联的同步数据量极大（单用户几十万到上百万行记录），跨机房、跨VNet的链路限流、Azure层的流量检测、NSG规则拦截都会拉长传输时间，数据库本地回环网卡传输完全感知不到这类开销。
  2. 应用侧驱动的缓冲解析耗时：NodeJS的mysql驱动默认会等整个结果集全部接收、解析完成后才返回给业务逻辑，如果结果集体积大，内存拷贝、字段解析的开销会被全部算成查询耗时；而终端是边接收边打印结果，感知不到全量缓冲的等待时间。
     验证方式很简单：开启MariaDB慢查询日志，核对对应慢查询记录的Query_time字段，如果日志里显示查询执行时间同样<1s，就能100%确认问题不在数据库执行层。
• 预编译语句执行计划缓存偏差
  MariaDB 10.x版本的优化器对预编译语句（Prepared Statement）会缓存首次生成的执行计划，如果第一次预编译时传入的参数是数据分布极集中的值，优化器会选择适合该参数的索引；后续传入数据分布极偏的特定用户参数时，会复用旧的错误执行计划，导致索引选择错误、查询耗时陡增。你在终端手动执行的是即时SQL，每次都会根据当前参数重新生成执行计划，所以不会触发这个问题。可以在慢查询触发时，在应用侧对同参数SQL执行explain，和终端执行同SQL的执行计划做对比，看索引选择是否存在差异。
• 锁等待场景未被手动复现覆盖
  你手动在副本、终端执行查询的时间点，大概率刚好错开了业务高峰期的长事务：如果应用侧查询触发时，刚好有未提交的长事务持有对应行的行锁、或是表元数据锁，查询会一直等待锁释放，等待时间会被全部算成查询耗时；等你手动复现的时候长事务已经提交，自然查询速度极快。下次复现慢查询时可以立刻执行show processlist，查看对应查询的状态是否为锁等待状态。

快速定位步骤 #

1. 先拉取数据库慢查询日志，确认慢查询的实际数据库执行时间，先排除传输、驱动层问题
2. 对比应用业务连接和终端连接的字符集、排序规则、事务隔离级别配置，排查配置差异
3. 对慢查询参数分别在应用侧、终端侧执行explain，核对执行计划、索引选择是否一致
4. 如果以上都无异常，在应用侧抓包核对数据库回包速率，定位网络链路瓶颈

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