mysql流式读取弊端？数据完整性堪忧

mysql流式查询如何传输数据

客户端向MySQL服务器发起连接请求，MySQL服务器根据连接参数建立连接，并返回连接成功的消息。客户端向MySQL服务器发起流式查询请求，并告知查询条件和列信息。MySQL服务器收到流式查询请求后，开始查询，并将结果返回给客户端。客户端收到查询结果后，按照预定的格式进行解析和处理即可。

使用mysqldump命令导出数据 mysqldump命令可用于导出整个MySQL数据库或特定表的数据。可以将导出的数据作为SQL脚本，然后在目标MySQL数据库中该SQL脚本文件。可以在从服务器上导入操作，并从主服务器上导出数据。

首先，需要在`Mapper.xml`配置文件中对`lect`语句进行优化，添加`fetchSize`属性。此属性底层调用JDBC的`tFetchSize`方法，每次从结果集中取设定数量的行，然后循环取，直至取完所有数据。默认情况下，`fetchSize`为0，意味着会一次性将所有数据集取出，当数据量过大时，很容易导致内存溢出。

**普通查询**：将所有数据一次性加载到JVM内存中，对大查询量不友好，易导致内存溢出。 **流式查询**：服务端以包为返回数据，通过TCP链路传输给客户端，客户端以流的方式逐个读取，避免了内存一次性加载过大数据。

首先，理解流式查询，它通过提供数据获取管道，客户端按需从管道读取，保持连接，避免一次性加载大量数据到内存。流式查询有基于注解和xml两种方式，选择ResultSetType为` Scrollable`以减少内存占用。

Spark跟Flink的JDBC,都不靠谱

1、Spark：虽然Spark声称支持多种数据源，但在Spark Structured Streaming中，并不支持通过JDBC读取特定数据库的数据流。尽管有开源项目尝试改造Spark JDBC以支持流式读取，但并未提供直接支持。Flink：Flink的JDBC连接器也存在类似问题。

2、Spark 和 Flink 支持流式计算，但实际应用中需数据源端及其对接方式配合，才能实现流式读取。文档和实践表明，Spark 和 Flink 通过 JDBC 方式直接实现流式读取存在局限性。在 Spark 中，虽然声称支持多种数据源，但 Spark Structured Streaming 不支持通过 JDBC 读取特定数据库（如 MySQL）的数据流。

3、SQL方言差异：Flink和Spark SQL在字段别名处理上存在不同。Flink不能准确识别别名，而Spark虽然可以识别别名，但要求别名命名需与原字段名有所区别。字段处理差异：这种SQL方言中的字段处理差异，导致了聚合结果的准确性问题。具体表现：Flink的聚合结果存在不一致性，记录可能被错误地分开。

4、Flink 聚合结果存在不一致性，导致记录被错误地分开。代码调试后，运行结果与标准聚合结果不符，显示了错误的聚合过程。Spark 聚合结果同样不准确，且与 Flink 的错误方式不同。问题根源在于 SQL方言。Flink 和 Spark SQL 对于字段别名在 group by 条件中的识别能力不同。

5、Flink的checkpoint目录结构与Spark不同，且每10秒更新一次，即使无数据情况也如此。向Kafka添加数据后，数据被Flink写入，但Flink UI界面显示的数据量与条数为0。暂停程序后，再次启动时需使用特殊恢复模式，指定checkpoint目录，才能消费断点处的数据。若未正确设置，程序可能无法恢复断点状态。