MySQL用户行为记录应采用独立日志表+异步/批量写入，字段含id、user_id、action、target_type、target_id、extra（JSON）、ip、ua、created_at；建(user_id,created_at)、(action,created_at)等索引；按时间分区并分级归档。
在 MySQL 中实现用户行为记录，核心是设计一个可扩展、低侵入、易查询的行为日志表，并配合合理的写入策略与索引优化。不建议直接在业务表中加字段或用触发器硬耦合，而应采用独立日志表 + 异步/批量写入方式。
行为日志表结构设计
一张通用、轻量、支持多种行为类型的日志表是基础。推荐字段如下：
- id：BIGINT AUTO_INCREMENT 主键（便于分页和顺序读取）
- user_id：INT/BIGINT，用户标识（允许为 NULL，覆盖游客场景）
- action：VARCHAR(32)，行为类型，如 'login'、'click_product'、'submit_order'、'search' —— 用语义化英文，避免中文或过长描述
- target_type：VARCHAR(20)，目标类型，如 'article'、'user'、'order'（配合 target_id 使用）
- target_id：BIGINT，目标记录 ID（如点击的文章 ID、被关注的用户 ID）
- extra：JSON 类型（MySQL 5.7+），存放非固定字段，如搜索关键词、按钮位置、设备类型、来源页面等
- ip：VARCHAR(45)，记录客户端 IP（支持 IPv6）
- ua：TEXT，可选，存简化的 User-Agent（如只保留 browser + os）
- created_at：DATETIME / TIMESTAMP，默认 CURRENT_TIMESTAMP
注意：不要为每个行为建单独表，统一表 + action 字段更利于维护和聚合分析；extra 用 JSON 而非序列化字符串，方便后续用 JSON_EXTRACT 查询。
写入方式：优先异步，避免阻塞主流程
用户行为日志对实时性要求通常不高，但写入频次高、量大。同步写库易拖慢接口响应，推荐以下方式：
- 应用层先写入消息队列（如 Kafka、RabbitMQ 或 Redis List），再由后台消费者批量插入 MySQL
- 若无 MQ，可用本地缓存暂存（如内存队列 + 定时 flush），或使用 INSERT … VALUES (),(),() 批量插入（单次最多 1000 行）
- 禁止在事务中写行为日志（尤其订单创建等核心事务），防止日志失败导致主流程回滚
关键索引与查询优化
高频查询模式通常是「某用户近期行为」、「某类行为统计」、「某时间段内某操作分布」。建议建立以下组合索引：
- (user_id, created_at)：查用户行为时间线
- (action, created_at)：按行为类型查趋势（如每天 login 次数）
- (created_at)：范围查询主索引（配合分区提升效率）
- 如需按 target_id 快速反查（如“谁点击了这个商品”），可加 (target_type, target_id, created_at)
对超大日志表（亿级），可按月/周对 created_at 进行 RANGE 分区，加快冷数据归档与删除。
数据生命周期与归档策略
行为日志增长极快，需主动管理：
- 热数据（近 3 个月）保留在主表，确保查询性能
- 温数据（3–12 个月）可迁移到历史表（同结构，不同名），或转存至列存数据库（如 ClickHouse）做分析
- 冷数据（1 年以上）压缩归档为 Parquet 文件存对象存储，或直接 DROP PARTITION
- 定期用事件（EVENT）或运维脚本执行清理，例如：red">DELETE FROM user_behavior_log WHERE created_at
不复杂但容易忽略。
