大表查询性能问题在 MySQL 中非常常见，尤其是当数据量达到百万甚至千万级以上时，查询响应变慢、锁表、资源消耗高等问题会明显暴露。优化这类查询不能只依赖单一手段，需要从索引设计、SQL 写法、表结构、分区策略和硬件配置等多个方面综合考虑。
合理使用索引提升查询效率
索引是优化大表查询最直接有效的手段，但前提是索引必须被正确使用。
为频繁出现在 WHERE、ORDER BY 和 GROUP BY 条件中的字段建立合适的索引，优先考虑复合索引而非多个单列索引。 避免在索引列上使用函数或表达式，如 WHERE YEAR(create_time) = 2023，会导致索引失效；应改写为范围查询：WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'。 使用覆盖索引（Covering Index），让查询所需字段全部包含在索引中，避免回表操作，大幅减少 I/O 开销。 定期检查并删除冗余或未使用的索引，减少写入开销和维护成本。优化 SQL 查询语句写法
很多性能问题源于不合理的 SQL 写法。
避免 SELECT *，只查需要的字段，减少数据传输量。 分页查询慎用 OFFSET，比如 LIMIT 1000000, 20 会扫描前一百万条记录。可改用基于主键或时间戳的“游标”方式分页：WHERE id > last_id ORDER BY id LIMIT 20。 减少子查询嵌套层级，尽量用 JOIN 替代非相关子查询，并确保关联字段有索引。 避免在 WHERE 中使用 OR 连接多个条件导致索引失效，可用 UNION ALL 拆分查询。表结构设计与分区策略
良好的表结构是高性能的基础。
选择合适的数据类型，比如用 INT 而非 VARCHAR 存储数字，用 DATETIME 而非 TIMESTAMP（除非需要自动时区转换）。 对超大表考虑使用分区（Partitioning），如按时间范围（RANGE 分区）或哈希分区，能显著减少单次查询扫描的数据量。 注意分区键的选择，要与常用查询条件匹配，否则无法发挥分区裁剪（Partition Pruning）优势。 对于历史数据多、更新少的表，可以冷热分离，将旧数据归档到其他表或数据库。利用缓存与读写分离减轻压力
数据库不是唯一解决方案，架构层面也能缓解大表压力。
高频且变化少的查询结果可使用 Redis 或 Memcached 缓存，降低数据库负载。 对读多写少的场景，配置主从复制，将查询请求分流到从库，实现读写分离。 应用层做查询限流和异步处理，避免突发大量复杂查询拖垮数据库。基本上就这些。大表查询优化是个系统工程，关键是理解业务查询模式 + 合理设计索引 + 避免全表扫描。配合执行计划（EXPLAIN）分析每条 SQL 的执行路径，持续迭代调整，才能稳定维持高性能。
