我复现一下上面的操作说 zq-platform初始数据写不到数据库

第一次执行

alembic revision --autogenerate -m "init tables"

报错

INFO  [
            alembic.runtime.migration]
           Context impl PostgresqlImpl.INFO  [
            alembic.runtime.migration]
           Will assume transactional DDL.ERROR [
            alembic.util.messaging]
           Target database is not up to date.FAILED: Target database is not up to date.

意思是：你的数据库当前版本 (current) 落后于 Alembic 迁移脚本所定义的最新版本 (head) cnblogs.com+1。这就好比你手里拿着的是第3版的说明书，但产品已经更新到第5版了

要解决这个问题，核心思路就是将数据库的当前版本 (current) 更新到与最新的迁移脚本版本 (head) 一致。

1.查看当前数据库状态：首先，确认一下版本差异。在项目根目录下打开终端，依次运行：

    # 查看数据库当前记录的版本    alembic current    # 查看所有可用的迁移脚本版本（head）    alembic heads

你通常会看到 current 的版本号比 heads 的版本号要旧，或者 heads 显示了多个分支（这通常意味着存在多个分支迁移需要合并）。

分别显示

INFO  [
            alembic.runtime.migration]
           Context impl PostgresqlImpl.INFO  [
            alembic.runtime.migration]
           Will assume transactional DDL.

这证实了问题所在：数据库当前停留在一个空版本，并没有处于最新状态，所以 Alembic 拒绝你生成新的迁移脚本。

请直接运行下面这条命令来解决这个问题：

alembic upgrade head

这个命令会扫描 alembic/versions 文件夹，找到所有脚本，并依次在数据库中执行它们。

执行结果：

INFO  [
            alembic.runtime.migration]
           Context impl PostgresqlImpl.INFO  [
            alembic.runtime.migration]
           Will assume transactional DDL.INFO  [
            alembic.runtime.migration]
           Running upgrade  -> b6a31168d666, init tablesINFO  [
            alembic.runtime.migration]
           Running upgrade b6a31168d666 -> a79453452d83, add page design

数据库已经成功升级到最新版本了。从输出 Running upgrade b6a31168d666 -> a79453452d83 可以看到：数据库已经更新到了 a79453452d83，

打开数据库可以看到当前版本号：

重新生成迁移：现在可以再次尝试运行 alembic revision --autogenerate -m “init tables”。

alembic revision --autogenerate -m "init tables"

显示结果：

INFO  [
            alembic.runtime.migration]
           Context impl PostgresqlImpl.INFO  [
            alembic.runtime.migration]
           Will assume transactional DDL.Generating F:\下载程序与源码\★★★可执行项目收集★★★\zq-platform\backend-fastapi\alembic\versions\588
            bd64ec92e_init_tables.py
           ...  done

输出显示：Generating ... 588bd64ec92e\_init\_tables.py ... done

这表示 Alembic 成功扫描了你的代码和数据库，并发现它们之间的差异，自动生成了一个新的迁移脚本文件： 588bd64ec92e\_init\_tables.py。

接下来的步骤：让修改生效

现在脚本文件只是生成了，但数据库里的表结构还没变。你需要执行最后一步：

1. 查看生成的脚本（可选，但推荐）

你可以打开 alembic\versions\ 9abfcdbaff03\_init\_tables.py 看一眼。检查 upgrade() 函数里是否包含了 op.create\_table(…) 等语句。如果那里是空的，说明 Alembic 没检测到你的模型变化，或者模型没有被正确导入。

2. 更新数据库（必须执行）

在终端运行：

alembic upgrade head

这将会把刚才生成的脚本应用到你的 fastapi\_db 数据库中，创建对应的表结构。

显示

INFO  [
            alembic.runtime.migration]
           Context impl PostgresqlImpl.INFO  [
            alembic.runtime.migration]
           Will assume transactional DDL.INFO  [
            alembic.runtime.migration]
           Running upgrade a79453452d83 -> 588bd64ec92e, init tables

数据库迁移已经完全成功了！🎉

从输出 Running upgrade a79453452d83 -> 588bd64ec92e 可以确认：

你的 fastapi\_db 数据库已经成功应用了 init tables 脚本，所有定义的表结构现在都已经真实存在于数据库中了。

验证成果

如果你想确认表真的创建好了，可以：

1.打开 pgAdmin（如果你安装了的话）。

2.连接到 fastapi\_db。

3.展开 Schemas -> public -> Tables。

4.你应该能看到刚才定义的所有数据表（比如 users 等）。

或者，你可以直接在 Python 代码中试着向数据库写入一条数据，看是否报错。

再执行python scripts/ loaddata.py db\_init.json，导入数据，看到

导入完成:  成功: 38 条  失败: 0 条

先不要激动！！！日志最后一句“导入完成: 成功 38 条 / 失败 0 条”是脚本自己打印的统计，并不真实——

只要发生 ROLLBACK，整个事务就被回滚，数据库里一条新数据也没有写进去。

真正的失败原因就是这一条：

            asyncpg.exceptions.DataError:
            invalid input for query argument $4: '2026-01-11T19:44:39.752685'  (expected a 
            datetime.date
           or 
            datetime.datetime
           instance, got 'str')

也就是 core\_user.last\_login 字段传的是 字符串，而数据库列类型是 timestamp without time zone，异步驱动 asyncpg 不接受字符串隐式转换。

如何修复

def parse_datetime(value):    """解析日期时间字符串"""    if isinstance(value, str):        # 尝试多种日期时间格式        formats = [            "%Y-%m-%dT%H:%M:%S.%f",  # ISO 格式带微秒            "%Y-%m-%dT%H:%M:%S",      # ISO 格式不带微秒            "%Y-%m-%d %H:%M:%S.%f",   # 带微秒的空格分隔格式            "%Y-%m-%d %H:%M:%S",      # 不带微秒的空格分隔格式            "%Y-%m-%d",               # 仅日期格式        ]                for fmt in formats:            try:                return 
            datetime.strptime(value,
           fmt)            except ValueError:                continue                # 如果以上格式都不匹配，尝试 fromisoformat        try:            return 
            datetime.fromisoformat(value.replace(
          "Z", "+00:00"))        except ValueError:            pass                # 如果所有尝试都失败，返回原始值        return value    return value    ......    # 转换日期时间字段                for key, value in 
            fields.items():
                              if isinstance(value, str):                        # 检查是否为日期时间格式的字符串                        parsed_value = parse_datetime(value)                        # 如果成功解析且返回的是 datetime 对象，则替换原值                        if isinstance(parsed_value, datetime):                            fields[key] = parsed_value

再执行python scripts/ loaddata.py db\_init.json，直至这些数据都导入完成。

当看到

从文件导入数据: 
            db_init.json
          读取到 38 条记录2026-01-20 17:07:52,224 INFO 
            sqlalchemy.engine.Engine
           select 
            pg_catalog.version()
          2026-01-20 17:07:52,225 INFO 
            sqlalchemy.engine.Engine
           [raw sql] ()......2026-01-20 17:07:52,276 INFO 
            sqlalchemy.engine.Engine
           COMMIT导入完成:  成功: 38 条  失败: 0 条

·脚本成功读取了 db\_init.json 文件，识别出包含 38 条待导入的记录

·SQLAlchemy 引擎成功连接到 PostgreSQL 数据库（日志中出现 pg\_catalog.version() 是 PostgreSQL 特有的查询）

数据库验证

出现账号数据即为数据导入成功。

启动服务

python main.py或使用 uvicornuvicorn main:app --reload --host 0.0.0.0 --port 8000

这样初始数据写不到数据库问题就可以得到根本解决。

作者：张红霞，青岛雨诺网络信息股份有限公司新零售产品部总监

综述

当前，医药零售企业已不再满足于“卖药”，而是致力于成为“健康管理伙伴”。通过构建以 CRM 会员系统为核心、线上与线下深度融合的全渠道服务架构，企业实现了服务时间与空间的无限延展、会员数据的集中管理与智能应用、营销活动的精准触达与高效转化。

作为医药零售的头部企业，重庆医药（集团）股份有限公司（简称“重药集团”）前身是成立于1950年的中国医药公司西南区公司，服务于医药全产业链，同时从事医药研发（MAH）、医疗器械生产，并投资参与医药工业。重药集团拥有全级次分、子公司200余家，正在从传统的配送商业企业向“互联网+医药”融合型现代医药企业转型。

随着CRM会员系统的使用时间拉长，其底层的传统数据库逐渐难以满足复杂数据的高效处理需求。面对海量交易和多维度行为数据的汇聚，重药集团CRM会员系统亟需采用具备高可用、强一致、可扩展特性的数据库。经过对比三款国产分布式数据库，重药集团选择OceanBase，最终实现系统稳定运行、复杂场景实时分析、查询效率提升25倍、存储空间节约60%。

此次重药集团CRM系统的数据库升级不仅提升了用户体验与品牌忠诚度，也为后续集团构建高性能、高可用的“集团级数字化运营中枢”提供了明确的业务需求与数据基础，构建可扩展、可复制、可监管的集团化运营体系。

医药零售商业模式变革，CRM系统实现全渠道协同

随着消费者行为的数字化转型和健康需求的持续升级，医药零售行业正经历深刻的商业模式变革。传统药店“有啥卖啥”的经营逻辑，逐步向“顾客需要什么”的逻辑转变，除了提供到店服务外，还支持线上服务，比如通过企业微信、公众号等渠道建立长期沟通机制。微商城代客下单、在线解答疑问等。

为构建以专业化服务为基础的顾客信任体系，医药企业建立了完整的会员服务体系——CRM 会员系统，以实现绑定多重会员信息、建立精准的会员标签画像，为会员提供更多的服务和营销。通过数据驱动决策的专业化服务能力提升来提高企业在行业内的竞争力，实现增收。

如图1 所示，CRM 会员系统可以实现线上、线下全渠道协同，支持会员档案统一、标签体系完善、自动触发机制、店员触达赋能、社群营销等关键功能。完成顾客到店/线上购药 → 完成交易 → 数据沉淀至 CRM → 触发服务与营销 → 二次消费 → 再次触达，实现“交易—服务—再交易”的正向循环。

图1 CRM会员系统实现线上、线下全渠道协同

为实现一体化管理需求，构建CRM会员系统

重药集团CRM会员系统的搭建背景，源自于其各子公司会员管理分散，系统缺乏统一规划，导致数据难沉淀、服务差异大、运营难复制，且缺乏实时监控，难以支撑决策。

为实现一体化管理，重药集团CRM会员系统分阶段建设。第一阶段完成会员营销平台的底座建设，打造集团化、标准化、数据化运营基础，核心目标如下。

• 搭建集团化会员运营平台。现集团—子公司—门店的一体化管理，打通组织架构与业务链路，确保会员在不同层级和渠道中都能获得一致的服务体验。
• 统一的会员运营服务体系。构建覆盖会员管理、营销活动、服务交付的标准化流程，减少分散运作带来的效率损耗，提升整体运营协同能力。
• 可快速复制标准化服务能力。形成可落地的服务模板和运营机制，帮助新业务和子公司快速复制成熟经验，缩短建设周期，提升推广效率。
• 实现经营数据统一分析。沉淀完整的数据资产，打破信息孤岛，实现对会员、门店、区域的多维度统一分析，为企业战略决策与合规审计提供有力支撑。

在上述目标指导下，我们做了三个核心举措：

• 联合集团会员中心，推进一体化进程。覆盖集团全品牌及线上会员，实现线上和线下会员统一运营和全域价值管理（见图2）。
• 构建多层级组织架构视角报表。支持集团、品牌、门店的权限管理，权限灵活配置，便于集团总部进行跨品牌的数据报表分析。
• 集团统一下达任务。集团可向各品牌下发销售任务、患者教育活动任务及拉新任务，实现集团任务统一管理与执行监督。

图2 集团会员同意运营架构

我们计划以集团内个别区域公司为试点，试行以上举措，若成功，则进行全面推广。推广成功后，重药集团会员运营平台将实现从“单一业务系统”向“集团级数字化运营中枢”演进。依托统一的技术底座与标准化流程，平台不仅实现对多家子公司、多个品牌的全面接入，更构建起可扩展、可复制、可监管的集团化运营体系。

此外，为实现全渠道会员统一运营，平台通过整合分散在各系统中的数据，构建统一、动态、多维度的会员标签画像体系（见图3），支撑精细化运营决策。

图3 多维度会员标签画像体系

通过会员系统精准化的服务来反哺我们的线上和线下的会员营销和服务，实现线上精准营销、个性化推荐、好物推送、会员关怀，线下关联用药建议、慢病管理提醒、店员主动触达等，提升营销转化率，增强客户粘性，实现“数据驱动服务”的闭环。

精细化会员服务，带来海量数据的查询、存储难题

然而，随着集团化会员运营平台的推进，精细化服务模式持续深化，导致用户数据规模呈指数级增长，显著提升了系统的查询与存储复杂性。

• 会员量：突破千万级，覆盖多个品牌及区域公司。
• 交易数据量：达到亿级，涵盖线上线下购药、用券、复购等行为。
• 用户行为类数据：包括商品浏览、搜索、加购等，总量亦达千万级以上。

这些数据来源于线上商城、私域平台、公众号等多个渠道，经标签体系整合后，用于构建立体化的会员画像，支撑精准营销与双向引流。

但数据体量大、类型多样、实时性要求高，对数据库的高并发读写能力、存储扩展性与查询性能提出严峻考验。面对千万级会员、亿级交易和多维度行为数据的汇聚，传统数据库难以满足高效处理需求，亟需采用具备高可用、强一致、可扩展特性的分布式数据库系统进行支撑。

CRM会员系统数据库升级，应对千万级数据处理难题

传统数据库的技术瓶颈制约业务发展

重药集团会员服务平台的规模化发展，使系统数据总量迅速增长至千万级、数十 TB 存储规模，传统关系型数据库在支撑精细化会员运营场景时，暴露出四大核心挑战。

• 性能：百万大表 InnoDB 在高并发读写及复杂查询场景下，性能显著下降，无法满足业务需求，且有事务访问，无法通过拆分提升性能。同时，业务强依赖事务一致性，无法通过拆分提升性能。
• 效率：核心归档由于业务需求，需要保留大量数据（数十 TB），会造成 DDL 周期长，延迟业务上线时间。
• 成本：随着企业数量增多、历年数据累积，存储成本将越来越高。
• 及时性：在各种场景下，对应数据处理的及时性需求越来越强。

上述技术挑战不乏真实业务案例。

例 1：某大型连锁店，以满足信创要求为前提进行性能保障

如今国家对信息技术应用创新（简称“信创”）的要求日益严格，特别是在国有企业中，系统必须符合相关标准才能上线。为了响应这一趋势，我们严格按照信创目录选择数据库产品，并对其进行了全面的业务场景适配与性能验证。

• 数据准备：会员卡 9950万+、订单 1 亿 9980万+。
• 验证数据库：OceanBase 数据库、某数据库1、某数据库2。
• 验证功能：报表 14 项内容、高级筛选 8 项内容。
• 参考标准：报表查询小于 20s、静态化数据小于 60s、高级筛选小于 15s。

测试结果如图4所示。OceanBase 在所有测试项中均显著优于其他两个国产数据库，在报表查询、高级筛选、静态化数据三个场景的性能表现都远超预期：

• 报表查询小于 7s，平均提速 78 倍以上。
• 高级筛选响应高级筛选小于 1s，速度提升 200–700 倍。
• 静态化数据静态化数据小于 46s，效率提升 6.7 倍以上。

图4 OceanBase 数据库、某数据库1、某数据库2的测试结果

在严格遵循国家信创要求的前提下，OceanBase 不仅完全满足合规性准入条件，更在百亿级数据规模下的复杂查询与批量处理场景中展现出卓越性能，远超同类国产数据库产品。基于此，我们总结了三个数据库的性能数据，向客户提交了一份详细的分析报告。

例 2：连锁会员、订单交易数据量增长迅速，实时性查询瓶颈

除了信创需求外，客户对业务的实时性、及时性要求也越来越高。过去，企业主要依赖 BI 工具进行周期性报表生成，可容忍数小时甚至数天的数据延迟。然而，随着营销策略向精准触达和即时响应演进，业务人员需要在高价值客户识别、复购提醒触发、定向营销投放、健康知识推荐等场景中获取近实时数据支持。为实现精准服务，运营人员经常需要基于会员信息、会员属性、历史消费、会员标签、商品集合等多个维度进行多维组合筛选，由于关联维度过多，可能会出现查询失败、查询时间过长、范围跨度受限、复杂查询无法支持等问题，显然，这些问题是我们服务的客户无法接受的。

例 3：海量业务数据，系统可用性与存储成本难平衡

连锁医药企业会员体系的不断扩展和数字化运营的深入，必然会带来业务数据量的指数级增长，海量数据带来的高存储成本成为制约系统可持续发展的关键瓶颈之一。

• 用户数据：累计会员数量突破千万级（>1000万）。
• 交易流水：日均订单量达百万级，历史累计超过亿级（>1亿条）。
• 用户行为数据：包括浏览、搜索、加购、收藏等行为记录，总量亦达千万级以上。

单个业务数据库实例空间占用已达到 N 个 TB 级别，且随时间推移呈线性增长。随着客户数量增加和业务持续扩张，业务数据库实例的空间占用迅速攀升至数十TB甚至上百TB级别，这些数据不仅用于支撑日常业务运行，还需长期保留以满足合规审计、精准营销、客户画像构建等需求。企业面临保障性能与可用性的前提下降低存储成本的难题。

因此，引入具备高效数据压缩、自动冷热分层、弹性扩展能力的新一代分布式数据库，是实现“数据价值最大化、存储成本最小化”的必然选择。

数据库技术引入，支撑海量交易数据的高效处理

综合业务需求与传统数据库的技术瓶颈考虑，我们需要替换传统数据库，升级为高性能、稳定性强、成本低、 HTAP 一体化的分布式数据库。

自 2023 年起，我们开始系统性地评估并引入 OceanBase，历经技术认知、多轮测试、工具链验证、SaaS 级试点上线等关键阶段（见图5），最终成功应用于重药集团会员管理平台。

图5 上线OceanBase的关键阶段

1.技术引入与评估阶段（2023年）

测试重点包括三部分。

其一，日常抖动测试。在对 OceanBase 初期测试时，我们首先进行了业务压力测试。低峰期业务配合100%模拟线上流量直接发压，高达4轮的压力测试，每次持续 3 小时以上。

其二，扩容/缩容测试。在业务流量低时进行相关操作验证。为了验证是否存在小概率事件，进行了为期一周的脚本自动扩、缩容操作以观察其稳定性。

其三，Add Index 测试。与扩容、缩容相仿，基于业务流量对1T大表进行多达几十次的add index操作，观察延迟情况。

2.SaaS 产品试点上线（2023 年 12 月）

在完成全面技术验证后，我司将 OceanBase 应用于内部 SaaS 类产品中，作为首个生产级试点场景。该阶段实现了：

• 数据库稳定运行于真实业务环境中。
• 验证了迁移、运维、监控等全生命周期管理能力。
• 积累了宝贵的实战经验，为后续客户项目打下坚实基础。

3.重药集团项目正式上线（2025 年 4 月）

基于前期充分验证与试点成果，我们于 2025 年 4 月正式启动重药集团会员管理平台项目，OceanBase 正式投入生产使用，支撑海量交易数据的高效处理。

会员服务平台“新面貌”：稳定、高性能、低成本

构建标准化数据链路，稳定、高效处理海量数据

目前，OceanBase 主要支撑重药集团会员服务平台的分析型业务场景，支撑高并发、多维度的会员数据查询、标签计算、报表生成及精准营销决策。其核心价值体现在：高效处理海量历史数据、支持复杂实时分析、保障查询性能与系统稳定性。

整个数据链路遵循“源系统 → CRM 中转清洗 → OceanBase 分析库”的三层架构，如图6所示。

图6 会员服务平台的数据分析链路

数据来源（源系统）包括POS 订单数据、各渠道会员信息、组织人员数据、会员标签数据、档案测量数据、全部商品主数据。

• 中转与清洗层（CRM 系统）：所有原始数据通过定时抽取或实时接入方式进入 CRM 系统，进行统一的数据清洗、去重、合并与标准化处理。关键处理策略包括历史数据清洗、订单数据合并、积分逻辑处理、会员标签动态更新、消费行为计算、活跃度模型计算。
• 目标存储与分析层（OceanBase 分析库）：清洗后的数据通过同步机制实时或定时写入 OceanBase 分析库；并分为原始数据表、静态化处理表、日表/月表、报表中间表。

通过构建“源数据 → CRM 清洗 → OceanBase 分析库”的标准化数据链路，实现了多源异构数据的统一整合、复杂分析场景的高性能响应、业务数据的长期留存与高效利用。

会员精准筛选复杂场景，查询效率提升 25.7 倍

在重药集团会员服务平台的实际运营中，多维度组合筛选（见图7）是支撑精细化营销与客户管理的核心功能。对于数据库而言，该功能是典型的复杂查询场景，用户需同时基于多个维度进行精确匹配，查询通常涉及多表关联、大量过滤条件和聚合计算，非常考验数据库的执行效率。我们通过开启 OceanBase 的列存模式（Columnar Storage），将原本传统数据库MySQL 的响应时间从 18 秒缩短至 0.7 秒，性能提升达 25.7 倍，满足业务对“实时圈选、即时触达”的严苛需求，显著提升了系统整体吞吐量与用户体验。

图7 会员服务平台多维度组合筛选

数据存储空间省 60%，有效降低存储成本压力

OceanBase 将全量数据划分为两个部分进行管理：一是增量数据（Memtable），即实时写入内存中的热数据，支持快速读写；二是基线数据（静态数据），即经过合并与持久化后的冷数据，存储于磁盘。

对于静态数据，OceanBase 采用高效的压缩算法，对列式存储的数据进行深度压缩，显著减少磁盘 I/O 和存储开销。例如，当原始数据总量为 4TB 时，MySQL 需要完整保留所有数据，存储空间占用为 4TB；而 OceanBase 通过对静态数据进行高压缩处理，仅需 1.5TB 即可承载相同规模的数据。

在重药集团会员服务平台的实际部署中，OceanBase 通过其先进的列式存储引擎与高效压缩算法，显著降低了数据存储空间占用，在同等业务数据规模下实现了 60% 以上的存储空间节约，有效缓解了海量数据带来的存储成本压力。

面向未来，持续推进 OceanBase 的深度集成与价值释放

随着 OceanBase 在重药集团会员服务平台的成功落地，我们对其在更广泛业务领域和客户群体中的应用充满信心。面向 2026 年及未来，我们将围绕场景拓展、客户推广、技术融合与产品适配四大方向，持续推进 OceanBase 的深度集成与价值释放。

应用于更多业务场景与产品

当前，OceanBase 已稳定支撑重药集团会员管理平台的复杂分析型业务（如精准筛选、标签计算、报表生成）。订单处理中心和运营诊断产品也在生产环境开始使用OceanBase，下一步，我们将推动其全面融入日常运营服务场景，包括：实时会员服务、营销活动执行、AI 智能推荐等业务场景。

另外，我们将逐步将 OceanBase 适配至更多内部产品，包括商品主数据管理、患者健康管理平台、智能补货与供应链协同系统，构建以 OceanBase 为核心的统一、弹性、智能的企业级数据基础设施。

向业内客户推荐

在国家信创政策与企业降本增效双重驱动下，我们已将 OceanBase 作为高并发、大数据量、强一致性要求场景下的首选数据库，并向行业客户积极推广。截至目前，已在以下大型医药企业成功落地：扬子江药业集团、鹭燕医学、重药集团、上海医药、国大药房。未来，我们将继续优先推荐 OceanBase 作为会员服务、订单中心等关键系统的数据库底座，助力更多企业完成安全、高效、低成本的国产化替代。

交流开发，沉淀运维经验

为持续提升团队与客户的 OceanBase 应用能力，我们计划定期组织专题培训、参与社区技术沙龙、共建问题解决机制、定期组织数据库培训及实战分享会议，探讨并解决遇到的问题，争取打造一支“懂业务、精技术、能落地”的复合型数据库应用团队。

未来，我们将携手更多合作伙伴，共同探索“数据库 + AI + 行业场景”的创新路径，为医药健康行业的高质量发展注入新动能。