前言
与DataStream同样，官方在Flink SQL上也提供了很多连接器，今天来学习总结一下JDBC连接器
环境准备
如果使用编码，需要引入两个依赖包，Flink提供的jdbc连接器依赖和和对应的mysql驱动包，
以下为1.12.0 提供的jdbc连接器依赖
org.apache.flink
flink-connector-jdbc_2.11
1.12.0
mysql依赖下载地址
使用学习
The JDBC sink operate in upsert mode for exchange UPDATE/DELETE messages with the external system if a primary key is defined on the DDL, otherwise, it operates in append mode and doesn’t support to consume UPDATE/DELETE messages.
来自官网的一段介绍，简单翻译一下就是说，如果DDL上定义了主键，则JDBC接收器以upsert模式操作与外部系统交互，否则以append模型来进行交互。
本人测试了一下，详细步骤就不写了，和官网差不多，测试主要步骤如下：
外部数据库DDL设置主键，Flink SQL DDL设置主键
外部数据库DDL不设置主键，Flink SQL DDL设置主键
外部数据库DDL设置主键，Flink SQL DDL不设置主键
外部数据库DDL不设置主键，Flink SQL DDL不设置主键
结果如下：
| 外部系统DDL有主键 | 外部系统DDL无主键 | |
|---|---|---|
| Flink SQL DDL 有主键 | upsert | append |
| Flink SQL DDL 无主键 | upsert | append |
总结：JDBC sink的操作时，如果外部系统定义的DDL存在主键，则JDBC连接器将使用upsert语义而不是简单的insert，在Flink任务执行中如果出现了故障，Flink作业将会从上一个成功的检查点恢复并重新处理，这可能导致在恢复期间重新处理消息。
强烈建议使用upsert模式，因为使用append模式需要重新处理记录，下游可能会出现重复数据。
重要特性
Partitioned Scan
为了加速并行Source任务实例中的数据读取，Flink 在JDBC连接器中提供了scan.partition.column，scan.partition.num，scan.partition.lower-bound，scan.partition.upper-bound 这4个配置属性。其原理简单解释一下：
如果一个线程去读一张很大的表，从头读到尾，肯定很慢，如果想加快速度，自然能想到使用多线程。如何使用呢？
比如假设有id为0到100的数据，id不连续，并且实际上有50条记录，如果我们希望分而治之，那么最好是五个线程，每个线程读取10条数据。但是肯定是做不到这么精确的。最简单的办法是，产生五条如下的SQL：
select * from xxx where id<20;
select * from xxx where id>=20 and id <40;
select * from xxx where id>=40 and id <60;
select * from xxx where id>=60 and id <80;
select * from xxx where id>=80;
因为id中间有空隙，所以每条SQL实际拿到的数据并不一样。但没关系，通过五个线程执行这五条SQL，我们肯定可以通过更少的时间获取到全量数据。
所以在分区扫描中，确定了4个属性规则，用来并行的读这些数据
scan.partition.column： 按照哪个列进行分区
scan.partition.num：分区数量
scan.partition.lower-bound：分区字段的最小值
scan.partition.upper-bound：分区字段的最大值
这个其实和之前博客中写的过优化SQL方法原理是一样的，链接请看：
SQL优化之使用数学的方式动态的确定区间并统计02
简单来说就是，如果这个比如这样（...,20）,[20,40),[40,60),[60,80)....[80,...) 。少还可以，如果面对上百组的情况，后续不容易维护，比如上面的例子，第一组的最小值是20,最后一组的最大值是80,然后总共5组，这样Flink就知道20-80之间还要再分三组。
目前Flink 支持 数字，日期，时间戳等类型的分区扫描配置。
Lookup Cache
JDBC连接器在作为Source维度表使用时，可以开启缓存来提高临时连接JDBC连接器的性能。
默认情况下，不启用查找缓存，因此所有请求都发送到外部数据库。启用查找缓存后，每个进程（即TaskManager）将保存一个缓存。Flink将首先查找缓存，并且仅在缺少缓存时才将请求发送到外部数据库，并使用返回的行更新缓存。当缓存达到最大缓存行数lookup.cache.max-rows或超过最大生存时间时，缓存中最旧的行将过期lookup.cache.ttl。缓存的行可能不是最新的，用户可以调整lookup.cache.ttl为较小的值以获取更好的新鲜数据，但这可能会增加发送到数据库的请求的数量。因此，这是吞吐量和正确性之间的平衡。
lookup.max-retries则配置在查询失败后重试的次数
Buffer-flush
当mysql被使用被Sink时，可以配置
sink.buffer-flush.max-rows ：配置刷新前缓冲记录的最大大小
sink.buffer-flush.interval ：配置刷新间隔，单位为毫秒，在此期间，异步线程将刷新数据。可以设置为'0'来禁用它。注意,”sink.buffer-flush.max-rows'可以设置为'0'，并设置刷新间隔，以允许完成异步处理缓冲的动作。
总结
本文是本文学习和使用Flink SQL JDBC 连接器的学习笔记和总结，如果出现描述问题，欢迎大家留言指出，一起努力。
-- by 两只猴