mysql 应只存下载元数据（如 user_id、file_path、download_time），不存文件本身；文件放磁盘或对象存储；用参数化查询插入，建 file_name+download_time 复合索引优化高频统计。
用 MySQL 存文件下载记录，别存文件本身
MySQL 不适合直接存储大文件（如 PDF、ZIP），BLOB 类型会拖慢备份、复制和查询性能，还容易触发 max_allowed_packet 错误。真正该存的是「谁、什么时候、下了哪个文件、路径在哪」——文件本体放在磁盘或对象存储里，数据库只管元数据和行为日志。
典型字段建议：id、user_id、file_name、file_path（如 /uploads/2024/05/report_v2.pdf）、download_time（DATETIME）、ip_address、user_agent（可选，用于识别设备类型）。
注意：file_path 必须是应用层可控的绝对路径或相对路径，不能依赖 MySQL 的 LOAD_FILE() 或 SELECT ... INTO DUMPFILE——这些函数默认禁用，且权限要求高，不适合常规下载记录场景。
INSERT 时如何自动记录时间与客户端信息
后端代码（如 Python/PHP/Java）在用户点击下载链接后、实际返回文件前，先执行一条 INSERT。不要依赖 NOW() + 应用层拼接 SQL，容易被注入；用参数化查询。
-
download_time用应用层datetime.now()或date('Y-m-d H:i:s')生成，确保时区一致（推荐全系统用 UTC） -
ip_address从请求头取X-Forwarded-For（注意代理链校验）， fallback 到REMOTE_ADDR - 避免把
user_agent当主键或索引字段——太长且低区分度，真要查可用LIKE '%Chrome%'临时过滤，但别建索引
示例（Python + PyMySQL）：
cursor.execute(
"INSERT INTO download_log (user_id, file_name, file_path, download_time, ip_address) VALUES (%s, %s, %s, %s, %s)",
(user_id, filename, filepath, datetime.utcnow(), client_ip)
)查下载频次、防刷、定位异常行为
靠单表 SELECT COUNT(*) 和 GROUP BY 就能快速看出问题。重点不是“怎么查”，而是“查什么才有效”。
- 1 小时内同一
ip_address下载 > 10 次？跑个SELECT ip_address, COUNT(*) FROM download_log WHERE download_time > NOW() - INTERVAL 1 HOUR GROUP BY ip_address HAVING COUNT(*) > 10 - 某个
file_name突然被高频下载（比如 5 分钟 200 次）？加INDEX(file_name, download_time)加速范围扫描 - 用户
user_id = 0（未登录）占比过高？说明登录态没校验或埋点漏了，得回溯应用逻辑
别忘了定期清理：老日志（如 90 天前）用 DELETE FROM download_log WHERE download_time ，或者按月分表。
为什么不能用 MySQL 的 SELECT … INTO OUTFILE 做“下载”
这是最常见的误解：SELECT ... INTO OUTFILE 是 MySQL 服务端把查询结果写到服务器本地磁盘（路径必须是 MySQL 进程有写权限的目录，如 /var/lib/mysql-files/），**不是发给客户端的文件下载**。它不经过网络响应流，也不受 HTTP 头控制，完全无法实现“浏览器弹保存框”效果。
真正让浏览器下载文件，靠的是后端设置响应头：
Content-Type: application/octet-stream Content-Disposition: attachment; filename="report.pdf"
然后把文件内容（或流）写入响应体——这个动作和 MySQL 无关。MySQL 只负责告诉你“该读哪个文件”“该记哪条日志”。混淆这两层，会导致权限配置错误、路径越界、甚至把数据库文件意外暴露。
复杂点在于：文件路径需校验合法性（防止 ../../../etc/passwd 路径遍历），下载记录要和鉴权强绑定（比如用户 A 不能通过改 URL 参数下载用户 B 的私有文件），这些都得在应用层做，MySQL 只是可靠记账的那本册子。
