By

前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、和 mysql 基本对比

  • 选 TiDB：当业务需要处理海量数据 + 复杂分析查询，且对秒级响应可接受时，分布式计算优势显著。
  • 选 MySQL：当业务以简单查询 + 低延迟交易为主，数据量未触及单机瓶颈时，单机架构更高效。
场景维度 TiDB 优势场景 MySQL 优势场景
数据规模 亿级以上（分布式计算优势） 千万级以下（单机性能足够）
查询类型 复杂聚合（COUNT/SUM/JOIN）、分析型查询 简单查询（单表主键查询）、OLTP 交易型查询
延迟敏感性 秒级响应可接受（如报表统计） 毫秒级响应（如支付扣款、秒杀下单）
计算资源需求 需要并行计算能力（多节点分摊压力） 单机计算资源足够（CPU / 内存利用率低）

电商订单分析（复杂查询）：TiDB：统计 “近 30 天各品类销售额 TOP10”，利用分布式聚合秒级返回结果；MySQL 单机可能因全表扫描超时，分库分表需跨库聚合，开发复杂且性能不稳定。

用户登录验证（简单查询）：MySQL：查询用户信息（单表主键查询），响应时间 < 10ms，满足实时性要求；TiDB 因跨节点调用延迟可能达 20ms，用户感知轻微卡顿。

1、架构与扩展性：从单机到分布式的突破

1）MySQL 的单机瓶颈与 TiDB 的分布式架构

  • MySQL 的局限性
    • 单机存储与计算能力有限，数据量超过 TB 级或并发量高时，性能会显著下降。
    • 分库分表需要手动设计与维护，增加开发复杂度（如跨库 ` Join`、事务一致性问题）。
  • TiDB 的分布式优势
    • 采用 Shared-Nothing 架构，支持水平扩展（计算节点 ` TiDB Server、存储节点 TiKV），理论上可扩展至 PB` 级数据。
    • 自动数据分片（Region机制）与负载均衡，无需手动分库分表，开发成本低。
    • 在线事务处理( TP )底层存储采用行存, 在线分析( AP )底层存储采用列存, 相互隔离互不影响。业务可以像使用 MySQL一样简单的使用 TiDB, 无需分库分表的烦恼, 无需关心拆分键.

2）弹性扩展能力

  • MySQL：扩展需通过主从复制、分库分表，但主从同步存在延迟，分表后难以应对复杂查询。
  • TiDB：新增节点即可自动平衡数据与负载，支持在线扩缩容，对业务无中断。

2、性能：海量数据与高并发场景的优化

1）查询性能对比

a、亿级数据 + 复杂计算（优势）

  • tidb
    • 优势： 复杂查询的瓶颈在于计算能力，TiDB 通过分布式扩展计算节点，将 ` O(n) 的单机计算复杂度降为 O(n/m)（m` 为节点数），性能随节点增加线性提升。
      • 原理：TiDB 通过分布式架构将查询拆分为多个子任务，在多个 TiKV 节点并行处理（如分组统计、多表 JOIN），利用多节点计算资源缩短整体耗时，聚合性能提升 10-100 倍（例如：亿级数据分组统计可在秒级完成）。。
      • 示例：对 1 亿条订单数据按 “日期 + 品类” 分组统计总金额，TiDB 可将数据分片到 10 个节点并行计算，每个节点处理 1000 万条，最终合并结果，总耗时约 1-2 秒；而 MySQL 单机需扫描全量数据，耗时可能超过 1 分钟。
    • 劣势：复杂查询的瓶颈在于计算能力，TiDB 通过分布式扩展计算节点，将 ` O(n) 的单机计算复杂度降为 O(n/m)（m` 为节点数），性能随节点增加线性提升。
  • MySQL：单机查询时，亿级数据的 JOIN、分组统计（如 COUNT、SUM）易出现慢查询，需依赖索引优化或分库分表。

b、简单查询（劣势）

  • 说明：MySQL 单节点查询直接访问本地磁盘，无需跨网络调用；而 TiDB 的简单查询（如单表主键查询）可能涉及跨节点路由（即使数据在同一节点，也需通过 TiDB Server 转发），引入额外网络延迟（约 5-10ms）。
    • 本质：简单查询的瓶颈在于IO 延迟，TiDB 的分布式链路（客户端→TiDB Server→TiKV→返回）比 MySQL 的单机链路（客户端→MySQL Server→本地磁盘→返回）多了网络交互步骤，放大了延迟。
  • 示例：查询单条用户数据（如 SELECT * FROM user WHERE id=123），MySQL 单节点响应时间约 1-2ms，TiDB 因跨组件调用（TiDB Server→TiKV→返回结果）可能耗时 10-20ms。
  • 核心劣势：分布式架构的网络开销影响了简单查询的延迟，尤其对毫秒级响应要求的场景（如高频交易）。

2）写入与事务性能

  • MySQL：InnoDB 引擎在高并发写入时，受锁机制影响（如行锁、表锁），易出现性能瓶颈。
  • TiDB：支持分布式事务（基于 Percolator 协议），通过多节点并行写入提升吞吐量，同时保证 ACID 一致性，适合交易类场景。

3、功能兼容性：MySQL 生态的无缝迁移

1）SQL 兼容性

  • TiDB 兼容 MySQL 5.7 协议与语法（如 DDL、DML、函数），应用程序无需大幅修改即可迁移，降低改造成本。
  • 支持 MySQL 生态工具（如 Navicat、MySQL Workbench、ORM 框架），运维与开发习惯无缝衔接。

2）生态集成与工具链

  • MySQL 生态成熟，但分布式扩展需额外组件（如 MyCat、Sharding-JDBC），稳定性与运维成本较高。
  • TiDB 自带分布式集群管理工具（TiUP），支持自动化部署、监控与故障恢复，且兼容 Prometheus、Grafana 等监控体系。

4、企业级需求：高可用、一致性与运维

1）高可用性架构

  • MySQL：主从复制架构下，主库故障需手动切换，存在数据丢失风险（异步复制）。
  • TiDB：
    • 三副本保证数据强一致性，任意节点故障可自动选举新节点，服务不中断。
    • 支持多机房部署（如同城多活、异地灾备），满足金融级高可用需求。

2）数据一致性与事务

  • MySQL：分布式事务需依赖 XA协议，性能损耗大，实现复杂。
  • TiDB：原生支持分布式强一致事务，适用于金融、电商等对事务要求高的场景（如订单支付、账户扣款）。

3）运维与监控

  • MySQL：分布式场景下运维复杂度高（如分表管理、主从同步监控）。
  • TiDB：自动化运维工具（TiUP）支持一键部署、扩容、缩容，内置监控面板（TiDB Dashboard）实时展示集群状态与性能指标。

5、与 MySQL 的成本对比

  • 硬件成本：TiDB 需多节点部署，初期硬件投入高于单机 MySQL，但数据量超过 TB 级后，MySQL 分库分表的硬件与运维成本会反超 TiDB。

  • 人力成本：TiDB 减少分库分表开发与运维工作量，长期来看人力成本更低。

  • 更少的资源占用：相同数据量下 TiDB 存储的磁盘占用是 MySQL 的 1/3 , 更加节省存储资源, 降本增效.

6、分库分表

1）原生分布式能力

  • MySQL 分库分表：表结构设计时必须为每个表设计合适的分片键，并且在 SQL 查询时指定分片键，否则对集群的影响是灾难性的；不支持全局二级索引，必须加上分片键才能实现精确查询，牺牲了业务多维自定义查询能力，对业务有极高侵入性，对于开发有极大挑战，增加系统架构的复杂度。
  • TiDB：建表 + 使用（SQL）无需指定分片 / 区键，无业务侵入性；大幅提升开发效率；支持全局二级索引，提供多维自定义查询能力，与单机 MySQL 使用习惯一致。

2）分布式事务

  • MySQL 分库分表：分库分表的分布式事务大部分基于弱一致性事务，需要外部组件来实现，或者需要业务来实现，对业务开发非常不友好。

  • TiDB：100% ACID（金融级保障），分布式事务性能良好，显著提升业务开发效率。

3）在线水平横向扩展

  • MySQL 分库分表：分库分表架构在进行在线水平横向扩展时，非常麻烦，几乎所有的数据都要重新分布，对于开发和运维的压力巨大，业务连续性无保障。

  • TiDB：存储计算分离架构，灵活性较高，存储和计算节点一键在线水平扩展，不影响业务，大幅缩短扩展实施周期。

  • 在线 DDL

    • MySQL 分库分表：虽然 MySQL 本身支持一定 Online DDL，但在分库分表架构下，DDL 需在多个物理分片上重复执行，缺乏统一管控，运维复杂度呈指数级上升；且扩容需重新分片和迁移数据，难以实现在线无感扩展。

    • TiDB：基于存储计算分离架构，支持计算与存储节点的独立在线扩缩容，数据自动再平衡，对业务透明；同时提供原生 Online DDL，绝大多数操作不锁表，如添加列可在秒级完成（即使在超大表上），索引创建虽为异步但仍不影响业务读写，显著提升运维效率和系统可用性。

      • 使用全局版本号 + 异步任务队列；
      • 大多数 DDL（如 ADD INDEX, ADD COLUMN）为非阻塞；不会锁表，DML 可正常进行；
      • DDL 操作提交后立即返回（对于 ADD COLUMN 这类 instant 操作确实是“秒级”）；
      • 对于 ADD INDEX，虽然不锁表，但构建索引是后台异步任务，耗时取决于数据量（可能几分钟甚至几小时），但不影响查询和写入；

4）分析能力

  • MySQL 分库分表：MySQL 原生能力比较差，使用分库分表架构后，对于复杂 SQL 的支持问题突出，需要引入外部分析引擎才能承载业务模块的基础分析需求。

  • TiDB：基于 MPP 架构的列式存储引擎提供实时分析能力，能够在隔离性、实时性、一致性上得到保障，提供实时的分析。

5）高可用

  • MySQL 分库分表：高可用切换需要外部组件或者人工进行干预，跨中心复制方案不完善。

  • TiDB：内置 Raft 一致性协议，大多数副本存活的情况下可实现自恢复，支持同城多中心、双中心，两地三中心等金融级高可用方案。

6）服务支持

  • MySQL 分库分表：中间件 + MySQL 方案缺乏原厂商业保障。

  • TiDB：提供本地化的原厂商业服务支持。

7）建设成本

  • MySQL分库分表：分库分表支持的业务负载单一，为支撑业务中台的业务需求，需要引入多个技术栈才能提供完整服务，建设成本高、周期长，开发运维复杂。

  • TiDB：一套技术栈解决 80% 以上的业务需求，敏捷高效，建设与开发运维成本低。

二、差异对比

1、DDL

1）结论

  • 业务能接受秒级延迟、数据量不大、成本敏感 → MySQL + Sharding 仍可胜任；
  • 追求高可用、无缝扩缩容、高频 DDL 变更、超大表 → TiDB 的无锁 DDL 和弹性架构优势明显
维度 MySQL TiDB
锁机制基础 依赖传统 表级锁 + 元数据锁（MDL） 通过状态机 + 版本控制实现并发安全
DDL 执行方式 单节点本地执行，可能阻塞 DML 集群范围异步任务调度，完全解耦
是否真正“不锁表” 大部分操作“短时加锁”，接近无锁 真正无锁，DDL 与 DML 完全并发
跨节点一致性 不适用（单实例） 通过 Raft 协议保证元数据强一致
典型场景表现 ADD INDEX 可并发 DML，但有短暂 MDL 锁 所有 DDL 提交即返回，后台异步完成，全程不影响业务
     
长事务期间执行 DDL DDL 被阻塞，直到事务结束（常见“DDL 卡住”问题） DDL 立即提交，不受长事务影响
对 1TB 表 ADD INDEX 耗时较长，最后有短暂 catch-up 锁（毫秒级） 提交秒级返回，后台异步构建，无锁
并发 DML 压力大时 DDL row log 可能积压，影响性能 DML 正常进行，DDL 后台限速执行

2）执行流程对比

a、Mysql：基于“锁 + 日志”的局部并发模型

1）元数据锁（Metadata Lock, MDL）：

  • 所有 DDL 和 DML 操作在打开表时都会申请 MDL；
  • DDL 需要 排他 MDL（X锁），DML 需要 共享 MDL（S锁）；
  • 当 DDL 开始时，必须等待当前所有事务释放 S 锁，然后自己加 X 锁 → 可能阻塞新 DML。

2）表级锁控制（LOCK=NONE/SHARED/EXCLUSIVE）：

  • 控制 DDL 执行期间是否允许 DML；
  • 实际是通过 row log 缓冲区 记录并发变更，最后重放；
  • 但为了安全，某些阶段仍需短暂排他访问。

b、TiDB：基于“状态机 + 分布式协调”的无锁架构

核心设计理念：DDL 不是“操作”，而是“状态变更” ，TiDB 的 DDL 完全脱离了传统数据库的锁模型，采用类似分布式系统的状态机演进思想。

  1. 用户提交 DDL：ALTER TABLE t ADD INDEX idx_x(x);

  2. 接收节点将 DDL 任务写入 KV 存储的 DDL Job Queue（持久化）
  3. Owner 节点从队列中获取任务，将其状态设为 “running”
  4. 开始分批扫描数据，构建索引（异步后台任务）
  5. 同时，所有 TiDB 节点继续处理 DML：
    • DML 使用当前 Schema Version 读写数据；
    • 新插入的数据也会被后续索引构建任务覆盖；
  6. 构建完成后，Owner 将 Job 状态改为 “completed”，并更新全局 Schema Version
  7. 各 TiDB 节点在 Lease 到期后拉取新 Schema Version，自动生效

3）问题

a、MYSQL DDL关键瓶颈：

  • MDL 冲突：如果有一个长事务未提交，DDL 会一直等待，导致“DDL 卡住”；
  • 最后 catch-up 阶段：虽然时间短，但仍需短暂阻塞写入；
  • 单点执行：所有操作在一台 MySQL 实例上完成，资源竞争明显

b：为什么说 TiDB “真正无锁”？

  • MySQL 像在一条高速公路上修收费站：施工时要临时封路一会儿（加锁），修好后再开放。
  • TiDB 像在旁边悄悄建一个新收费站，车照常通行老路；等新收费站建好了，系统自动切换路线，司机毫无感知。
特性 说明
没有 MDL TiDB 不使用 MySQL 那样的元数据锁机制
DDL 提交即返回 客户端提交 DDL 后，只要写入 Job Queue 成功就返回，无需等待完成
DML 全程并发 所有读写操作不受 DDL 影响，因为它们基于当前 Schema Version 执行
最终一致性 索引是逐步构建的，查询可能暂时走不到新索引，但数据绝对一致

ContactAuthor