一、Record 中字段类型
| Record 中的字段名称 | 说明 |
| id | 全局递增 ID。 |
| version | 协议版本，当前版本为1。 |
| messageType | 消息类型，枚举值："INSERT"，"UPDATE"，"DELETE"，"DDL"，"BEGIN"，"COMMIT"，"HEARTBEAT"，"CHECKPOINT"。 |
| fileName | 当前 record 所在的 binlog 文件名。 |
| position | 当前 record 的在 binlog 中结束的偏移量，格式为 End_log_pos@binlog 文件编号。例如，当前 record 位于文件 mysql-bin.000004 中，结束偏移量为2196，则其值为"2196@4"。 |
| safePosition | 当前事务在 binlog 中开始的偏移量，格式同上。 |
| timestamp | 写入 binlog 的时间，unix 时间戳，秒级。binlog 记录的事务中对应 event header 里面的 timestamp，源端长事务操作可能会导致 timestamp 与 readerTimestamp 有时间差，这种属于正常情况。 |
| gtid | 当前的 gtid，如：c7c98333-6006-11ed-bfc9-b8cef6e1a231:9。 |
| transactionId | 事务 ID，只有 commit 事件才会生成事务 ID。 |
| serverId | 源库 serverId，查看源库 server_id 参考 SHOW VARIABLES LIKE 'server_id'。 |
| threadId | 提交当前事务的会话 ID，参考 SHOW processlist;。 |
| sourceType | 源库的数据库类型，当前版本只有 MySQL。 |
| sourceVersion | 源库版本，查看源库版本参考select version();。 |
| schemaName | 库名。 |
| tableName | 表名。 |
| objectName | 格式为：库名.表名。 |
| columns | 表中各列的定义。 |
| oldColumns | DML 执行前该行的数据，如果是 insert 消息，该数组为 null。 |
| newColumns | DML 执行后该行的数据，如果是 delete 消息，该数组为 null。 |
| sql | DDL 的 SQL 语句。 |
| executionTime | DDL 执行时长，单位为秒。 |
| heartbeatTimestamp | 心跳消息的时间戳，秒级。只有 heartbeat 消息才有该字段。 |
| syncedGtid | DTS 已解析 GTID 集合，格式形如：c7c98333-6006-11ed-bfc9-b8cef6e1a231:1-13。 |
| fakeGtid | 是否为构造的假 GTID，如未开启 gtid_mode，则 DTS 会构造一个 GTID。 |
| pkNames | 如果源库的表设有主键，则 DML 消息中会携带该参数，否则不会携带。 |
| readerTimestamp | DTS 处理这条数据的时间，unix 时间戳，单位为毫秒数。 |
| tags | QueryEvent 中的 status_vars，详细参考 QueryEvent。 |
| total | 如果消息分片，记录分片总数。当前版本 (version = 1) 无意义，预留扩展。 |
| index | 如果消息分片，记录当前分片的索引。当前版本 (version = 1) 无意义，预留扩展。 |
二、Record 中 MySQL 列属性
·name：列名。
·dataTypeNumber：是 binlog 中记录的数据类型。取值详见 MySQL。
·isKey：是否主键。
·originalType：DDL 中定义的类型。
三、MySQL 数据类型转换逻辑
在 JSON 协议中，将 MySQL 类型全部转换成了字符串。
1. 对于 varchar 等字符串类型，全部转成了 UTF8 编码。
2. 对于数值类型，全部转成了与值相同的字符串，如 "3.0"。
3. 对于 binary、blob 等二进制类型，输出为与16进制值相同的字符串，如 "0xfff"。
4. 对于时间类型，转换逻辑如下。
·datetime：DTS 对源库全量及增量数据的精度解析，与源库实际的精度保持一致（0~6位精度）。
示例1：源库 INSERT 数据 datetime 值为 2024-10-24 12:34:56.123456，消费到的数据为 2024-10-24 12:34:56.123456。
示例2：源库 INSERT 数据 datetime 值为 2024-10-25 12:34:56，消费到的数据为 2024-10-24 12:34:56。
·time：DTS 解析的精度一定大于等于源端精度，必要时会补0~6位精度。
·timestamp：DTS 对源库全量及增量数据的精度解析为毫秒级，即3位精度，对于 timestamp(4)/timestamp(5)/timestamp(6)，会丢失毫秒之后的精度。
示例：源库 INSERT 数据 timestamp 值为 2024-10-24 12:34:56.123456，消费到的数据为 2024-10-24 12:34:56.123。
注意：说明：
注意：建议用户在消费数据时，不必关注源库的精度，消费程序中对时间类型的字段解析0~6位精度的格式都进行兼容即可。