由于此類問題雖然不常見，但是每次遇到排查都會花費大量的時間，整理整個case，供參考
背景：
客戶報障他們隻要一連接配接到TDSQL抽取資料，差不多10分鐘左右就會出現逾時中斷，反複幾次都不成功。連到MySQL卻沒有任何問題。
排查過程：
一、看到這個問題，确實比較懵，除了能看到客戶用了我們的DCDB産品之外，不清楚發生了什麼事。
首先和客戶确認，他們用的什麼工具做的資料抽取，回報是DataX。先了解一下DataX是什麼東東。
DataX 是一個異構資料源離線同步工具，緻力于實作包括關系型資料庫(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各種異構資料源之間穩定高效的資料同步功能。
為了解決異構資料源同步問題，DataX将複雜的網狀的同步鍊路變成了星型資料鍊路，DataX作為中間傳輸載體負責連接配接各種資料源。當需要接入一個新的資料源的時候，隻需要将此資料源對接到DataX，便能跟已有的資料源做到無縫資料同步。
二、資訊還是比較少，繼續收集資訊
客戶聲音：
“我能夠确定的是，不是架構限定了連接配接時間，因為同樣的代碼，連傳統mysql沒有問題（超過兩個億，半個多小時以上），一連TDSQL抽取10分鐘後就報Timeout。這個問題已經嚴重影響到下遊系統，請協助解決”
客戶所能提供的資訊也比較有限，進一步深入來查。
首先懷疑到了DataX和DCDB的相容性，客戶回報之前有導出成功的案例，故排除。
還是得從DataX工具入手，分析日志發現，DataX的架構裡會自動設定net_write_timeout=600，這個600s和客戶回報的沒到10分
鐘左右就會逾時的報障吻合。
檢視官檔：
netTimeoutForStreamingResultsWhat value should the driver automatically set the server setting 'net_write_timeout' to when the streaming result sets feature is in use? (value has unit of seconds, the value '0' means the driver will not try and adjust this value)Default: 600Since version: 5.1.0
明确這裡是JDBC的屬性，導緻每一個會話都會把參數net_write_timeout set成600s
修改代碼：
jdbcUrl後面加上參數netTimeoutForStreamingResults=28800
再次啟動DataX抽取DCDB中的資料，順利完成！後續也再未出現類似問題。
分析：
客戶在MySQL上跑不會逾時應該是可能因為結果集相對小，jdbc沒啟用streaming result set的特性，是以不需要設定
這個參數netTimeoutForStreamingResults
官方參考文檔：https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-implementation-notes.html
經驗證，sqoop抽取資料時也有同樣的問題。