由于此类问题虽然不常见，但是每次遇到排查都会花费大量的时间，整理整个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抽取数据时也有同样的问题。