营销中心价格表同步实战：从飞书表格到 MySQL 的单一策略落地

这个策略解决什么问题

营销中心价格表常常由业务团队维护在一张在线表格里,每天被多个门店、促销方案引用。一旦人工维护,改价不同步、口径不一致的问题就出来了。这条策略的目标很朴素:每天定时把飞书表格里的价格数据原样落到 MySQL 的营销中心价格表,让下游的门店、促销、报表都从同一张表里取数,避免“多处维护、月底对账”。在客户现场,我们用轻易云数据集成平台(Qeasy)承接这条策略,把它作为后续十余条同步任务的一个稳定起点。

数据流向与字段映射

数据流向是单向的:飞书(B) → MySQL(A),源系统标识为 B,目标系统标识为 A。下面是关键字段的对照关系,实务中我们建议先按这张表对齐口径,再去做配置。

源端走的是飞书开放平台的 /open-apis/sheets/v2/spreadsheets/:spreadsheetToken/values/:range 这个 GET 接口,目标端走 MySQL 的批量执行(batchexecute),本质上是一条带参数的 SQL。字段之间不做复杂转换,价格类字段直接透传,唯一一处加工是物料编码两侧空格用 TRIM 去掉——这是最容易被忽视、也最容易在三个月后让两边数字对不上的细节。

在轻易云上如何配置

源端配置上,把 Feishu 这边的连接器建好,API 选 /open-apis/sheets/v2/spreadsheets/:spreadsheetToken/values/:range,effect 选 QUERY,method 为 GET。两个 query 参数固定写死:valueRenderOption=ToString、dateTimeRenderOption=FormattedString,避免数字被科学计数、日期被转成时间戳。headers_line=1 表示第一行是标题,从第二行起当作数据读取。

目标端配置上,平台选 MySQL,effect 为 EXECUTE,走 batchexecute。每个字段都对应一个 {{变量}} 占位符,物料编码额外包一层 _function TRIM('{{物料编码}}'),这一类轻加工放在轻易云的字段映射里集中维护,是轻易云客户最常见的做法之一——把“清洗逻辑写在哪一行”这个问题统一收口,后续换源、换目标都不至于散落各处。

实施步骤

1. 先把源表结构在 MySQL 里建好。字段、类型、空值策略对齐飞书表格,主键 id 用自增或者雪花都行,但一定要稳定。
2. 手动触发一次全量,验证字段映射与 TRIM 这类加工是否符合预期。建议先在一个测试库跑通,再切到生产。
3. 接入调度,设置增量起点。源端 crontab 设为 0 1 * * *(每天凌晨 1 点拉一次飞书表格),目标端错开 30 分钟,设为 30 1 * * *。错峰的根本原因是不要让源端拉取和目标端写入挤在同一秒,出现并发时容易出现“源端读到旧值、目标端写到新值”的错位。
4. 观察 3 个完整调度周期,核对每天落库条数、行数波动、空值比例,确认没有“某天突然少了一大片”这种断崖式异常。
5. 稳定后再决定是否叠加全量触发。日常靠每日增量,每月或每季度做一次全量比对,这是轻易云客户常用的“增量与全量双轨”模式。

踩坑复盘

• 空格与不可见字符。物料编码从表格复制到 MySQL,两侧空格、空行非常常见。如果不在落库前 TRIM,3 个月后两张表 join 必然丢数据。
• 数字渲染模式。飞书表格里的金额默认可能是带千分位、带币种的字符串,valueRenderOption 一定要固定为 ToString,否则会被识别成科学计数或者时间戳。
• 空值处理。浮点字段在源端是空白时,落到 MySQL 不能直接写 0,要明确是 NULL 还是 0,这个口径最好在配置阶段就锁死。
• 调度不要同秒。源端拉取和目标端写入挤在同一时间点,容易出现“上一次还没写完,下一次又开始读”的重叠。错开 30 分钟是最稳妥的做法。
• 幂等键要稳定。这条策略用 id 做主键,如果未来飞书表格改了 id 规则,整条增量逻辑都会失准,所以 id 规则要在源头固定下来,不要轻易换。

适用场景与不适用场景

适用:源数据由业务团队维护在飞书表格、数据量在万行量级以内、需要每日定时刷新、对实时性要求不高的价格类、基础资料类同步。不适用:数据量极大、需要分钟级实时同步、源端不在飞书表格里、或者字段转换逻辑非常复杂(超过轻易云字段映射所能承载的范围)的场景。