在数字化浪潮的推动下，作为承载民众民生保障的核心部门，各地人社正加速向“人工智能+人社”演进，其对数据底座的稳定性、安全性与协同能力提出了前所未有的严苛要求。

自 2020 年以来，OceanBase 深耕人社领域六载，服务全国 1/3 省级人社关键业务数据库升级建设，目前在人社的落地案例、应用适配、实践经验等均处在国产数据库第一。此外，OceanBase 还支撑人社部的人社大数据平台，构建覆盖就业创业、社会保险、人才人事、劳动关系等全业务领域的“数字大脑”。
本文聚焦上海人社的数智化实践——这是全国第一个完成全栈一体化架构国产升级并成功上线的人社项目；也是全国社保系统第一个数据库上云的项目。
文章经授权转载自微信公众号“中国社会保障杂志”。全文 3261 字，阅读约需7分钟，希望对您有所帮助。

2026年1月8日，上海市人社核心业务系统在OceanBase 海扬数据库上正式上线。对上海市人社部门而言，把民生关键数据整体搬上云端、换上国产分布式数据库底座，这绝非一次普通的升级。

2023年，人力资源和社会保障部印发《数字人社建设行动实施方案》，全面推进数字化改革，推动人社服务从“能办”向“好办、易办”升级。人社核心系统是支撑我国社会保障体系正常运转的“数字心脏”和“神经中枢”，其数据架构升级成为必然选择。而承载着参保登记、缴费核定、待遇申领、社保关系转移等核心业务的数据库，正是这场升级中最难啃的环节之一。据项目方介绍，上海人社项目是全国第一个核心系统全栈国产化的人社项目，国产化范围覆盖中央处理器（CPU）、图形处理器（GPU）等；也是全国第一个完成全栈一体化架构国产升级并成功上线的人社项目；也是全国社保系统第一个数据库上云的项目。

01

一场关于“租户克隆”的选型

上海人社核心库经过20余年积累，数据规模超过60TB，涉及2.6万余张表、4000多个存储过程与函数、近500个视图；数据库既要承接日常高频经办，也要支撑财务批量支付、月度结算等周期性任务，上线后还要持续进行政策调整、应用迭代和数据库变更验证。给这样的系统“换心脏”，难度可想而知。上海此次数据库改造，是在现有全市集中一体化平台的基础上进行的，在保留存量业务逻辑和历史数据的同时，完成传统集中式数据库向国产分布式数据库的升级，并继续具备生产运行、业务验证和版本发布能力。

选型阶段，上海市人社部门先后组织了两轮数据库专项测试，综合比较兼容性、性能、迁移和运维能力。第二轮测试使用完整核心库数据，开展了11个业务场景的验证。最终，OceanBase凭借“租户克隆”能力、高兼容性、高性能、低适配成本等优势胜出。

“租户克隆”为什么如此被看重？它解决的是一个具体问题：政策调整、应用更新或数据库变更，都需要在正式上线前经过验证，而用于验证的数据必须足够接近真实业务。

系统改造前，上海人社采用Oracle（甲骨文）数据库配合H3C存储克隆、快照的方式准备准生产数据库：由存储层提供数据副本，再与Oracle数据库及准生产应用环境配合使用。据上海市数据局相关负责人介绍：“只有具备这样的数据基础，业务人员和技术团队才能在上线前验证真实业务流程、关键结构化查询语言（SQL）、月度处理逻辑以及数据库变更，避免‘小数据量测试发现不了问题’的风险。”

传统测试开发需要做整库复制，复制到新的租户上测试开发，时间长且操作繁琐。OceanBase可以做到秒级克隆租户，在不影响生产库数据的情况下同步进行开发测试。放到上海人社场景，这意味着准生产库可以基于生产库的一致性数据状态准备，减少每次验证重新转储整库的需求。

正是这一能力，让OceanBase在选型中多了一个关键筹码。借助OceanBase的“租户克隆”能力，上海人社“基于生产数据先验证、再上线”的工作方式得以更简便、高效。

02

让数据分布贴合经办业务

数据库是人社核心系统升级中最难的环节之一，它承担着两类不同的工作。一类是日常经办，大量业务请求需要及时返回结果；另一类是社保费征缴、养老金发放、医院和药店的医保实时结算等集中处理任务，这类任务会产生瞬时海量并发请求。这要求数据库必须在短时间内处理数以万计甚至百万计的并发实时交易，并满足数据安全和审计的要求。

上海市人社部门原核心库采用Oracle RAC（高可用性集群解决方案）及高性能全闪存储，已难以承载人社核心业务需求。升级到新的服务器与数据库架构后，数据的存放和处理方式发生了变化。项目没有直接照搬Oracle库表设计，而是让数据的组织方式更贴近实际经办习惯。例如，原系统有些表按年月组织分区，而实际业务查询常围绕参保人员、年龄或业务类型展开。当查询条件与分区规则不匹配时，可能扫描多个无关分区。因此，项目针对过亿大表重新制定分区规范，由技术团队与业务人员共同确认分区键，并配合复合主键和路由策略调整，让高频查询更早定位所需数据。

表与表之间的关联关系也在“搬家”中重置，经常一起使用的数据被重新合理安排。项目利用数据库重放功能记录改造前的生产负载，通过自研程序分析表之间的关联关系，将生产表组织为四个表组，改善关联数据的物理分布，为分区级关联创造条件，缓解跨节点关联带来的性能影响。例如，对“查询某个人最后一条记录”这类高频场景，项目采用窗口函数等方式，改写原有的多次扫描逻辑；对批量任务，调整子查询、关联方式和索引；针对执行计划跳变、隐式类型转换等问题，把经过验证的执行计划固定下来，并将开发规范前置到表结构和SQL设计阶段。“先减少不必要的数据访问，再谈资源调配。日常业务并发量和批量SQL并行度需要共同规划，SQL治理不能靠无限增加并行度来替代。”上海市数据局相关负责人表示，此类优化与“提高并行度”并不是同一件事。

据项目技术总结，搭载OceanBase分布式数据库的新系统稳定承载日均交易约20万笔，在业务交易笔数、数据库峰值最大并发时仍稳定运行。目前已统计的高频经办接口平均响应时间不超过1秒，达到秒级响应；月结耗时为原环境的100%至125%，周期任务均能完成。

03

60TB“家底”的搬家与瘦身

数据库迁移是一项细致的工作。除了搬迁表中的数据，还需要让承载业务规则的程序、数据约束和其他数据库对象，在新环境中继续有效运行。数据有没有遗漏、金额是否一致、业务计算结果是否正确，都需要逐项确认。

上海人社数据库迁移不仅包括表数据，还包含存储过程、函数、视图、序列、约束及其他对象。

据了解，该项目先梳理仍在使用的业务数据、历史静态数据和已经停用的数据，明确需要迁移的范围。历史静态数据提前迁移，能够提前完成的适配工作尽量放到正式切换之前。针对迁移速度，团队根据数据表大小配置不同并发度，并结合链路带宽、迁移主机资源和报错表清单持续调整。最终，通过任务拆分、资源优化和反复演练纠正问题，提升迁移效率。

上海市数据局相关负责人介绍：“判断迁移成功不能只看任务‘完成’。迁移完成后，仍要进行多层核验。项目对所有表进行记录数比对，对核心表关键数值字段进行累加校验，重点验证金额准确性；对业务核心表开展逐行逐字段核对。”与此同时，还要检查表结构、过程与函数有效性、约束、序列以及触发器逻辑，避免出现“行数相同但业务结果不同”的情况。

得益于OceanBase高兼容Oracle，其在数据类型、PL/SQL（过程化拓展）存储过程、系统包、优化器等方面做到了高度对齐。项目组每轮迁移不仅记录转储耗时，也修正语法适配、异常数据、任务拆分和验证问题，形成能够重复执行的步骤。最终，总迁移时间由72小时优化至36小时；核心数据库数据转储优化后控制在15小时以内；整体系统切换用时7天，包含切换、准生产验证及生产试运行。

历史数据的“瘦身”同样精彩。数据搬迁之外，长期存储也是项目需要解决的问题。上海人社核心库数据规模已超过60TB，每年新增约10TB，历史记录留存、数据增长和多套验证环境会带来持续的容量压力。项目利用OceanBase数据库的编码与压缩能力，在保留业务数据及正常访问能力的前提下，显著降低了数据存储占用。据目前统计，压缩后的数据占用约9TB，约为压缩前的六分之一到七分之一。这一效果既满足了人社历史数据长期留存和查询的需要，也为后续新增数据释放了容量空间，缓解了数据持续积累带来的存储扩容压力。

上线至今，OceanBase在上海人社核心系统中稳定运行。回看这一项目，OceanBase承接核心交易数据库，通过租户克隆准备准生产数据库；通过分区、表组和SQL优化支撑日常经办与周期任务；作为Oracle升级的目标数据库，高兼容让存量库平滑升级；编码与压缩则提供了长期容量管理的技术能力。对人社业务来说，这些能力最终对应的是业务能继续运行、历史数据能准确承接、变更上线前有环境可验证，以及长期数据增长有办法管理。

从“能办”到“好办、易办”，智慧人社建设需要稳定、弹性、可持续演进的数据底座。上海人社核心系统的落地说明：核心系统国产升级的关键，不只是数据库产品本身，更是迁移方法、验证体系、运维能力和业务理解的共同支撑。目前，OceanBase已在人社领域服务全国三分之一的省级行政区。上海市人社部门的实践，为这一名单增添了核心系统全栈国产的新注脚，也为正在推进升级改造的省市和计划上线的业务系统，提供了一个可观察、可复盘的现实样本。

大会预告

立即试用 OceanBase 企业版，体验国产数据库能力 立即试用 OceanBase 企业版，体验国产数据库能力