编者按
在证券行业，“高频、高敏、高复杂”是核心业务系统的典型特征。面对早盘集合竞价的每秒数万笔请求，以及“业务中断不得超过 5 分钟”的监管红线，数据库的稳定性与性能是企业的生命线。在国产化浪潮下，中泰证券面临着巨大的挑战：如何从管理数百套 MySQL 平滑过渡到国产数据库？如何在预算有限的情况下实现上千套实例的统一管理？如何避免“为了改造而改造”，真正实现降本增效？
本文整理自中泰证券信息技术管理部总监孙永富的公开演讲。他详细复盘了中泰证券从数据库选型、资源池化建设到智能化运维的全链路实践。通过引入分布式数据库——平凯数据库及其多租户资源池方案，中泰证券不仅实现了千万级的直接成本节省，更完成了从“人工运维”到“平台化、智能化运维”的质变。
中泰证券信息技术管理部总监孙永富
一、 选型背景：在“高压”下寻找最优解
中泰证券的业务场景对数据库有着极其严苛的要求。以核心系统为例，单一节点在集合竞价期间每秒请求量高达 5 万笔。在这个场景下，数据库必须具备极致的性能和快速恢复能力——我们内部要求，一旦出现故障，必须在 5 分钟内恢复业务。
在引入平凯数据库之前，我们的数据库运维经历了从“手工阶段”到“标准化、自动化”的演进。但随着系统数量激增至 1200 多套（其中国产化数据库占比日益提高），单纯靠堆人力的“人肉运维”已难以为继。我们需要一个既能满足国产化要求，又能解决大规模管理难题的平台化解决方案。
二、 选型之路：不看广告看疗效
在国产数据库选型的过程中，我们没有盲目听信厂商宣传，而是制定了一条严谨的“漏斗式”选型路径：
- 初步筛选与大规模 POC：我们选取了市场上主流的国产数据库，基于真实的业务场景制定了 6 大类、200 多个子场景的测试用例（涵盖全写、全读、跑批、清算等），进行严格的 PK。
- 深入调研与供应链评估：除了性能，我们高度关注厂商的研发人员规模（规避供应链风险）、本地化支持能力以及产品是否为原生分布式架构。
- 生态优先原则：我们非常看重开源社区的活跃度和行业案例。“如果中信建投这样体量的友商都敢用，那我们用起来就更有底气。” TiDB 活跃的开源社区和丰富的金融行业案例，是我们建立信心的关键。
我们在针对多个数据库的测试中发现了一些国产数据库的通病：
- 高可用陷阱：有些数据库在遇到几十 GB 的大事务或 IO 打满时，无法自动切换，或者切换导致服务长时间中断；
- 统计信息缺失：面对证券行业典型的“朝生暮死”表（早盘数据激增，晚盘清空），部分数据库缺乏自动更新统计信息的机制，导致执行计划跑偏；
- 单进程风险：部分单进程架构的数据库，一旦被某个用户的特定 Bug 触发宕机，会牵连所有用户，导致业务反复震荡。
最终，TiDB 凭借原生分布式架构、对 MySQL 的高度兼容性（几乎无需修改代码）、强大的生态以及对混合负载的支持，成为了我们的核心选择。
三、策略复盘：以开源做“技术蓄水”，以商业版如期“交卷”
在最终敲定平凯数据库（TiDB 企业版）之前，我们其实经历了一个非常关键的“技术储备期”。这也是我们能高效响应国产化要求的秘诀所在。
第一阶段：借力开源，低成本试错与人才孵化。早在国产化要求到来之前，我们就已经利用 TiDB 的开源版本在非核心业务和测试环境中进行了大量的“实战演练”。
- 低成本验证： 开源版本让我们在不涉及复杂采购流程的情况下，就能先行验证分布式架构与我们业务的适配度（POC）。
- 人才前置培养： 在采购商业版之前，我们的团队已经通过开源社区的学习和实操，熟悉了 TiDB 的运维逻辑。这使得我们内部早早就有了一批懂分布式数据库的 DBA，完成了 20 多人的内部技术认证。
第二阶段：无缝升级，满足合规与服务兜底。当国产化的时间节点压下来时，我们没有像其他企业那样因为技术路线切换而手忙脚乱。因为内核的一致性，我们从开源版升级到商业化的平凯数据库几乎是“无缝”的，但这一步升级带来了质的变化：
- 合规落地： 商业版完全符合金融国产化的监管要求，帮助我们顺利通过了相关的验收与检查。
- 企业级特性解锁： 我们获得了很多开源版不具备的高级特性（如更严格的安全审计、更高级别的资源管控工具），以及原厂的 SLA 服务承诺。
四、 核心解法：资源池化实现“降本增效”
在国产化改造过程中，如果按照“一系统一库”的传统模式1:1部署，硬件和软件授权成本将是天文数字。为了解决预算与需求的矛盾，我们采用了 TiDB 资源池化（多租户） 的解决方案。
分类分级，按需入池
我们没有把所有鸡蛋放在一个篮子里，而是根据业务条线（投研、理财、零售等）和重要程度建立了十几套资源池：
- 高重要性系统： 独享高性能资源池，配置两地三中心或同城双活的高可用架构。
- 中低重要性系统： 如 OA、网管等，合并入综合资源池，通过资源超卖技术最大化利用硬件。
错峰借用，极致压榨性能
利用TiDB的资源管控能力，我们将由于业务特性导致高峰期错开的系统部署在同一个池子里。例如，日间交易系统（9:00-15:00 忙）和晚间跑批系统（夜间忙）部署在一起。系统闲置的资源可以被忙碌的系统“借用”，使得 CPU 利用率从传统的 30%安全线提升到了70%-80%且依然稳定。
成果数据： 通过资源池化建设，相比独立部署模式，我们仅在今年就节省了约 1000 万元的直接资本性支出。
五、 运维进化：从“救火”到“治未病”
引入 TiDB 资源池后，我们面临的新挑战是：几个人如何管理上千套实例？答案是建设全域数据库健康监测与管控平台，实现运维体系的智能化。
事前：资产感知与防御
- 资产动态管理： 我们自研了资产自动识别专利技术，全网扫描服务器，自动发现新增数据库及其主从架构，解决了“不知道家里有多少家底”的痛点。
- 非法连接熔断： 只要有新的 IP 或客户端首次连接数据库，系统会立即通过微信/邮件告警。我们甚至监控“密码错误次数”，第一时间发现暴力破解或撞库行为。
事中：全链路可视化与快速定位
- 业务视角的监控： 我们建立了“功能号-SQL”关联机制。当用户反馈“登录慢”时，运维不再是盲查数据库，而是直接定位到该功能对应的几条 SQL，快速判断是网络问题还是数据库问题。
- 智能根因分析： 结合eBPF技术和相似度算法，我们将故障期间的 CPU/IO 波形与具体 SQL 的资源消耗波形进行比对，直接锁定导致性能突降的“元凶” SQL，让运维人员底气十足。
统一操作平台：消灭“手抖”风险
在多租户环境下，误操作的代价是巨大的。我们构建了统一操作平台，收回了 DBA 的底层权限。
- 防误删机制： 所有的 Delete/Update 操作在执行前，平台会自动将受影响数据备份到中间库。一旦发现误操作，运维人员可以一键生成逆向Insert语句进行回滚，从技术上根除了“删库跑路”的风险。
六、 总结与展望
中泰证券在国产数据库的实践可以概括为八个字：“降本增效，运维提质”。通过 TiDB 资源池化，节省了千万级的硬件与授权成本。 业务系统扩容从“按天”缩短为“即时”，无缝支撑业务波动。将散落在各处的数百套小系统统一纳管，使得边缘系统也能享受到专家级的运维保障，整体故障率大幅下降。
未来，我们将继续深化与平凯数据库以及 TiDB 社区的合作，探索更多基于 AI 的智能运维场景，让数据库不仅是数据的载体，更成为驱动金融科技创新的核心引擎。