SQL接口日志表优化核心是“写快、查少、删稳、扩易”，通过时间分区与业务分表实现冷热分离，禁用非必要约束与字段，采用异步批写和内存缓冲，并以预聚合宽表替代实时扫描。
SQL接口日志表在高并发、海量写入场景下容易成为性能瓶颈，优化核心是“写快、查少、删稳、扩易”。不靠堆硬件，而靠设计前置和分层控制。
按时间分区 + 按业务维度分表（冷热分离）
日志天然具有强时间属性，单表超千万行后INSERT和DELETE都会明显变慢。建议以天或小时为单位做范围分区（如MySQL 8.0+ RANGE COLUMNS），同时对高频调用的接口（如支付回调、登录验证）单独建子表或加前缀（log_pay_callback_20241001）。这样写入压力分散，清理历史数据只需DROP PARTITION或DROP TABLE，毫秒级完成，避免全表锁和长事务。
- MySQL开启
innodb_file_per_table=ON，确保分区可独立管理 - PostgreSQL推荐用
PARTITION BY RANGE (created_at)+DEFAULT分区兜底异常时间数据 - 避免用UUID或雪花ID作分区键——打散写入但破坏时间局部性，查最近1小时日志反而跨多个分区
写入路径极致精简：禁用非必要字段与约束
日志表不是业务表，不需要ACID强一致。能关的都关掉：
- 关闭唯一索引、外键、CHECK约束——日志重复或格式异常可接受，后期清洗即可
- TEXT/BLOB字段转为VARCHAR(1024)并截断，或异步落对象存储（如S3/MinIO），主表只存URL和哈希
- 把
created_at DEFAULT CURRENT_TIMESTAMP改为应用层生成时间戳（减少服务端函数调用开销） - 用
INSERT IGNORE或INSERT ... ON DUPLICATE KEY UPDATE替代先查后插，避免双写延迟
异步批写 + 内存缓冲兜底
应用层不要每条请求都直连DB写日志。改用内存队列（如Disruptor、LMAX RingBuffer）或轻量消息队列（RabbitMQ、Kafka）缓冲，攒够100~500条或100ms触发一次批量INSERT。好处明显：
- 单次INSERT多行比N次单行快5~20倍（减少网络往返+事务开销）
- 突发流量时内存缓冲可削峰，防止DB被打满
- 失败时可降级：缓冲区满则写本地磁盘文件，后台定时重投
查询走窄口径 + 预聚合代替实时扫描
99%的日志查询是“某个接口昨天错误率多少”“TOP5耗时接口”，而非查某条原始记录。因此：
- 禁止在日志主表上建复杂联合索引——写入成本飙升，且多数查询用不上
- 每天凌晨跑定时任务，将原始日志按
interface_name + date + status聚合到宽表（如daily_interface_stats），查报表直接读这张表 - ES或ClickHouse做全文检索补充：原始日志同步到ES，查明细用ES，统计分析回MySQL聚合表
基本上就这些。不复杂但容易忽略——很多团队卡在“先写再优化”思维里，等日志表涨到50GB才想起分区，其实从第一个接口上线就该定好分表策略和字段规范。
