MySQL查询耗时超51小时需每日Cron执行，求优化建议

Hey, 针对你遇到的这个跑了51小时的MySQL查询难题，结合你提到的无索引、大数据量、每日定时执行以及预期1000万条结果的情况，我整理了几个实用的建议：

1. 先搞定索引——这是慢查询的核心元凶 #

• 既然param1和param2都没建索引，这绝对是查询耗时爆炸的主要原因。大数据量下无索引会触发全表扫描，耗时直接呈指数级增长。
• 先跑EXPLAIN分析你的查询语句，看看执行计划里的扫描类型（比如ALL就代表全表扫描），然后根据查询逻辑给这两个字段建索引：如果查询里同时用它们做过滤条件，建联合索引；如果是单独使用，就建单个字段的索引。
• 别担心建索引的代价：虽然会占用部分磁盘空间，对写入操作有一丢丢影响，但对你这种每日只读的定时任务来说，这个交换完全值得。

2. 必须拆分大查询——1000万条结果绝不能一次性拿 #

• 答案是肯定的，必须拆！一次性取出1000万条数据，不仅会长时间占用数据库连接，还会耗光应用服务器的内存，风险极高。
• 推荐两种靠谱的拆分方式：
  • 按时间范围拆分：如果你的数据有时间字段（比如创建时间），就按天/小时分批查询，比如每日任务分成“查昨天0-6点”“6-12点”等多个小查询，最后按需合并结果。
  • 基于有序字段的范围分页：别用LIMIT offset, size（大偏移量会极慢），改用WHERE id > last_processed_id LIMIT 10000这种方式，利用主键的有序性快速定位，每次只查1万条，循环直到处理完所有数据。
• 拆分后每个小查询的执行时间会短很多，而且就算某个小查询失败，只需要重跑这一段就行，不用从头再来51小时。

3. 其他锦上添花的优化点 #

• 别用SELECT *，只选你需要的字段，减少数据传输量和内存占用。
• 如果涉及多表关联，确认关联字段也有索引，避免关联时的全表扫描。
• 调优MySQL配置：比如增大innodb_buffer_pool_size（让更多数据缓存到内存）、调整sort_buffer_size和join_buffer_size等，根据服务器硬件资源合理设置。
• 用中间表缓存结果：每日任务先把查询结果插入到一个专门的结果表，后续业务直接查这个表，不用重复跑耗时的大查询。
• 把cron任务放到非高峰时段执行，避免影响正常业务。

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