MySQL长查询响应慢及关联查询异常问题咨询

1. 执行长查询时，MySQL是否会出现响应缓慢的情况？ #

当然会！长查询本身会持续占用MySQL的CPU、磁盘IO等核心资源，要是查询逻辑复杂（比如多表嵌套关联、大表无索引排序），或者服务器本身资源吃紧（内存不足导致频繁磁盘交换、CPU被其他进程占满），响应缓慢几乎是必然的结果。

而且长查询还可能引发连锁问题：它会占据数据库连接资源，导致其他正常查询排队等待；如果是带写操作的长查询，还可能持有锁时间过长，阻塞其他读写请求，进一步拖慢整个实例的响应速度。

2. 针对关联查询状态为'Sending data'且Rows_examined达757497478的解决办法 #

先给你拆解下关键信息：Sending data这个状态很容易被误解成在给客户端发数据，但实际上大部分时候是MySQL在后台处理查询结果（比如多表关联匹配、过滤不符合条件的数据、排序或分组计算）；而Rows_examined高达7.5亿，说明你的查询扫描了巨量数据，几乎肯定是没用到合适的索引，或者查询逻辑可以优化。下面是具体的解决步骤：

• 先看执行计划，精准定位瓶颈
  把这条慢查询复制出来，前面加EXPLAIN执行，比如：

  EXPLAIN SELECT ... -- 替换成你的关联查询语句
  

  重点关注这几个核心字段：

  • type：如果显示ALL，说明是全表扫描，这就是性能爆炸的根源；
  • key：看看有没有用到你预期的索引，要是显示NULL，就是完全没用到索引；
  • rows：这个是MySQL预估的扫描行数，和实际的Rows_examined对比，要是差距过大，可能是表的统计信息过时，需要执行ANALYZE TABLE更新统计信息；
  • Extra：如果出现Using filesort或Using temporary，说明查询需要额外排序或创建临时表，也是重要的性能损耗点。

• 优化索引，大幅减少扫描行数
  针对查询里的关联字段（JOIN ON后面的字段）、WHERE子句的过滤字段创建合适的复合索引。比如你是JOIN table_a ON table_a.id = table_b.a_id WHERE table_b.status = 1，那可以给table_b建(status, a_id)的复合索引，既满足过滤条件又能用于关联匹配，直接把扫描行数砍下来。
  注意：不要盲目加索引，索引会增加写操作的开销，只给高频查询的关键字段加。

• 简化查询逻辑，降低处理压力

  • 别用SELECT *，只查询你真正需要的字段，减少数据传输和后台处理的开销；
  • 如果关联的表太多，试试拆分查询：比如先从主表过滤出符合条件的主键集合，再用主键去关联其他表，减少关联时的数据量；
  • 要是查询的数据量特别大，考虑分批处理，比如用LIMIT配合偏移量分页，或者按时间/ID范围拆分查询。

• 检查服务器与MySQL配置，补全资源短板

  • 看看服务器内存够不够：InnoDB的innodb_buffer_pool_size建议设置为服务器内存的50%-70%（如果是专用MySQL服务器），把常用数据缓存到内存里，大幅减少磁盘IO；
  • 调整查询相关的缓冲区：比如join_buffer_size（关联查询缓冲区）、sort_buffer_size（排序缓冲区），但不要调得太大，避免内存耗尽；
  • 检查是否有锁冲突：用SHOW ENGINE INNODB STATUS看看有没有锁等待，比如有没有其他长事务在写你查询的表，导致查询被阻塞。

• 数据归档，缩小业务表体积
  如果你的表是积累了大量历史数据的业务表，把归档数据迁移到单独的历史表，让当前业务表的数据量变小，这样查询时扫描的数据自然就少了。

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