tidb 中DML语句是怎么个执行流程啊，与mysql 有多大的不同啊
DML 语句在 TiDB 中的典型执行流程：
- 客户端请求
SQL 解析：客户端发送的 SQL 语句首先由 TiDB Server 接收。TiDB Server 作为前端处理节点，负责解析 SQL 语句，检查语法正确性，并生成逻辑执行计划。
权限验证：TiDB Server 会根据用户的权限设置，验证用户是否有权执行该 DML 操作。如果权限不足，操作将被拒绝。 - 执行计划生成
优化器：TiDB 使用 Cost-Based Optimizer (CBO) 来选择最优的执行计划。优化器会分析表结构、索引、统计信息等，以确定最有效的查询路径。对于 DML 语句，优化器还会考虑事务的隔离级别和并发控制策略。
物理计划生成：优化后的逻辑执行计划会被转换为物理执行计划，这包括决定如何访问数据（例如通过索引扫描或全表扫描）、如何分配任务给不同的 TiKV 节点等。 - 分布式执行
Region 分片：TiDB 将数据划分为多个 Region，每个 Region 由一组连续的键值对组成。DML 语句的操作会被分解为对这些 Region 的具体操作。TiDB Server 会根据 Region 的分布情况，将操作分发到相应的 TiKV 节点。
Raft 协议：每个 Region 在 TiKV 中都有多个副本，这些副本通过 Raft 共识算法保持一致。当接收到 DML 操作时，TiKV 会使用 Raft 协议确保所有副本都达成一致。只有当大多数副本确认后，操作才会被认为是成功的。
MVCC 和锁机制：TiDB 实现了多版本并发控制（MVCC），允许不同事务同时读取和写入数据，而不会相互阻塞。对于写操作，TiKV 会为受影响的行加锁，以防止其他事务对其进行修改。锁的类型取决于事务的隔离级别（如快照隔离或可重复读）。 - 数据持久化
Write Ahead Log (WAL)：为了确保数据的持久性和可靠性，TiKV 在实际修改数据之前，会先将操作记录到 Write Ahead Log (WAL) 中。即使系统崩溃，也可以通过重放 WAL 日志来恢复未完成的事务。
数据写入：一旦 WAL 记录成功，TiKV 会将实际的数据变更应用到存储引擎中。TiKV 使用 RocksDB 作为其底层存储引擎，数据会被写入内存中的 MemTable，并定期刷新到磁盘上的 SSTable 文件中。 - 事务提交
两阶段提交 (2PC)：TiDB 支持分布式事务，使用两阶段提交协议来保证事务的原子性和一致性。在第一阶段，协调者（通常是 TiDB Server）会向所有参与的 TiKV 节点发送预提交请求。如果所有节点都成功响应，则进入第二阶段，协调者发送提交请求，正式提交事务。如果有任何一个节点失败，则整个事务会被回滚。
乐观事务模型：从 TiDB 3.0 开始，还引入了乐观事务模型（Optimistic Transaction Model），它在提交时才检查冲突，减少了锁的使用，提高了并发性能。乐观事务模型适用于大多数场景，默认启用。 - 结果返回
响应客户端：一旦事务成功提交，TiDB Server 会将结果返回给客户端。如果事务失败，TiDB Server 会返回相应的错误信息，客户端可以根据需要进行重试或其他处理。 - 垃圾回收 (GC)
旧版本清理：由于 TiDB 使用 MVCC 机制，旧版本的数据会在一段时间内保留。为了节省存储空间，TiDB 定期运行垃圾回收（GC）进程，删除那些不再需要的旧版本数据。GC 的周期和安全点可以通过配置参数调整，以平衡性能和存储开销。
2 个赞