针对你遇到的220万行MySQL数据通过Logstash导入Elasticsearch速度极慢，还偶发临时空间不足的问题，结合你的环境信息和后续的排查进展，咱们来梳理几个关键优化方向：

1. 紧急解决MySQL内存过载问题 #

从你给出的free -m结果来看，MySQL服务器4G内存已经用了97%，这必然会触发系统磁盘交换（swap）——swap的读写速度比内存慢几个数量级，是拖慢查询的核心原因之一，哪怕负载平均值不高也没用。

• 调整MySQL的innodb_buffer_pool_size：4G内存的机器，建议把这个值设为2G左右（别超过总内存的60%），这是MySQL最核心的内存参数，用来缓存表和索引，合理设置能极大减少磁盘IO。
• 检查并调小其他内存参数：比如sort_buffer_size、join_buffer_size，如果之前设得太大（比如超过128M），并发查询时会瞬间吃掉大量内存。建议把这两个值调到64M以内，按需调整。
• 关闭不必要的MySQL进程或服务：确保只有MySQL核心进程在运行，避免其他程序抢占内存。

2. 优化复杂子查询的临时表开销 #

你已经用EXPLAIN优化了索引，这一步非常关键！在此基础上，咱们再针对临时表问题做优化：

• 调整MySQL临时表参数：tmp_table_size和max_heap_table_size，这两个参数控制内存临时表的最大大小，如果查询生成的临时表超过这个值，就会转到磁盘。可以适当调大（比如设为256M），但别超过系统剩余内存，避免内存溢出。
• 确认临时目录权限：/data/tmp_mysql要确保是mysql用户拥有读写权限，避免因为权限问题导致写临时文件失败。
• 拆分复杂子查询：如果子查询逻辑太复杂，不妨拆成多个简单查询，提前用临时表存储中间结果，减少单次查询生成的临时数据量，降低磁盘IO压力。

3. 调整Logstash的JDBC导入配置 #

你的Logstash已经启用了分页，但可以再优化几个点：

• 调小jdbc_page_size：当前是10000，结合MySQL内存紧张的情况，建议降到5000，减少单次查询对MySQL内存的占用。
• 开启jdbc_fetch_size：这个参数控制JDBC驱动每次从MySQL拉取的数据量，和分页配合使用，能进一步降低两边的内存开销，比如设为1000。
• 优化Logstash的JVM内存：修改logstash/config/jvm.options里的-Xms和-Xmx，比如设为-Xms2g -Xmx2g（服务器总内存4G，留2G给系统和Elasticsearch），避免Logstash因为频繁GC拖慢导入速度。

4. Elasticsearch端的写入优化 #

导入期间给ES做些临时优化，能大幅提升写入速度：

• 临时关闭副本：导入时设置index.number_of_replicas: 0，这样ES不用同步副本数据，节省大量IO和CPU资源，导入完成后再改回原来的副本数（比如1）。
• 延长刷新间隔：把index.refresh_interval改成30s甚至1m，默认1s刷新一次会频繁触发索引合并，严重影响写入性能，导入完成后再改回默认。
• 确保索引缓冲区足够：ES的indices.memory.index_buffer_size默认是堆内存的10%，如果ES堆内存是2G的话，这个值足够，不用调整；如果堆内存更大，可以适当调增。

从你后续的进展来看，重新创建索引+优化索引后，导入时间降到了55小时，这说明索引和ES状态的优化已经起了作用。再结合上面的MySQL内存调整和参数优化，应该能进一步缩短导入时间，同时解决临时空间不足的问题。

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