Nginx无法直接写日志到数据库，需通过中间层转发：推荐filebeat+logstash+MySQL组合，配置JSON日志格式；或用fluentd轻量替代；低频场景可用脚本轮询定时入库，但须注意并发与可靠性。
Nginx 本身不支持直接将访问日志写入数据库，必须通过中间层（如日志收集器或脚本）转发日志数据。核心思路是：先让 Nginx 将日志输出到文件或标准输出，再用外部工具实时采集、解析、入库。
使用 filebeat + logstash + MySQL（推荐方案）
这是生产环境中稳定、可扩展的常见组合，适合中高流量场景。
- 配置 Nginx 日志为 JSON 格式（便于后续结构化解析）：
access_log /var/log/nginx/access.log json;
- 安装并配置 Filebeat，监听该日志文件，将内容发送给 Logstash；
- Logstash 配置 filter 插件解析 JSON，并用 jdbc 插件写入 MySQL 表（需提前建好对应字段的表）；
- 注意设置 Logstash 的 JDBC 批量插入参数（如 batch_size 和 flush_interval），避免频繁单条写入拖慢性能。
用 fluentd 替代 logstash（轻量替代）
Fluentd 启动更快、内存占用更低，对资源受限环境更友好。
- 在 fluentd 配置中使用 in_tail 插件读取 Nginx 日志文件；
- 用 parser 插件解析 JSON 或正则匹配字段；
- 通过 out_sql 或 out_mysql 插件写入数据库，支持批量提交和失败重试；
- 建议启用 fluentd 的 buffer 机制，防止数据库短暂不可用导致日志丢失。
简单脚本轮询 + 定时入库（低频适用）
适用于测试环境或日均请求量低于 1 万的小型服务。
- 用 Python 或 Bash 脚本定期（如每分钟）读取新追加的日志行（可用 tail -n +N 或记录 inode+offset）；
- 逐行解析 JSON，过滤无效数据，拼成 INSERT 语句或调用 MySQL 客户端批量导入；
- 务必加锁或使用原子性标记（如临时位点文件），避免重复处理或漏处理；
- 不要在高并发下用此方式——容易阻塞 Nginx 写日志或造成数据库连接风暴。
注意事项与避坑点
无论选哪种方式，以下细节直接影响可用性：
- Nginx 日志需开启 buffer 和 flush（如 access_log /path/log.json json buffer=64k flush=1s;），减少磁盘 I/O 频次；
- 数据库表设计要合理：时间字段用 DATETIME 或 BIGINT 存时间戳，高频查询字段建索引（如 status、time_local）；
- 避免在入库环节做复杂计算（如实时 PV/UV），应由分析系统（如 ClickHouse、Grafana+Prometheus）承担；
- 务必监控采集链路：Filebeat/Fluentd 是否存活、Logstash 是否积压、MySQL 是否拒绝连接或慢查询。
