事务模型

TiDB 使用乐观事务模型,在执行 UPDATEINSERTDELETE 等语句时,只有在提交过程中,执行 UPDATEINSERTDELETE 等语句时才会检查写写冲突,而不是像 MySQL 一样使用行锁来避免写写冲突。类似的,诸如 GET_LOCK()RELEASE_LOCK() 等函数以及 SELECT .. FOR UPDATE 之类的语句在 TiDB 和 MySQL 中的执行方式并不相同。所以业务端在执行 SQL 语句后,需要注意检查 COMMIT 的返回值,即使执行时没有出错,COMMIT 的时候也可能会出错。

与 MySQL 行为及性能对比

事务重试

执行失败的事务默认自动重试,需注意这可能会导致更新丢失。可通过配置 tidb_disable_txn_auto_retry = on 关闭自动重试。

大事务

由于 TiDB 分布式两阶段提交的要求,修改数据的大事务可能会出现一些问题。因此,TiDB 特意对事务大小设置了一些限制以减少这种影响:

  • 单个事务包含的 SQL 语句不超过 5000 条(默认)
  • 每个键值对不超过 6MB
  • 键值对的总数不超过 300,000
  • 键值对的总大小不超过 100MB

小事务

由于 TiDB 中的每个事务都需要跟 PD leader 进行两次 round trip,TiDB 中的小事务相比于 MySQL 中的小事务延迟更高。以如下的 query 为例,用显式事务代替 auto_commit,可优化该 query 的性能。

  1. # 使用 auto_commit 的原始版本
  2. UPDATE my_table SET a='new_value' WHERE id = 1;
  3. UPDATE my_table SET a='newer_value' WHERE id = 2;
  4. UPDATE my_table SET a='newest_value' WHERE id = 3;
  5. # 优化后的版本
  6. START TRANSACTION;
  7. UPDATE my_table SET a='new_value' WHERE id = 1;
  8. UPDATE my_table SET a='newer_value' WHERE id = 2;
  9. UPDATE my_table SET a='newest_value' WHERE id = 3;
  10. COMMIT;

单线程或时延敏感型 workload

由于 TiDB 中的 workload 是分布式的,TiDB 中单线程或时延敏感型 workload 的性能相比于单实例部署的 MySQL 较低。这与 TiDB 中的小事务延迟较高的情況类似。

Load data

  • 语法:

    1. LOAD DATA LOCAL INFILE 'file_name' INTO TABLE table_name
    2. {FIELDS | COLUMNS} TERMINATED BY 'string' ENCLOSED BY 'char' ESCAPED BY 'char'
    3. LINES STARTING BY 'string' TERMINATED BY 'string'
    4. IGNORE n LINES
    5. (col_name ...);

    其中 ESCAPED BY 目前只支持 ‘/\/\’。

  • 事务的处理:

    TiDB 在执行 LOAD DATA 操作时,默认将每 2 万行记录作为一个事务进行持久化存储。如果一次 LOAD DATA 操作插入的数据超过 2 万行,那么会分为多个事务进行提交。如果某个事务出错,这个事务会提交失败,但它前面的事务仍然会提交成功,在这种情况下,一次 LOAD DATA 操作会有部分数据插入成功,部分数据插入失败。而 MySQL 中会将一次 LOAD DATA 操作视为一个事务,如果其中发生失败情况,将会导致整个 LOAD DATA 操作失败。

    注意:

    LOAD DATA 在 TiDB 中没有事务原子性的保证,可以在数据初次导入时使用,不建议在生产环境中使用。