【TIDB】了解，MySQL和TiDB的取舍，差异
一句话总结：
MySQL 好用，但扩展性差；TiDB 像 MySQL，但能轻松应对大数据、高并发。
为什么用 TiDB 而不是 MySQL？
| 场景 | MySQL | TiDB |
|---|---|---|
| 数据量很大（几百 GB ～ TB） | 容易卡顿、查询慢 | 水平扩展，性能稳定 |
| 业务快速增长、分库分表难维护 | 需要人工做分库分表 | 自动水平扩展，无需分库分表 |
| 高并发写入（比如秒杀、交易） | 主从延迟、写入瓶颈 | 多副本写入，强一致性，吞吐更高 |
| 高可用要求 | 需要额外搭建主从/集群 | 内建高可用（Raft 协议） |
| 想用 MySQL 生态（SQL语法、驱动） | 支持 | 兼容 MySQL 协议，直接迁移 |
举个通俗易懂的例子：
- MySQL 像是一台单机的咖啡机，你用它泡咖啡很方便，但如果客人太多就会排队、宕机。
- TiDB 像是一排自动分工的咖啡机器人，可以自动分流、一起工作，而且泡出来的咖啡口味一致，客人再多也能顶得住。
TiDB 的核心优势
- 水平扩展（Scale-Out）：增加机器就能提升性能，不用重构业务。
- 强一致分布式事务：不像传统分库那样事务无法保证一致性。
- 兼容 MySQL 协议：学过 MySQL 就能用 TiDB，迁移成本低。
- 分布式 HTAP：既能做 OLTP（在线事务处理），又能做 OLAP（分析）。
什么时候该选 TiDB？
- 数据已经超过 500GB+，MySQL 开始慢。
- 业务增长快，怕 MySQL 扛不住未来3年的数据。
- 不想手动搞分库分表、数据迁移、主从高可用。
- 需要实时统计分析，又想兼容 OLTP。
如果你还是初学者，可以这样记：
MySQL 适合小而美、稳定不变的业务；TiDB 更像是 MySQL 的“集群加强版”，适合业务增长快、数据量大、并发高的企业级场景。