做后台开发时，系统运行状态的监控离不开网络日志。无论是用户访问页面、接口调用失败，还是服务器异常重启，这些信息都得靠日志来记录。但日志不是随便写写就完事了，尤其当数据量上来之后，怎么设计一个合理的数据模型，直接影响到后续的查询效率和分析能力。
日志内容到底该存什么
先别急着建表，想想你真正关心的是什么。比如你在做一个电商后台，想知道某个促销活动期间用户下单失败的情况。这时候光记录“请求失败”就没啥用，你还得知道是哪个用户、在哪个时间点、调了哪个接口、返回了什么错误码、有没有异常堆栈。
所以典型的网络日志至少要包括：时间戳、客户端IP、请求路径、HTTP方法、响应状态码、耗时、用户标识（如user_id）、设备信息、追踪ID（trace_id）等。如果涉及敏感操作，还可以加上操作结果和变更前后的值。
数据库表结构怎么定
如果你用的是关系型数据库，比如MySQL，可以这样设计主表：
CREATE TABLE `access_log` (
`id` BIGINT AUTO_INCREMENT PRIMARY KEY,
`timestamp` DATETIME(6) NOT NULL,
`client_ip` VARCHAR(45) NOT NULL,
`request_method` VARCHAR(10) NOT NULL,
`request_url` VARCHAR(512) NOT NULL,
`status_code` SMALLINT NOT NULL,
`response_time_ms` INT NOT NULL,
`user_id` BIGINT DEFAULT NULL,
`trace_id` CHAR(32) DEFAULT NULL,
`user_agent` VARCHAR(255) DEFAULT NULL,
`error_stack` TEXT DEFAULT NULL,
INDEX `idx_timestamp` (`timestamp`),
INDEX `idx_user_id` (`user_id`),
INDEX `idx_trace_id` (`trace_id`)
) ENGINE=InnoDB;这里用DATETIME(6)支持微秒精度，方便做性能分析；client_ip留45位是为了兼容IPv6；trace_id用于链路追踪，排查问题时能串起一次完整请求的所有日志。
要不要拆分大字段
像error_stack这种可能很长的内容，如果每次都和主记录一起查，会拖慢整体性能。更合理的做法是把高频查询字段放在主表，大文本单独存到扩展表里：
CREATE TABLE `log_detail` (
`log_id` BIGINT PRIMARY KEY,
`stack_trace` LONGTEXT,
`request_body` MEDIUMTEXT,
`response_body` MEDIUMTEXT,
FOREIGN KEY (`log_id`) REFERENCES `access_log`(`id`)
);这样日常看访问情况不用加载大字段，真要深挖问题再关联查询，系统负担小很多。
高并发下怎么扛住写入压力
想象一下双十一流量高峰，每秒几万条日志涌进来，直接往数据库insert肯定撑不住。常见的解法是加缓冲层——应用先把日志发到Kafka或者RabbitMQ，再由专门的消费者服务批量落库。
另外也可以考虑用Elasticsearch这类专为日志设计的存储方案。它天然支持分片、倒排索引，配合Filebeat、Logstash整套ELK栈，查起来比MySQL快得多。这时候数据模型就得按ES的习惯来，比如定义好index template，设置keyword和text字段类型，避免mapping被自动推断搞乱。
冷热数据如何处理
最近三天的日志天天查，三年前的几乎没人碰。全堆在一个表里既浪费资源又影响性能。可以按月分表，或者用TTL机制自动归档。比如MySQL 8.0支持表级生命周期管理，PostgreSQL也能通过分区表+定时任务清理旧数据。
更灵活的方式是写入时打上时间标签，查询服务根据时间范围决定走实时库还是历史库。比如近一周走ES热节点，一个月前的导去HDFS+Spark分析，成本低还不会拖累在线系统。
别忘了预留扩展空间
刚开始可能只记录Web请求，后来APP端接入了，又要记埋点事件；再后来IoT设备上了，日志格式又不一样。一开始就在表里留一两个JSON类型的扩展字段很实用：
`extra_info` JSON DEFAULT NULL这样新业务加字段不用频繁改表结构，程序里也能动态塞进去device_model、network_type这类个性化数据，后期分析时再提取出来就行。