TiDB Binlog解析同个事务的数据顺序问题

🪐 TiDB 技术问题
1 
START TRANSACTION;
update my_pay_table set pay_fee  = 66 where order_id ='100000014157340598267809792';
update my_pay_table set pay_fee  = 989 where order_id ='100000014157340598267809792';
commit;

对于同个事务中两个update，我看binlog中的commitTs值是一样的，那么是不是只能根据mutations的顺序来区分两条记录变更的顺序了？因为发现同个订单的两条数据其update_sys_tm时间可能是一样的，无法区分出更新的先后顺序
binlog内容:

type: DML
commit_ts: 448392993097646086
dml_data {
  tables {
    schema_name: "my_schema_name"
    table_name: "my_pay_table"
    column_info {
      name: "id"
      mysql_type: "bigint"
      is_primary_key: true
    }
    column_info {
      name: "user_id"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "user_type"
      mysql_type: "tinyint"
      is_primary_key: false
    }
    column_info {
      name: "user_contact"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "pay_msg_id"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "pay_order_id"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "biz_order_id"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "model_type_code"
      mysql_type: "tinyint"
      is_primary_key: false
    }
    column_info {
      name: "order_id"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "pay_fee"
      mysql_type: "bigint"
      is_primary_key: false
    }
    column_info {
      name: "real_refund_fee"
      mysql_type: "bigint"
      is_primary_key: false
    }
    column_info {
      name: "pay_status"
      mysql_type: "tinyint"
      is_primary_key: false
    }
    column_info {
      name: "pay_time"
      mysql_type: "datetime"
      is_primary_key: false
    }
    column_info {
      name: "pay_channel"
      mysql_type: "tinyint"
      is_primary_key: false
    }
    column_info {
      name: "pay_way"
      mysql_type: "tinyint"
      is_primary_key: false
    }
    column_info {
      name: "third_reduce_fee"
      mysql_type: "bigint"
      is_primary_key: false
    }
    column_info {
      name: "third_trade_no"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "refund_fee"
      mysql_type: "bigint"
      is_primary_key: false
    }
    column_info {
      name: "callback_topic"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "callback_class"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "remark"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "ext1"
      mysql_type: "varchar"
      is_primary_key: false
    }
    column_info {
      name: "delete_flag"
      mysql_type: "tinyint"
      is_primary_key: false
    }
    column_info {
      name: "create_sys_tm"
      mysql_type: "datetime"
      is_primary_key: false
    }
    column_info {
      name: "update_sys_tm"
      mysql_type: "datetime"
      is_primary_key: false
    }
    column_info {
      name: "visit_source"
      mysql_type: "tinyint"
      is_primary_key: false
    }
    mutations {
      type: Update
      row {
        columns {
          int64_value: 157340602831212544
        }
        columns {
          string_value: "5546"
        }
        columns {
          int64_value: 1
        }
        columns {
          string_value: "110"
        }
        columns {
          string_value: "pay_code160827762502068"
        }
        columns {
          string_value: "100000014157340598267809792"
        }
        columns {
          string_value: "10160827762449146"
        }
        columns {
          int64_value: 14
        }
        columns {
          string_value: "100000014157340598267809792"
        }
        columns {
          uint64_value: 66
        }
        columns {
          uint64_value: 0
        }
        columns {
          int64_value: 2
        }
        columns {
          string_value: "2020-12-18 15:47:05"
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          string_value: "third_trade_no160827762502018"
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          int64_value: 0
        }
        columns {
          string_value: "2020-12-18 15:52:50"
        }
        columns {
          string_value: "2024-03-15 14:18:44"
        }
        columns {
          int64_value: 0
        }
      }
      change_row {
        columns {
          int64_value: 157340602831212544
        }
        columns {
          string_value: "5546"
        }
        columns {
          int64_value: 1
        }
        columns {
          string_value: "110"
        }
        columns {
          string_value: "pay_code160827762502068"
        }
        columns {
          string_value: "100000014157340598267809792"
        }
        columns {
          string_value: "10160827762449146"
        }
        columns {
          int64_value: 14
        }
        columns {
          string_value: "100000014157340598267809792"
        }
        columns {
          uint64_value: 111
        }
        columns {
          uint64_value: 0
        }
        columns {
          int64_value: 2
        }
        columns {
          string_value: "2020-12-18 15:47:05"
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          string_value: "third_trade_no160827762502018"
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          int64_value: 0
        }
        columns {
          string_value: "2020-12-18 15:52:50"
        }
        columns {
          string_value: "2020-12-18 15:52:50"
        }
        columns {
          int64_value: 0
        }
      }
    }
    mutations {
      type: Update
      row {
        columns {
          int64_value: 157340602831212544
        }
        columns {
          string_value: "5546"
        }
        columns {
          int64_value: 1
        }
        columns {
          string_value: "110"
        }
        columns {
          string_value: "pay_code160827762502068"
        }
        columns {
          string_value: "100000014157340598267809792"
        }
        columns {
          string_value: "10160827762449146"
        }
        columns {
          int64_value: 14
        }
        columns {
          string_value: "100000014157340598267809792"
        }
        columns {
          uint64_value: 989
        }
        columns {
          uint64_value: 0
        }
        columns {
          int64_value: 2
        }
        columns {
          string_value: "2020-12-18 15:47:05"
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          string_value: "third_trade_no160827762502018"
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          int64_value: 0
        }
        columns {
          string_value: "2020-12-18 15:52:50"
        }
        columns {
          string_value: "2024-03-15 14:18:44"
        }
        columns {
          int64_value: 0
        }
      }
      change_row {
        columns {
          int64_value: 157340602831212544
        }
        columns {
          string_value: "5546"
        }
        columns {
          int64_value: 1
        }
        columns {
          string_value: "110"
        }
        columns {
          string_value: "pay_code160827762502068"
        }
        columns {
          string_value: "100000014157340598267809792"
        }
        columns {
          string_value: "10160827762449146"
        }
        columns {
          int64_value: 14
        }
        columns {
          string_value: "100000014157340598267809792"
        }
        columns {
          uint64_value: 66
        }
        columns {
          uint64_value: 0
        }
        columns {
          int64_value: 2
        }
        columns {
          string_value: "2020-12-18 15:47:05"
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          string_value: "third_trade_no160827762502018"
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          is_null: true
        }
        columns {
          int64_value: 0
        }
        columns {
          string_value: "2020-12-18 15:52:50"
        }
        columns {
          string_value: "2024-03-15 14:18:44"
        }
        columns {
          int64_value: 0
        }
      }
    }
    5: {
      1: "PRIMARY"
      2: "id"
    }
  }
}
2

两个update语句在同一个事务里面，如果事务正常结束了，最终结果肯定就是最后边那条 989的

1 个赞
3

因为你显示把他们包在同一个事务里面了。committs就会是一样的。
去掉

START TRANSACTION;

试试看。

4

事务之间按提交时间戳排序，同个事务内部只有一个提交时间的，应该再按记录的文本顺序吧

5

你什么版本，还在用binlog，改成cdc吧

6

这是事务的基本机制啊，必须保证事务内的操作，要么全执行成功，要么全失败…

你要的先后顺序，是要到串行化级别么？tidb 事务机制好像没到这么高…

image
image1066×689 45.4 KB

还是说，你要参考这个：
https://docs.pingcap.com/zh/tidb/stable/ticdc-canal-json#tidb-扩展字段

7

可以在列中default current_timestamp on update current_timestamp，即使事务提交时间一样，但事务中语句执行时刻仍然会有区别

9

问题解决了吗

10

问题解决了吗

11

打个卡

12

觉得事务提交时间一样，但事务中语句执行时刻应该会有区别吧

13

最终结果肯定是989，但是当同步binlog到数仓时，66和989的操作记录就分不清哪个先哪个后了，因为update_sys_tm的字段都是一样的，然后看binlog内容commitTs值也是一样的

14

我理解也是的

15

tidb侧是没问题，只是说我在同步binlon操作日志，不太好区分这两条update操作的先后顺序

16

@小于同学 @chris-zhang 目前是从mutations的顺序来区分两条update操作语句的先后顺序，目前没发现有什么问题，不知道其他人有没有更好的方案

17

既然最终结果是989，证明答案已经有了，989的肯定是后面执行的

18

不是质疑执行结果的问题， 是在binlog中两条update的commitTs是一样的，是不是就只能通过mutations的顺序来区分两条update语句的先后顺序

19

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。