数据价值在线化丨TiDB 在企查查数据中台的应用及 v7.1 版本升级体验
内容提要
本文介绍了企查查在数据中台建设中使用 TiDB 的经验和应用，通过迁移构建了基于 TiDB+ Flink 的实时数仓框架，充分利用了 TiDB 的分布式架构、MySQL 兼容性和周边工具等特性，实现了数据的在线化处理。文章还分享了企查查在使用 TiDB 过程中的一些好用特性和版本升级经验，包括 TiDB 开源社区的活跃和稳定性对决策的重要性。
延伸解读
从MySQL到TiDB：迁移的考量与收益
企查查原有20多套MySQL数据库，面临单机性能瓶颈、热备效率低、无法直接对接Flink等问题。迁移至2套TiDB集群后，利用TiDB的MySQL兼容性，DBA几乎无学习成本；原生分布式架构支持水平扩展和高可用；完善的周边工具（如TiCDC、BR）提升了数据同步与备份效率。这一迁移不仅解决了原有痛点，还为实时数仓框架奠定了基础。
TiDB在数据中台中的实际应用与价值
TiDB覆盖了企查查数据中台从采集到清洗的全流程。通过TiCDC将数据同步到Kafka，供Flink清洗及下游消费，并利用CommitTs保证一致性。TiDB的分布式读写能力结合Flink实时计算，实现了数据价值在线化；与上下游生态的良好兼容性，提升了数据流转效率。此外，部分数据同步到ES和Hive，满足检索与离线分析需求。
版本升级体验：性能提升与问题应对
企查查从v4.0升级至v6.5.3再至v7.1.1，解决了早期版本中TiDB重启、DDL阻塞、TiCDC不稳定等问题。v7.1.1带来QPS峰值50-60K、95线响应时间降至10-30ms的性能提升，并引入了资源管控功能，降低30%成本。升级中也遇到内存控制参数调整和TiCDC参数无效的问题，但通过社区反馈迅速得到修复，体现了开源协作的优势。
好用特性解析：资源管控、GC与热点调度
TiDB 7.1的Resource Control特性支持多租户资源隔离，企查查对程序账号和非程序账号实施差异化管理，提升资源利用率并降低成本。GC功能支持28小时内任意时间点恢复，比MySQL binlog恢复更高效。热点自动调度能力在7.1版本得到增强，可自动调度热点数据，减少人工干预。这些特性共同提升了数据库的易用性和稳定性。
Q&A
企查查为什么从 MySQL 迁移到 TiDB？
MySQL 存在单机性能瓶颈，无法满足高并发写入和复杂 SQL 查询的需求；热备操作慢且恢复速度慢；不支持将数据直接投递到 Flink，对数据库压力大。TiDB 兼容 MySQL 协议，几乎无学习成本，原生分布式架构支持水平扩展和高可用，周边工具完善，社区活跃，大数据生态友好。
企查查如何构建实时数仓框架？
企查查基于 TiDB 和 Flink 构建了实时数仓框架，应用于数据中台。通过 TiCDC 将 TiDB 数据同步到 Kafka，供 Flink 清洗；使用自研 Flink Hybird Source 将数据入湖到 Iceberg，支持全量、增量和全增量一体同步模式。
TiDB 在企查查数据中台中有哪些应用价值？
TiDB 的分布式读写能力远超 MySQL，结合 Flink 实时计算保证数据实时性，提升数据分发查询能力，实现数据价值在线化；与上下游生态兼容性好，提高数据流转效率，盘活数据资产。
企查查使用 TiDB 的哪些好用特性？
Resource Control 满足多租户需求，提升资源利用率，降低 30% 投入成本；GC 支持任意时间点内数据恢复，效率高于 MySQL；热点自动调度，升级到 v7.1 后热点调度能力大幅提升。
企查查升级 TiDB v7.1.1 后性能提升如何？
升级后系统性能大幅提升，QPS 峰值达到 50-60K，95 线响应时间从 60ms 以上降低至 10-30ms。同时使用了 v7.1 的资源管控功能，满足业务需求。
企查查在 TiDB 版本升级中遇到哪些问题？
在 v4.0 版本中遇到删除大量数据后 TiDB 重启、DDL 阻塞、TiCDC 不成熟等问题；升级到 v6.5.3 后这些问题得到解决。在 v7.1.1 中遇到内存控制参数调整导致访问阻塞和 TiCDC partition_num 参数无效的问题，后者已反馈社区并修复。
