购物车表必须区分用户会话与登录状态
未登录用户用
session_id标识，已登录用户用
user_id，二者不能共存于同一字段。常见错误是只建一个
user_id并允许为 NULL，导致查询时需反复判断，且无法利用索引加速未登录场景。
正确做法是设两个字段：
user_id（BIGINT UNSIGNED，可为 NULL）和
session_id（VARCHAR(128)，非 NULL），并在 WHERE 条件中明确使用其中之一：
SELECT * FROM cart_items WHERE user_id = 123; -- 或 SELECT * FROM cart_items WHERE session_id = 'abc123...';
同时为这两列分别建索引，避免全表扫描。
商品关联必须用 product_id
+ sku_id
两级标识
单纯用
product_id无法支持多规格（如颜色、尺寸），而只存
sku_id又丢失了商品主干信息。实际业务中，SKU 是库存与价格的最小单位，但前端展示常需回溯到所属商品（如“iPhone 15”这个商品下有多个 SKU）。
因此表结构中应同时保留：
product_id：指向
products表，用于聚合、展示、类目统计
sku_id：指向
skus表，用于校验库存、价格、限购数
插入或更新前必须校验
sku_id是否真实存在且
status = 'on_sale'，否则会出现“加进去了却结不了账”的问题。
quantity
字段必须带约束且禁止负值
购物车数量不是简单整数，它受多重限制：最小值为 1，最大值由 SKU 的
max_per_order决定，且不能超过当前可用库存（
stock_quantity）。若仅靠应用层校验，高并发下极易超卖。
建议在数据库层面做基础兜底：
定义quantity TINYINT UNSIGNED DEFAULT 1 CHECK (quantity >= 1)写入前查
SELECT stock_quantity, max_per_order FROM skus WHERE sku_id = ?UPDATE 时用乐观锁：
UPDATE cart_items SET quantity = ? WHERE id = ? AND quantity （? 为当前允许的最大值）
不要依赖触发器自动修正数量——它无法感知业务规则变化，且调试困难。
删除逻辑必须异步清理，不能依赖定时任务扫全表
购物车数据天然具备时效性：未登录用户的
session_id过期后应清理，已登录用户长时间未操作的条目也该归档。但直接对
cart_items执行
DELETE FROM cart_items WHERE updated_at 会锁表、拖慢写入。
更稳妥的做法是：
给cart_items加复合索引：
(session_id, updated_at)和
(user_id, updated_at)按天分表或分区（如按
user_id % 16分 16 张子表），降低单次清理压力 清理任务每次只删 1000 行，并 sleep 100ms，避免冲击主库
真正棘手的是“用户刚登出又立刻以新 session 登录”，此时旧 session 数据是否合并？这个逻辑不在表结构里，但在应用层必须显式处理，否则购物车凭空消失。
