TDSQL-C通过存算分离HTAP架构突破MySQL性能与扩展瓶颈：计算层无状态化仅解析执行SQL，存储层采用分布式共享存储并支持PB级容量，基于Redo日志实现ms级同步；列存索引与并行查询使分析性能提升十倍以上，电商场景纯写入QPS达45万，秒级弹性扩缩容。
先看业务是否真需要分布式，而不是“看着别人上就跟着上”
很多团队一听说 TiDB 能水平扩展、支持 HTAP，就默认“MySQL 不行了，该换 TiDB 了”。但实际不是所有业务都适合——单机 MySQL 在 QPS 分库分表已成运维噩梦，比如你改一个报表 SQL 就要协调 6 个库、每次扩容都要停服 4 小时、或者凌晨跑批直接把主库连接打满。
评估起点不是“TiDB 多好”，而是“当前 MySQL 的瓶颈是否已无法通过架构优化缓解”。建议用真实指标说话：SHOW PROCESSLIST 查长期运行的事务、information_schema.INNODB_TRX 看锁等待、slow_query_log 统计 >1s 查询占比。如果 >5% 的慢查询集中在跨表关联或大范围 ORDER BY + LIMIT，且加索引/读写分离/缓存都收效甚微，那分布式才是解法。
重点检查三类不兼容项：存储过程、外键、隔离级别依赖
TiDB 兼容 MySQL 协议，但不是 MySQL 的复刻。最容易在上线后翻车的是业务隐式依赖的 MySQL 行为：
-
存储过程和触发器：TiDB 完全不支持，如果你的订单创建逻辑封装在
PROCEDURE create_order里，必须提前拆到应用层 - 外键约束：TiDB 会解析但忽略，不会报错也不会生效。若业务靠外键保证级联删除一致性（比如删用户自动删订单），上线后会出现脏数据
-
事务隔离级别：MySQL 默认
REPEATABLE READ，TiDB 悲观事务默认READ COMMITTED，乐观事务默认SNAPSHOT ISOLATION。如果代码里写了SELECT ... FOR UPDATE又依赖“可重复读”的幻读屏蔽能力，结果可能不一致
别只信文档说“兼容 95%”，用 tiup dmctl check-task 扫一遍线上慢日志，重点关注输出里带 UNSUPPORTED 或 BEHAVIOR_DIFF 的条目。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
成本不能只算机器钱，得把“人的时间”折进去
硬件成本常被高估，人力成本常被低估。TiDB 集群基础配置（3 PD + 3 TiKV + 2 TiDB）比同等负载的 MySQL 主从+中间件集群贵不了多少，但以下几块隐形成本容易漏算：
-
DBA 技能切换成本：查慢查询不再看
EXPLAIN，而要看EXPLAIN ANALYZE输出的 Region 扫描分布；调优不是调innodb_buffer_pool_size，而是观察tidb_slow_query_file里 TiKV 的get/scan延迟 -
监控体系重构成本：Zabbix 里那套 MySQL 模板不能直接套用。你得接入
grafana+prometheus，重点盯tikv_storage_async_request_duration_seconds和tidb_session_transaction_duration_seconds - 回滚预案执行成本：MySQL 切 TiDB 后发现某核心报表性能下降 30%，想切回去？得确保 binlog 位置可追溯、MySQL 从库没因长时间不同步而被 purge、应用连接池能快速切回旧地址——这些都得在迁移前实测，不能只写在文档里
一个经验判断：如果 DBA 团队没人在测试环境跑过 3 个月以上 TiDB 真实业务流量，就别谈生产迁移。协议兼容只是起点，行为对齐才是难点。
验证阶段必须做“双写压测”，而非仅校验数据一致性
很多人以为用 pt-table-checksum 校验完数据一致就万事大吉，但这是最浅一层。真正的风险藏在并发写入路径里：
- MySQL 支持
INSERT IGNORE和ON DUPLICATE KEY UPDATE，TiDB 在悲观事务下表现相同，但在乐观事务下可能因冲突重试失败，导致应用层收到WriteConflictError - 批量导入时，MySQL 的
LOAD DATA INFILE是原子的，TiDB 的tidb-lightning导入期间表不可读，若业务有实时查询需求，得提前规划只读窗口 - 长事务（>10 分钟）在 TiDB 中会阻塞 Region Merge，拖慢整个节点吞吐。而 MySQL 的长事务只影响本实例
务必在预发环境模拟真实流量双写：让一半请求走 MySQL，一半走 TiDB，用影子表比对结果，并用 go-wrk 对关键接口施加峰值 QPS 压力。重点看 TiDB 是否出现 LockWaitTimeout 或 PD server timeout 类错误——这些在低并发校验里根本不会暴露。
