1. 数据模型设计与需求分析
1.1 关键实体与关系
在点餐系统中实现营销活动管理，数据模型的清晰度决定了后续落地的效率。核心实体通常包括 Campaign（活动）、Promotion（促销规则）、Rule（触发条件与约束）、Customer（顾客）、Order（订单）、MenuItem（菜品项）。这些实体之间通过外键和桥表建立联系，以支持多场景的组合与复用。通过将营销维度与点餐场景绑定，后续在桌头、外卖、APP等渠道的促销落地就能实现一致性。
为了实现灵活的组合与快速迭代，需将数据模型设计为可扩展结构：活动对象（Target）、优惠类型（DiscountType）、适用范围（Scope）等分离，确保后续增加新类型、新渠道时不需要大规模修改表结构。这样的设计还便于进行数据建模阶段的测试和回放。
在实际落地前，应明确哪些信息需要长期保存，以及哪些信息可以按周期归档。对于营销活动，历史记录和审计痕迹是关键：谁创建、何时修改、哪些订单触发、触发条件是否达成等，都需要可索引和可追溯。
-- 数据模型雏形（DDL 示例，便于理解核心字段关系）
CREATE TABLE campaigns (
campaign_id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100) NOT NULL,
type ENUM('discount','bundle','free_item') NOT NULL,
status ENUM('draft','active','paused','ended') NOT NULL,
start_time DATETIME NOT NULL,
end_time DATETIME,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
CREATE TABLE promotion_rules (
rule_id BIGINT PRIMARY KEY AUTO_INCREMENT,
campaign_id BIGINT NOT NULL,
rule_type ENUM('order_amount','item_count','shipping','time_window') NOT NULL,
rule_value DECIMAL(10,2),
constraint_value VARCHAR(255),
FOREIGN KEY (campaign_id) REFERENCES campaigns(campaign_id)
);
CREATE TABLE targets (
target_id BIGINT PRIMARY KEY AUTO_INCREMENT,
campaign_id BIGINT NOT NULL,
target_type ENUM('customer_group','loyalty_member','new_customer') NOT NULL,
target_value VARCHAR(255),
FOREIGN KEY (campaign_id) REFERENCES campaigns(campaign_id)
);
CREATE TABLE orders (
order_id BIGINT PRIMARY KEY AUTO_INCREMENT,
customer_id BIGINT,
total_amount DECIMAL(10,2),
order_time DATETIME,
campaign_id BIGINT DEFAULT NULL,
discount_amount DECIMAL(10,2) DEFAULT 0,
FOREIGN KEY (campaign_id) REFERENCES campaigns(campaign_id)
);
CREATE TABLE menu_items (
item_id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100),
price DECIMAL(10,2)
);
CREATE TABLE order_items (
order_item_id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_id BIGINT,
item_id BIGINT,
quantity INT,
price DECIMAL(10,2),
FOREIGN KEY (order_id) REFERENCES orders(order_id),
FOREIGN KEY (item_id) REFERENCES menu_items(item_id)
);
1.2 数据表结构的初步设计
第一阶段要点在于确定可扩展的字段结构，如将优惠规则、目标人群、以及执行渠道通过独立表进行管理。这样不仅方便未来扩展新类型的活动，也有利于对接多渠道的营销落地逻辑。初步设计中应包含活动的生命周期字段、时间点控制、以及执行状态的追踪信息。
此外，索引策略与约束设计要提早考虑：对 campaign_id、status、start_time、end_time 的范围查询需要高效；对 orders 的 campaign_id、order_time、total_amount 的聚合和筛选应具备良好性能。通过设计正确的外键与联合唯一键，可以避免重复执行、确保数据一致性。
落地时需要对接前端的展示数据结构，例如活动名称、优惠额度、有效期、以及已参与的订单数量。此时，视图（VIEW）和存储过程（PROCEDURE）可以用来快速组装需要的报表数据集，避免在应用层进行复杂 join 运算。
2. 营销活动场景设计与数据流
2.1 触发条件与执行路径
营销活动的核心在于触发事件与执行路径的设计。常见触发包括下单金额达到阈值、购买某类菜品、参与过推广活动、生日/纪念日等。为确保执行路径可追踪，应将触发事件与活动规则进行分离：事件表、规则表、执行队列分别负责不同阶段的职责。
在数据流方面，建议建立一个事件总线：事件产生 → 事件持久化 → 规则引擎判定 → 营销落地。当达到触发条件时，系统将相应的促销逻辑写入待执行队列，并在订单阶段或结账阶段对订单进行抵扣或赠品处理。
在高并发的点餐场景中，确保幂等性尤为关键。可以使用 订单条目级别的幂等键，以及对 campaigns 表与 promotions 表的状态进行严格检查，避免同一订单重复触发同一活动的情况。
-- 示例：触发条件表（简化版）
CREATE TABLE event_triggers (
trigger_id BIGINT PRIMARY KEY AUTO_INCREMENT,
campaign_id BIGINT NOT NULL,
event_type ENUM('order_placed','order_completed','birthday','item_purchased') NOT NULL,
min_value DECIMAL(10,2) NULL, -- 如总金额阈值
item_id BIGINT NULL, -- 如指定菜品
FOREIGN KEY (campaign_id) REFERENCES campaigns(campaign_id)
);
-- 示例：简单触发判定存储过程（伪代码/简化）
DELIMITER $$
CREATE PROCEDURE apply_campaign_if_eligible(IN p_order_id BIGINT)
BEGIN
-- 伪代码：读取订单信息、订单总额、已触发的 campaign
-- 判断是否存在可用活动及是否已触发，若符合则写入 order.campaign_id 与 discount
END $$
DELIMITER ;
2.2 营销渠道与落地策略
营销活动的落地渠道应覆盖餐厅内部与外部的主要触达路径，如桌头点餐屏、外卖端、公众号、小程序等。渠道对照表和落地策略表应确保各渠道的参数化管理，避免重复配置。通过统一的渠道通道，可以实现同一活动在不同入口的一致体验。
在设计时，需要将渠道参数与活动规则解耦，例如折扣金额、折扣比例、赠品组合、发放条件等可以通过 promotions、promotion_rules 的组合实现。这样在新增渠道时，只需在通道表中增加条目，而不需要回改核心规则逻辑。
落地的技术要点包括：消息推送的幂等、渠道可观测性（traceId、cta 点击率）以及预算约束，以保证营销活动在多渠道环境下的稳定执行。
3. 在 MySQL 上实现的营销活动管理功能
3.1 数据写入与状态管理
数据写入阶段要确保活动的创建、修改、上线等操作具备一致性。使用事务、状态字段和历史表，可以在活动转为上线前进行验证，确保 start_time、end_time、budget、 eligibility 等均符合预设规则。
在落地层面，状态转换通常涉及多表更新： campaigns、promotion_rules、targets、以及与订单的交互。通过存储过程封装状态变更逻辑，可以统一处理异常情况、回滚并记录日志。
以下示例演示一个简单的上线流程：创建成功后将状态改为 active，并准备触发条件。
-- 将一个已有的 campaign 从 draft 改为 active 的伪代码逻辑
START TRANSACTION;
UPDATE campaigns
SET status = 'active', start_time = NOW()
WHERE campaign_id = 123 AND status = 'draft';
-- 同步相关规则及目标的校验
UPDATE promotion_rules SET ensured = 1 WHERE campaign_id = 123;
UPDATE targets SET ensured = 1 WHERE campaign_id = 123;
COMMIT;
3.2 订单层面的应用与落地逻辑
在订单完成阶段，将活动的抵扣、赠品、组合优惠写回订单记录，实现对用户的可观测效益验证。系统需要支持对单笔订单的多重促销叠加、以及叠加限额的合理控制。
为了确保埋点数据的一致性，建议把订单维度的促销信息与主表分离，通过 order_campaigns、order_discounts 关联表记录实际落地的促销明细，并在结账时对抵扣金额进行验证。
下面给出一个简化的 applying 逻辑示例：将可用的活动应用到订单并更新抵扣金额。
-- 将合适的 campaign 应用于订单（简化示例）
UPDATE orders o
JOIN campaigns c ON c.campaign_id = o.campaign_id
SET o.discount_amount = o.discount_amount + 5.00
WHERE o.order_id = 555 AND c.status = 'active'
AND c.start_time <= NOW() AND c.end_time >= NOW();
4. 报表与监控：营销效果指标在点餐系统中的实现
4.1 指标设计与SQL聚合
有效的营销报表通常包含参与率、客单价变化、ROI、 redemption_rate、以及不同菜品维度的促销效果。为实现可追踪的指标，需要在数据层面建立清晰的聚合口径：定义参与人群、触达渠道、触发条件、执行结果，并通过可重复的 SQL 脚本输出稳定的 KPI。
在设计指标时，应考虑时序聚合以支持日、周、月粒度，确保报表能覆盖高峰期与淡季的对比。通过对 campaigns、order_items、orders 的关联聚合，可以计算出活动带来的增量收入、平均客单价变化等关键指标。
对于运维和审计来说，指标口径的文档化与版本控制极其重要，确保团队成员对同一指标口径理解一致。
-- 计算活动的 ROI 与参与度的示例（简化）
SELECT
c.campaign_id,
c.name,
COUNT(DISTINCT o.order_id) AS orders_count,
SUM(o.total_amount) AS revenue,
SUM(o.discount_amount) AS discounts,
(SUM(o.total_amount) - SUM(o.discount_amount)) AS net_revenue
FROM campaigns c
LEFT JOIN orders o ON o.campaign_id = c.campaign_id
WHERE c.status = 'active' AND o.order_time BETWEEN c.start_time AND IFNULL(c.end_time, NOW())
GROUP BY c.campaign_id, c.name;
4.2 实时监控与离线报表
实时监控通常依赖事件队列和轻量级查询来快速反馈系统状态。为点餐系统中的营销活动提供实时洞察，需建设事件流、滚动窗口聚合、以及告警机制，例如在促销预算即将耗尽、或参与率出现异常时触发告警。
对于离线报表，可以定期将历史交易数据快照并进行深度分析，以评估长期效果。通过 ETL 流程将 campaigns、orders、order_items、promotions 等表汇聚到分析型数据库或数据仓库中，可以实现更复杂的维度分析。
5. 性能优化与数据安全
5.1 索引与查询优化
在营销活动场景中，高效的查询是系统可扩展性的基础。应对 campaigns、promotion_rules、targets、orders、order_items 等表建立必要的复合索引，尤其是对 campaign_id、order_time、start_time、end_time 及金额字段的组合查询。对热点字段使用前缀索引，避免全表扫描，提升响应速度。
同时，避免在热路径上进行大表的复杂联接。可以将常用聚合放在物化视图、或定时刷新到中间表，减少在线查询的计算量。对于促销叠加的规则，尽量将其放到低成本的缓存路径或存储过程内部进行判定。
-- 常见的组合索引示例
CREATE INDEX idx_campaign_time ON orders (campaign_id, order_time);
CREATE INDEX idx_campaign_status ON campaigns (campaign_id, status);
CREATE INDEX idx_order_amount ON orders (total_amount, order_time);
5.2 事务、隔离级别与安全性
关于并发写入，事务控制与合适的隔离级别是保障数据一致性的关键。在更新促销状态、写入订单抵扣时，建议使用事务并设置合理的 isolation level，以避免脏读和不可重复读带来的错配。
此外，数据安全性要覆盖两方面：权限控制与数据脱敏。对营销相关的敏感字段，按最小权限原则配置数据库用户，并在显示端进行必要的脱敏处理。对日志与审计记录，确保不可篡改性，必要时开启写入只读副本以降低主库压力。
-- 简化的事务示例（上线并应用促销）
START TRANSACTION;
UPDATE campaigns SET status = 'active' WHERE campaign_id = 123 AND status = 'draft';
UPDATE orders SET campaign_id = 123, discount_amount = 5.00
WHERE order_id = 555 AND total_amount >= 20.00;
COMMIT;
