2023 年 11 月，杭州银行以平凯数据库（TiDB 企业版）为底层数据库的新一代核心业务系统正式投产，完成了从传统集中式数据库向云原生、分布式、全栈国产化架构的升级。在这一过程中，双方围绕产品适配、性能优化、高可用容灾和数据迁移开展了深度共创，不仅建设了同城双活、异地灾备的“两地三中心”体系，还共同沉淀了全链路数据迁移平台及覆盖开发、测试、发布、监控和运维的分布式数据库管理体系。
近日，在 TiDB 社区活动宁波站上，杭州银行数据库专家邵健分享了杭州银行在数据库国产化改造过程中的实践经验，内容覆盖平凯数据库金融级部署架构、核心系统容灾建设、数据库开发规范，以及规范平台化管控等多个方面。
按照业务等级设计 TiDB 部署架构
金融机构内部系统数量众多，不同系统对可用性、数据一致性和灾难恢复能力的要求并不相同。如果所有系统采用同一种部署架构，不仅难以兼顾业务需求，也可能带来不必要的建设和运维成本。
为此，杭州银行根据业务系统等级，制定了差异化的 TiDB 部署标准。
- 普通业务系统可采用单集群三副本或五副本架构，部署在单个数据中心或多个数据中心。这类架构维护相对简单，硬件成本较低，可以满足一般业务系统的连续性要求。
- 重要业务系统采用“3+1 副本”、DR-AutoSync 与备份相结合的架构，支持多数据中心部署。同城中心之间通过强一致性复制保障数据安全，并配置跨集群容灾能力。
- 对于核心系统，则采用“5+1 副本”、DR-AutoSync、TiCDC 容灾及备份相结合的部署模式，按照金融级“两地三中心”标准建设。在该架构下，数据恢复点目标 RPO 可以达到 0，恢复时间目标 RTO 不超过 30 秒。
这种分级建设方式，使数据库架构能够与业务等级相匹配：核心系统重点保障数据强一致性和快速恢复，重要系统兼顾容灾能力与建设成本，普通系统则更加关注部署和维护效率。
构建“两地三中心”金融级容灾体系
杭州银行核心系统以杭州为主中心、临平为同城中心、合肥为异地中心，形成“两地三中心”的整体布局。
主中心与同城中心采用“5+1 副本”架构，通过 DR-AutoSync 保证数据强一致性。同城中心还部署了 TiCDC 逻辑副本，用于承载数据抽取、只读查询、逻辑备份等任务。
将这些非核心交易负载从主集群中分离出来，可以减少查询和数据抽取对联机交易的影响，同时为核心业务切换提供更多保障。例如，部分数据汇聚、ETL 抽取、内部查询接口和逻辑数据导出等任务，可以由同城逻辑灾备集群承担，从而实现核心数据库的读写分离。
异地中心位于合肥，通过 TiCDC 接收同城中心同步的数据，并采用单中心三副本部署。逻辑备份数据首先写入对象存储，再进入磁带系统长期保存，形成集群副本、逻辑灾备、对象存储与磁带归档相结合的多层数据保护体系。
金融机构需要定期开展灾备切换演练，而且实际演练可能在临时通知后迅速启动。因此，数据库架构不仅要保证数据能够同步过去，还要考虑业务能否在规定时间内恢复。多副本部署、同城强一致复制、异地逻辑灾备和长期备份共同构成了核心系统连续运行的基础。
数据库国产化不只是完成产品替换
完成从 Oracle 到 TiDB 的迁移，并不意味着国产化改造已经结束。不同数据库在数据类型、事务机制、索引组织、字符集和执行方式等方面存在差异。如果仍然沿用原有数据库的设计和开发习惯，系统在迁移后可能出现性能下降、热点集中或兼容性问题。
因此，在建设 TiDB 数据库底座的同时，还需要形成与分布式数据库特点相匹配的开发规范。
杭州银行的 TiDB 开发规范主要分为三类：
- 设计规范，包括命名、建表、数据类型、函数、索引和事务等要求；
- SQL 规范，包括 DML、DDL、JOIN、UNION 和空值处理等要求；
- 性能规范，包括慢SQL预防、事务控制、锁操作、JDBC 和连接池配置等要求。
这些规范既服务于新系统开发，也用于指导 Oracle、MySQL 等存量系统向 TiDB 迁移。
统一数据库对象的设计标准
在数据库对象命名方面，杭州银行对数据库名、表名、字段名和索引名等进行统一管理。对象名称使用具有实际含义的英文词汇，词汇之间以下划线分隔，并控制名称长度和单表字段数量。
表名由表类型、模块代码和英文词根组成。例如，不同前缀可以分别表示参数表、历史表、备份表、迁移中间表、临时表、业务明细表、主表、关系表和交易流水表。通过表名前缀即可初步判断数据用途，并针对不同类型选择相应的优化和治理策略。
建表时必须设置主键，同时禁止使用外键，关联约束由应用端实现。主键优先选择与业务相关的字段，不使用与业务无关的自增列，也不宜使用更新频繁或随机生成的字段。
TiDB 默认使用聚簇表。对于容易出现写入热点的流水表等场景，可以使用非聚簇表，并通过 SHARD_ROW_ID_BITS 等方式打散数据，降低集中写入形成热点的风险。
处理好 Oracle 与 TiDB 的类型差异
从 Oracle 迁移至 TiDB 时，数据类型映射是需要重点处理的环节。类型选择不当，可能导致精度变化、数据同步失败，或者在SQL执行时发生隐式转换。
杭州银行针对 Java、TiDB 和 Oracle 建立了统一的数据类型映射。例如，金额和其他高精度数值在 TiDB 中使用 Decimal 类型，与 Oracle 的 Number 类型进行适配；日期使用Date类型，包含日期和时间的信息使用 Datetime 类型；需要毫秒精度的时间信息则使用 Datetime(3)。
字符集也需要统一处理。原有 Oracle 核心系统使用 ZHS16GBK 字符集，迁移到 TiDB 后统一使用 UTF8MB4 字符集，并采用 UTF8MB4_BIN 排序规则。
字符集检查不能只停留在表级别，还需要落实到字段级别。如果关联字段的字符集或排序规则不一致，可能引发隐式转换，使执行计划偏离预期，甚至导致索引无法有效使用。
控制索引数量，提高索引有效性
索引并非越多越好。索引可以提升查询速度，但同时会增加数据写入、更新和存储的成本。
要求单张表的索引数量原则上控制在 5 个以内，复合索引中的字段数量建议不超过 5 个。索引应优先选择区分度较高的字段，避免在性别、状态标志等低基数字段上单独建立索引。
复合索引需要遵循最左前缀原则，将复用度较高的字段放在靠前位置，并尽可能使用覆盖索引，减少回表带来的额外开销。
对于 ORDER BY、GROUP BY、DISTINCT 等可能产生排序操作的场景，也需要结合查询方式合理设计索引，避免数据库执行不必要的大规模排序。
限制复杂关联，减少不必要的数据库开销
在 SQL 开发方面，根据实际测试结果，对单条语句关联的表数量进行控制。通常情况下，联表数量控制在 3 个以内；如果超过 3 个，则需要结合业务场景评估是否拆分 SQL。
这并不意味着联表查询一定比多次单表查询慢。在适当的数据规模和索引条件下，3 个以内的联表查询可能比多次单表查询更高效。但随着关联表数量继续增加，执行计划复杂度和中间结果集规模也会相应上升，性能未必能够保持。
SQL开发还应遵循以下原则：
- 查询和 DML 操作必须带有明确的过滤条件；
- 避免直接使用
SELECT *，只查询业务真正需要的字段； - 尽量避免不必要的标量子查询，并控制子查询数量；
- 减少
LEFT JOIN和RIGHT JOIN的使用，适合使用内连接时优先采用内连接； - 优先使用
UNION ALL，避免UNION带来的额外去重开销； - 减少
OR条件，可根据场景使用IN或UNION； - 条件字段与传入参数的数据类型保持一致，防止隐式转换导致全表扫描。
这些要求的核心并不是简单限制 SQL 写法，而是减少不可控的执行计划和数据库资源消耗。
拆分大事务，优化批量处理效率
金融系统每天需要执行大量批处理任务。如果将过多数据放在同一个事务中处理，会增加内存、锁和日志压力，也会提高事务失败后的回滚成本。
通过平台控制批量任务的事务规模，要求批量写入先分段、再分批提交。根据业务类型和处理方式，可以将每 1000 至 2000 行作为一个事务；对于按账户处理的批量任务，则进一步控制每批账户数量。
在实际应用中，完成大事务拆分后，部分原本需要约 3 小时执行的夜间批量任务，处理时间缩短至 1 小时以内。性能提升并非仅来自数据库本身，也来自事务模型、批量策略和应用逻辑的共同优化。
事务隔离级别统一采用 RC，并结合悲观锁进行业务开发。对于SELECT ... FOR UPDATE场景，过滤条件需要使用唯一索引或主键，以减少锁定范围。
应用还需要捕获事务提交状态和数据库错误码，并设置明确的异常处理逻辑。否则，数据库异常会直接传递给业务系统，影响后续事务处理和业务状态判断。
通过连接池配置降低节点变更影响
应用通常通过负载均衡连接多个 TiDB Server 节点。在生产变更、节点升级或启停过程中，如果连接池长期保留旧连接，可能导致应用继续访问已下线的节点。
在连接池中重点配置 maxLifetime 和 keepaliveTime 等参数，为数据库连接设置合理的生命周期和保活周期。连接达到生命周期后会被释放并重新建立，从而使连接能够在不同 TiDB Server 节点之间更新。
借助连接池生命周期管理和负载均衡机制，TiDB Server 节点的启停和升级可以尽量减少对业务的影响，为生产环境的滚动变更创造条件。
将开发规范嵌入管理平台
规范制定之后，真正的难点在于如何保证研发人员持续执行。如果主要依靠人工评审和文档宣贯，不同团队对规则的理解和执行程度容易出现差异。
通过自研 DAP 平台，将数据库规范划分为强控类规则和提醒类规则，并嵌入程序开发、SQL 生成、测试验证和生产发布流程。
强控类规则不满足要求时，相关对象或 SQL 无法继续进入后续流程；提醒类规则则用于提示潜在风险，由研发人员结合业务情况确认。
可以检查表是否存在主键、字段类型是否合规、表字段是否过多，以及字符集和排序规则是否一致等问题。
还会通过注释方式为每条 SQL 注入唯一标识。出现慢 SQL 或生产异常时，可以利用这一标识将数据库日志与业务日志关联起来，快速定位 SQL 所属的业务系统、功能模块和研发团队，提高问题诊断效率。
建立覆盖开发、测试、发布和运维的闭环
数据库治理不能只关注 SQL 进入生产之前的检查，还需要覆盖测试、发布和日常运行阶段。
数据库变更需要依次经过 SIT、UAT、准生产和生产环境。变更管控系统负责审批、任务下发和执行，并保持不同测试环境之间的数据库结构一致。在正式生产发布前，还会经过灰度验证，验证成功后再逐步扩大发布范围。
进入生产环境后，监控平台会持续采集数据库运行指标，并按照既定规范开展日常检查。没有主键的表、索引冗余、自增列、宽表、字段类型、字符集和排序规则等，均被纳入常态化巡检范围。
由此，数据库规范不再是一份静态文档，而是形成了“规范制定—平台实施—环境验证—生产发布—监控检查”的完整闭环。
从基础软件替换走向体系化能力建设
杭州银行的实践表明，金融数据库国产化并不是简单地用一种数据库替换另一种数据库。真正稳定的国产化体系，需要同时完成数据库架构、应用开发方式、事务模型、发布流程和运维治理的调整。
其中，金融级高可用架构解决的是数据库“稳不稳”的问题，开发规范解决的是应用“用得对不对”的问题，平台化管控解决的则是规范“能否持续执行”的问题。
只有将数据库产品能力与金融机构自身的研发、测试和运维体系结合起来，才能使国产数据库从“完成迁移”进一步走向“稳定运行”和“规模化应用”。
想进一步了解杭州银行在 TiDB 金融级架构、开发规范与全流程治理方面的实践细节，可前往 TiDB 社区下载本次分享的完整演讲 PPT。