logstash7.0.1将数据从mysql5.7同步至es7.0.1大数据量下同步慢的问题

先说结论

博主不比比，先说结论
首先我们分为两种情况
全量导库：以主键id的方式写sql语句分页导入es
增量倒库：按数据修改时间的时间字段进行到库

按时间字段进行增量导库

原因：如果我们按修改时间的字段来进行全量倒库，那么logstash的sql语句在大数据量的时候会非常慢，因为logstash在我们的sql之外又套了一层
如：logstash里的mysql.conf文件里的sql

SELECT * FROM article_lib WHERE update_time >= '2021-01-01 10:06:00'

但是logstash执行的时候又给我们套了一层。这样的话当数据量大的时候offset偏移量也越来越大，导致sql的查询效率太低，在下亲测在导入到200w条数据的时候查询一次需要30min左右。

SELECT * FROM (SELECT * FROM article_lib WHERE update_time >= '2021-01-01 10:06:00') AS `t1` LIMIT 4000 OFFSET 884000

比如在200w的数据库全量导入到es，此时如果按照时间字段的方式导入，例如在配置文件中初始时间设置为’2000-01-01’那么它将查询大于该时间的所有的数据，然后再自己慢慢分页，于是就查询就特别慢，而且这是一次定时器的执行，也就是说在这次定时器未执行完毕之前，logstash的sql_last_value是不会更新值的。

优点：按时间字段适合增量导库，在全量导库之后再进行增量导库，此时给logstash指定一个上次运行时间，因为进行过增量导库，于是指定最新的时间即可，数据也就不会太多，也就避免了mysqlsql深度分页瓶颈，mysql数据库的表里需要维护一个时间字段，当程序里的数据进行修改的时候，也要修改该时间字段的值。而且优点在于，每当数据库里得数据有修改，在程序中mysql里该条数据得时间字段也得修改，此时logstash就可以将所有修改或者新增得数据同步至es。达到几乎实时同步的效果。
缺点：如果数据量太大，那么logstash自动在我们配置文件的sql语句外再加一个分页，会有mysql的深度分页瓶颈，效率相当之低。博主吐血亲测。。。300w的数据，用了48个小时还多。。。。

按主键id进行全量导库

全量导入按照id来进行导入,mysql.conf里的sql语句
sql语句

SELECT * from article_lib where article_id > 390 limit 10

logstash执行的时候sql

SELECT * FROM (SELECT * from article_lib where article_id > 390 limit 10) AS `t1` LIMIT 2