MySQL多表关联查询优化咨询：大表范围查询性能问题

先拆解下你的问题核心：两张数据量悬殊的表做关联，随着过滤的CSD_ID范围扩大，查询耗时急剧上升，尤其是数据获取阶段耗时很长。下面给你几个针对性的优化方向，比创建普通视图有用得多：

1. 修正JOIN类型，避免语义浪费 #

你的SQL用了LEFT JOIN，但WHERE子句里加了dri.DRI_SYM_SYMBOL = 1——这会把左连接自动转换成内连接（因为左连接后过滤右表非空字段，相当于只保留两张表匹配的行）。直接改成INNER JOIN能让数据库优化器更准确地选择执行计划，没必要保留左连接的冗余语义：

SELECT csd.CSD_ID, csd.CSD_ID_DRI, csd.CSD_PARTY_ID, csd.CSD_AMOUNT, dri.DRI_DATE, dri.DRI_SYM_TICKER 
FROM TWD_CSD_NEWS_DETAIL csd 
INNER JOIN TWD_DRI_NEWS_RESULT_HEADER dri ON dri.DRI_ID = csd.CSD_ID_DRI 
WHERE csd_id BETWEEN 1 AND 200000000 
  AND dri.DRI_SYM_SYMBOL = 1

2. 简化CSD_ID的过滤条件 #

你原来的WHERE里写了一堆(csd_id between ...) || (csd_id between ...)，如果这些区间是连续的（比如1-426029、426030-851977...最后到2亿），直接合并成一个BETWEEN 1 AND 200000000就行。多个OR的区间会让优化器难以判断索引的有效性，增加执行计划的计算开销，合并后更简洁高效。

3. 创建覆盖索引，彻底避免回表 #

这是提升大表查询性能最关键的一步：

• 对于TWD_CSD_NEWS_DETAIL（2亿行）：创建联合覆盖索引，包含过滤字段、关联字段和查询返回的所有字段：

  CREATE INDEX idx_csd_id_dri ON TWD_CSD_NEWS_DETAIL (CSD_ID, CSD_ID_DRI, CSD_PARTY_ID, CSD_AMOUNT);
  

  这个索引能让数据库直接从索引里拿到所有需要的数据，不用再去扫描主表（回表操作是大表性能的头号杀手）。

• 对于TWD_DRI_NEWS_RESULT_HEADER（100万行）：同样创建覆盖索引，包含关联字段、过滤字段和返回字段：

  CREATE INDEX idx_dri_id_symbol ON TWD_DRI_NEWS_RESULT_HEADER (DRI_ID, DRI_SYM_SYMBOL, DRI_DATE, DRI_SYM_TICKER);
  

  小表的索引开销很低，但能极大加速关联匹配的过程。

4. 关于视图的选择：普通视图没用，物化视图表需权衡 #

• 普通视图只是存储了你的查询语句，每次调用视图时还是会执行原查询，不会提升性能，反而多了一层解析，没必要用。
• 如果你的业务允许数据有一定延迟（比如不需要实时最新数据），可以考虑物化视图（不同数据库叫法不同，比如Oracle的Materialized View、PostgreSQL的Materialized View）。物化视图会把查询结果实际存储成一张表，查询时直接读这张表，速度会快很多，但需要维护数据同步（比如定时刷新），如果数据更新频繁，维护成本会很高。

5. 优化数据获取的方式 #

你提到“获取数据时长为26秒”，这部分是数据从数据库传输到客户端的时间。如果不需要一次性拿到所有2亿行数据，建议分批次查询（比如按CSD_ID分块，每次查100万行），减少单次传输的数据量，避免客户端内存溢出或等待太久。

另外，如果数据库支持分区表，把TWD_CSD_NEWS_DETAIL按CSD_ID做范围分区，查询特定区间时只会扫描对应分区，能进一步减少IO开销。

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