mysql流式查詢如何傳輸數(shù)據(jù)

客戶端向MySQL服務器發(fā)起連接請求，MySQL服務器根據(jù)連接參數(shù)建立連接，并返回連接成功的消息?？蛻舳讼騇ySQL服務器發(fā)起流式查詢請求，并告知查詢條件和列信息。MySQL服務器收到流式查詢請求后，開始查詢，并將結果返回給客戶端?？蛻舳耸盏讲樵兘Y果后，按照預定的格式進行解析和處理即可。

使用mysqldump命令導出數(shù)據(jù) mysqldump命令可用于導出整個MySQL數(shù)據(jù)庫或特定表的數(shù)據(jù)?？梢詫С龅臄?shù)據(jù)作為SQL腳本，然后在目標MySQL數(shù)據(jù)庫中該SQL腳本文件?？梢栽趶姆掌魃蠈氩僮?，并從主服務器上導出數(shù)據(jù)。

首先，需要在`Mapper.xml`配置文件中對`lect`語句進行優(yōu)化，添加`fetchSize`屬性。此屬性底層調用JDBC的`tFetchSize`方法，每次從結果集中取設定數(shù)量的行，然后循環(huán)取，直至取完所有數(shù)據(jù)。默認情況下，`fetchSize`為0，意味著會一次性將所有數(shù)據(jù)集取出，當數(shù)據(jù)量過大時，很容易導致內存溢出。

**普通查詢**：將所有數(shù)據(jù)一次性加載到JVM內存中，對大查詢量不友好，易導致內存溢出。 **流式查詢**：服務端以包為返回數(shù)據(jù)，通過TCP鏈路傳輸給客戶端，客戶端以流的方式逐個讀取，避免了內存一次性加載過大數(shù)據(jù)。

首先，理解流式查詢，它通過提供數(shù)據(jù)獲取管道，客戶端按需從管道讀取，保持連接，避免一次性加載大量數(shù)據(jù)到內存。流式查詢有基于注解和xml兩種方式，選擇ResultSetType為` Scrollable`以減少內存占用。

Spark跟Flink的JDBC,都不靠譜

1、Spark：雖然Spark聲稱支持多種數(shù)據(jù)源，但在Spark Structured Streaming中，并不支持通過JDBC讀取特定數(shù)據(jù)庫的數(shù)據(jù)流。盡管有開源項目嘗試改造Spark JDBC以支持流式讀取，但并未提供直接支持。Flink：Flink的JDBC連接器也存在類似問題。

2、Spark 和 Flink 支持流式計算，但實際應用中需數(shù)據(jù)源端及其對接方式配合，才能實現(xiàn)流式讀取。文檔和實踐表明，Spark 和 Flink 通過 JDBC 方式直接實現(xiàn)流式讀取存在局限性。在 Spark 中，雖然聲稱支持多種數(shù)據(jù)源，但 Spark Structured Streaming 不支持通過 JDBC 讀取特定數(shù)據(jù)庫（如 MySQL）的數(shù)據(jù)流。

3、SQL方言差異：Flink和Spark SQL在字段別名處理上存在不同。Flink不能準確識別別名，而Spark雖然可以識別別名，但要求別名命名需與原字段名有所區(qū)別。字段處理差異：這種SQL方言中的字段處理差異，導致了聚合結果的準確性問題。具體表現(xiàn)：Flink的聚合結果存在不一致性，記錄可能被錯誤地分開。

4、Flink 聚合結果存在不一致性，導致記錄被錯誤地分開。代碼調試后，運行結果與標準聚合結果不符，顯示了錯誤的聚合過程。Spark 聚合結果同樣不準確，且與 Flink 的錯誤方式不同。問題根源在于 SQL方言。Flink 和 Spark SQL 對于字段別名在 group by 條件中的識別能力不同。

5、Flink的checkpoint目錄結構與Spark不同，且每10秒更新一次，即使無數(shù)據(jù)情況也如此。向Kafka添加數(shù)據(jù)后，數(shù)據(jù)被Flink寫入，但Flink UI界面顯示的數(shù)據(jù)量與條數(shù)為0。暫停程序后，再次啟動時需使用特殊恢復模式，指定checkpoint目錄，才能消費斷點處的數(shù)據(jù)。若未正確設置，程序可能無法恢復斷點狀態(tài)。