TiDB 适用场景：
1.强一致性分布式事务：
可以把 TiDB 想象成一个单机的 RDBMS，ACID 事务可以在多节点间进行，无需担心一致性问题。 TiDB 对业务
没有任何侵入性，是传统的数据库中间件、数据库分库分表等优雅的替换方案。
重点解决 MySQL 的单机性能和容量无法线性和灵活扩展的问题
.
2.数据归档库：
若存储不足的时候可以水平扩展机器，TiDB的存储量大，归档的时候可以无需考虑磁盘空间。
配合TiDB的工具
(syncer\mydumper\loader 和TIDB DM
)可实现自动归档，当然也无需要考虑源库的操作。
顺序写入的场景：日志写入、数据审计、财务流水
3.MySQL单库超过亿行级别的表较多，否则量级达不到性能不如MySQL。至少是
5000万行级别以上的。
4.业务爆发式增长，有高并发，业务量增长较快。
5.OLAP：
TiDB 本身的SQL对OLAP支持有限制，需要结合TiSPark
.在TiDB3
.0之前不支持view，不支持windows functions，
CTE也不支持，TiDB自身对OLAP查询有限。由于TiDB优先OLTP，借鉴Google的 spanner，
对批量INSERT、UPDATE、DELETE操作单次限制在
30万行，需要手动修改参数支持DML大批量操作。
6.MySQL
+MyCAT 这种分库分表的数据合并：
MySQL
+MyCAT的可支撑单表
10亿级别的业务，但是需要配置MyCAT等数据库中间件
,比较繁琐。
由于TiDB自身就支持自动分片的功能，可以替换MySQL
+MyCAT这种方案。
7.异地多中心、auto
-Failover保证数据库高可用
:
TiDB 使用多副本进行数据存储，并依赖业界最先进的 Raft 多数派选举算法确保数据
100% 强一致性和高可用。 副本
可跨地域部署在的不同的数据中心，主副本故障时自动切换，无需人工介入，自动保障业务的连续性，实现真正意义上
的异地多活。不过在实际部署异地多活的时候还是需要考虑网络传输等因素
.
8.数据量大时
,水平弹性扩展
:
分布式的 TiDB 可随着你的数据增长而无缝地水平扩展，只需要通过增加更多的机器来满足业务增长需要，应用层可以
不用关心存储的容量和吞吐。 TiDB 根据存储、网络、距离等因素，动态进行负载均衡调整，以保证更优的读写性能。
TiDB 不适用场景：
1.MySQL单表存储数据在亿级别以下的时候，MySQL
+MyCAT方案性能要比TiDB高。
2.资金预算紧张的情况下，运行一个TiDB集群至少需要
6台高配SSD硬盘的主机
(建议支持NVME协议
)
随着时间的推移和硬件的发展，硬件成本会降低。
3.TiDB on cloud
虽然有TiDB operator 项目，但是截至
2019年
3月还不稳定和性能不足，不推荐运行在生产的kubernetes集群。
尚在PoC阶段。但是Cloud DB 是大势所趋。
4.要求
100%不修改源代码迁移应用从MySQL迁移到TiDB。
这个主要是TiDB目前对MySQL的函数和功能的兼容性不足导致的。预期TiDB
3.0会兼容MySQL8
.0版本大部分功能。
TiDB 不足的地方：
1.宣称HTAP，对于OLAP支持还需要大力发展
,一般OLAP是列存计算上有比较大的优势
,如何在一个数据库里做到行存和列存共存是需要解决的。
2.采用RocksDB 作为存储引擎，其自身存在写放大缺陷
(Write Amplification
)
3.由于是兼容MySQL的语法，而不是标准SQL，对一些高频SQL语句
(merge、full join等
)支持不足
4.TiDB作为OLAP应用的时候，若OLTP和OLAP放置到一起对业务影响还是会较大的，需要做资源限制。尚需TiDB的
开发人员努力优化的，作为宣称的HTAP性能有待商榷和验证。
业界采用的方案：
BAT三家有自己开发的对应的云数据库，国内的
TMD(toutiao、meituan\xiaomi、didi
)等互联网企业均有使用
.
https
://pingcap
.com
/cases
-cn
/
被替换的产品：
1.TiDB替换掉MySQL
+MyCAT
2.TiDB替换掉Hbase
3.TiDB替换掉
4.替换掉OLTP和OLAP是两套存储和计算的方案
TiDB 畅想：
1.如何提升OLAP的性能？支持列存数据库
2.对于新兴的硬件的支持如GPU加速、FPGA
.
3.生产级的TiDB on kubernetes
4.SQL标准的支持而非MySQL的SQL 方言
