用户行为记录几乎是所有中大型系统都绕不开的功能，无论是做产品漏斗分析、用户画像，还是排查异常操作，背后都需要一份完整可靠的行为日志。很多团队一开始只是随手建了一张表，把能想到的字段全部塞进去，结果运行几个月后就发现表膨胀到几十GB，查询一条记录要十几秒，删除历史数据更是直接把主库拖垮。行为日志的难点不在于能不能存，而在于数据量大之后还能不能写得快、查得动、删得掉。本文围绕MySQL展开，从表结构设计、写入方案到后期维护，给出一套完整可落地的做法。
一、行为日志表的核心字段设计
设计行为日志表的第一步是明确要记录什么。行为日志的本质是回答“谁在什么时间、什么环境下做了什么操作”，因此核心字段应该围绕这几个维度展开。一个通用的行为日志表结构如下：
CREATE TABLE `user_behavior_log` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键', `user_id` BIGINT UNSIGNED NOT NULL COMMENT '用户ID', `action` VARCHAR(50) NOT NULL COMMENT '行为类型,如login,click,order', `target_type` VARCHAR(30) DEFAULT NULL COMMENT '操作对象类型,如article,goods', `target_id` BIGINT UNSIGNED DEFAULT NULL COMMENT '操作对象ID', `extra` JSON DEFAULT NULL COMMENT '扩展信息,如来源页面、设备参数', `ip` VARCHAR(46) DEFAULT NULL COMMENT '客户端IP,兼容IPv6', `user_agent` VARCHAR(255) DEFAULT NULL COMMENT '浏览器或客户端标识', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '行为发生时间', PRIMARY KEY (`id`), KEY `idx_user_time` (`user_id`, `created_at`), KEY `idx_action_time` (`action`, `created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户行为日志表';
这里有几个设计要点值得展开说明。首先是主键的选择，行为日志是典型的追加写场景，用自增主键可以保证新数据总是顺序写入索引末尾，避免页分裂带来的随机IO。不要用UUID做主键，随机主键会让插入性能断崖式下降。其次是action字段建议用受控的枚举值而不是自由文本，比如统一约定为login、view_page、add_cart这类短字符串，后期统计聚合时效率更高，也不容易出现同一个行为写法不一致的问题。
扩展信息用JSON字段是一个实用的折中方案。行为日志的字段需求经常变化，如果每加一种行为就加一列，表结构会越来越臃肿。把低频、结构多变的参数放进extra字段，既保持了主表结构稳定，又保留了追溯细节的能力。需要注意JSON字段不适合做查询条件，如果某个扩展属性经常被查询，应该考虑将其提升为独立字段并建立索引。索引方面，只保留用户加时间、行为加时间这两个组合索引就够了，日志表上的索引越多写入越慢，这一点和业务表的设计思路恰好相反。
二、写入方案：同步、批量与异步落库
写入方式的选择直接决定系统的抗压能力。最简单的方式是在业务代码里直接INSERT，比如用户点击一个按钮就同步写一条日志。这种方式实现成本最低，但在高并发场景下，日志写入会和业务写入争抢数据库连接，一旦日志表出现写入堆积，整个业务都会被拖累。
更稳妥的做法是批量写入。行为日志通常不需要实时可见，可以在应用层先把日志攒到内存队列里，每隔几秒或攒够一定条数后一次性批量插入：
INSERT INTO user_behavior_log
(user_id, action, target_type, target_id, extra, ip, created_at)
VALUES
(10001, 'view_page', 'article', 8891, '{"from":"home"}', '203.0.113.15', '2024-03-01 10:23:11'),
(10002, 'click', 'banner', 34, '{"pos":"top"}', '203.0.113.22', '2024-03-01 10:23:12'),
(10003, 'add_cart', 'goods', 5567, '{"sku":"A102"}', '203.0.113.31', '2024-03-01 10:23:12');单条INSERT和一次插入几百条的多值INSERT，网络往返和事务开销相差悬殊，批量写入的吞吐量往往是单条写入的十倍以上。实践中建议把每批控制在500到1000条以内，批次太大反而会占用长事务和大量undo日志，得不偿失。
如果对可靠性要求更高，可以引入消息队列做异步落库。业务方把行为事件发到MQ，由专门的消费服务负责批量写入MySQL。这样即使数据库短暂抖动，消息也会堆积在队列里等待重试，不会丢失行为数据。这种架构下要注意做好消费端的幂等处理，可以借助日志表上的唯一约束或者消费前查询去重，避免队列重投导致重复记录。
三、大表治理：分区、归档与清理
行为日志表的数据量只增不减，几个月后单表破千万甚至上亿是常态，必须提前规划分区和清理策略。MySQL的分区表对日志场景非常友好，按时间范围分区是最常见的做法：
ALTER TABLE user_behavior_log
PARTITION BY RANGE (TO_DAYS(created_at)) (
PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')),
PARTITION p202402 VALUES LESS THAN (TO_DAYS('2024-03-01')),
PARTITION p202403 VALUES LESS THAN (TO_DAYS('2024-04-01')),
PARTITION pmax VALUES LESS THAN MAXVALUE
);按月分区后，查询最近一个月的数据只会扫描对应的分区，速度明显提升。清理历史数据时也不要用DELETE，大范围DELETE会产生大量锁和binlog，严重影响主从复制。正确姿势是直接删除整个分区，这是DDL级别的操作，几乎是瞬间完成：
ALTER TABLE user_behavior_log DROP PARTITION p202401;
对于需要长期留存的数据，建议采用冷热分离策略。热数据保留最近三到六个月在MySQL中，供日常查询分析；更早的数据定期导出到数据仓库或者归档表。归档可以用INSERT INTO ... SELECT把数据搬到归档库，确认无误后再清理源表分区。整个过程建议写成定时任务在业务低峰期执行，并保留执行日志以便追溯。分区表也有约束条件，比如主键必须包含分区键，这一点在建表之初就要设计好，否则后期改造成本很高。只要在表结构、写入链路和数据生命周期三个层面都做好规划，MySQL完全能够支撑一套稳定高效的用户行为记录系统。