SQL日志表设计核心是“写入吞吐 vs 查询可用性”的平衡，须精简字段、批量插入、分区主键、按需建索引、自动分区归档，一切围绕“写得快、删得快、查得准”展开。
SQL日志表在高写入场景下，核心矛盾是“写入吞吐 vs 查询可用性”。设计不当会导致磁盘IO打满、主键自增锁争用、慢查询拖垮业务。关键不是堆索引或加机器，而是从写入路径源头做减法。
日志表结构：只存必要字段，拒绝冗余
日志本质是追加写，绝大多数场景只需定位问题，而非复杂关联分析。字段设计务必克制：
- 必须字段：id（BIGINT AUTO_INCREMENT 或 UUID）、log_time（DATETIME(3) 或 BIGINT 时间戳）、level（TINYINT，如 1=DEBUG, 2=INFO, 3=WARN, 4=ERROR）、service_name（VARCHAR(32)，服务标识）、trace_id（VARCHAR(64)，用于链路追踪）、content（TEXT 或 MEDIUMTEXT，原始日志内容）
- 谨慎添加：host_ip、user_id、request_id —— 只在真实高频检索需求时才加，且建议建单独覆盖索引
- 禁止字段：JSON 字段（除非全文检索强依赖）、大文本字段拼接结果、冗余时间字段（如 created_at + updated_at）、外键约束（日志表不参与事务一致性）
写入优化：绕过事务与锁瓶颈
高并发写日志最怕 INSERT 阻塞。MySQL 默认的 AUTO_INCREMENT 锁和二级索引维护成本在万级 QPS 下会明显暴露：
- 用 INSERT INTO ... VALUES (...), (...), (...) 批量插入，单次写入 50–200 条为佳（根据平均日志大小调整）
- 关闭 autocommit，显式使用 START TRANSACTION; INSERT ...; COMMIT;，减少日志刷盘频率
- 考虑将 log_time 设为 主键第一列 + id 为第二列（如 PRIMARY KEY (log_time, id)），配合按天/小时分区，让写入天然局部化、避免热点
- 若允许轻微延迟，可引入消息队列（如 Kafka/RocketMQ）做缓冲，应用端异步发日志，DB 层用消费者程序批量落库
索引策略：查得快，但不拖慢写
日志表索引不是越多越好，每个索引都会增加 INSERT/UPDATE 的 B+ 树分裂开销：
- 必建索引：INDEX idx_time_service (log_time, service_name) —— 支撑按时间范围 + 服务名快速筛选
- 按需索引：INDEX idx_trace (trace_id)（仅当链路排查是高频操作）；INDEX idx_level_time (level, log_time)（如需快速抓 ERROR 日志）
- 避免单列索引：如单独给 content 建 FULLTEXT 索引代价极高，改用外部方案（Elasticsearch 或 Loki）更合理
- 定期检查 SHOW INDEX FROM log_table 和 information_schema.INNODB_METRICS 中 index_lock_wait_count，发现锁等待飙升就删掉低效索引
生命周期管理：自动归档，不让表无限膨胀
日志不清理 = 性能慢性死亡。别依赖人工删，要靠机制：
- 用 PARTITION BY RANGE COLUMNS(log_time) 按天或按周分区（MySQL 5.7+），删除旧数据只需 ALTER TABLE ... DROP PARTITION，毫秒级完成
- 搭配事件调度器（EVENT）每日凌晨执行归档逻辑：把 7 天前数据 INSERT INTO archive_log_table SELECT ...，再 DROP PARTITION
- 归档表可设为 MyISAM（只读场景）或压缩行格式（ROW_FORMAT=COMPRESSED），节省 40%+ 存储空间
- 对超过 90 天的日志，直接转存到对象存储（如 S3/OSS），数据库只留元信息（路径、大小、哈希值）
不复杂但容易忽略：日志表不是通用表，它不需要 ACID 强一致、不需要 JOIN、不需要实时统计。一切设计围绕「写得快、删得快、查得准」三个目标展开。其他都是干扰项。
