Airflow MySQLToGCS Operator内存溢出 如何低内存导出MySQL表到GCS

以下方案均适配你当前使用的Airflow 2.0.2 + Composer 1.17.0-preview.6环境：

• 自定义分批导出逻辑
  弃用原生全量加载的MySQLToGCSOperator，自行通过MySQLHook和GCSHook实现分片拉取：选择表中带索引的有序字段（如自增主键、时间字段）作为分片键，每次仅拉取固定范围的数据（如单次1万行），写入GCS对应分片文件后再拉取下一批。查询时推荐使用范围条件替代OFFSET：SELECT * FROM 表名 WHERE 分片键 > 上一批最大值 LIMIT 10000，全程内存仅保留当前批次的数据，内存占用可稳定控制在百MB以内。

• 基于mysqldump流式导出
  直接调用MySQL原生导出工具实现流式处理，全程不会将全量数据加载到内存或本地磁盘。使用BashOperator执行如下命令即可：

  mysqldump -h ${MYSQL_HOST} -u ${MYSQL_USER} -p${MYSQL_PWD} 数据库名 表名 \
  --quick --single-transaction --default-character-set=utf8mb4 \
  | gzip | gsutil cp - gs://存储桶路径/导出文件.sql.gz
  

  其中--quick参数强制mysqldump逐行读取表数据而非加载全表，--single-transaction参数可避免InnoDB引擎表导出时锁表，管道直接将输出流转给压缩、上传步骤，内存占用仅几十MB。敏感认证信息可通过Airflow变量或Secret Manager传入，不要硬编码在DAG代码中。

• 升级MySQL Provider包启用流式查询
  你当前环境使用的mysql provider包版本较低，旧版MySQLToGCSOperator默认全量加载数据到内存。可在Composer的PyPI依赖配置中升级apache-airflow-providers-mysql到2.1.0及以上版本，新版operator新增stream_results参数，开启后会自动分批流式拉取数据，配合approx_max_file_size_bytes参数即可控制分片大小，无需修改核心逻辑即可解决内存溢出问题。

• 托管Dataflow任务中转导出
  对于100GB以上的超大表，可直接调用Google Cloud官方的「JDBC to GCS」Dataflow模板，Airflow侧仅需要通过DataflowCreateJavaJobOperator触发任务即可，全量数据拉取、分片、写入GCS的逻辑全部由Dataflow分布式节点处理，完全不占用Composer Worker的内存资源，还可根据表大小自动扩容资源。

注意事项：如果选择分片查询方案，需确保分片键有覆盖索引，避免大批量扫表拖慢MySQL性能；如果是MyISAM引擎表，使用mysqldump时需提前评估锁表影响，选择业务低峰期执行。

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