文件元数据必须单独建表，不要把文件内容塞进业务表
直接在用户表或订单表里加一个
file_contentBLOB 字段看似省事，但会导致主表膨胀、备份变慢、查询变卡，尤其当业务表本身已有高频读写时。MySQL 对大字段（如 BLOB/TEXT）的处理机制是：即使没查该字段，只要 SELECT * 或字段在索引覆盖之外，就可能触发额外的磁盘 I/O 去读取溢出页。
正确做法是拆成两张表：
files表存元数据：
id、
original_name、
storage_path、
size_bytes、
mimetype、
uploader_id、
created_at业务表（如
orders）只存外键
attachment_id或 JSON 数组存多个
file_id（需配合应用层校验）
注意：
storage_path推荐存相对路径（如
2024/06/15/abc123.png），而非绝对 URL 或物理路径，方便后续迁移到对象存储（如 OSS/S3）时做透明替换。
大文件别用 BLOB 存 MySQL，用文件系统 + 路径引用
MySQL 官方明确建议：BLOB 不适合存储 > 1MB 的文件。实际压测中，单条记录超 4MB 就容易触发
max_allowed_packet限制，且复制延迟、主从同步稳定性都会下降。
上传流程应为：
前端分片上传（可选）或服务端接收完整二进制流 生成唯一文件名（如 UUIDv4 + 时间戳哈希），写入本地磁盘或挂载的 NFS 目录（如/data/uploads/...） 仅将文件路径、哈希值（
md5或
sha256）、大小等写入
files表 定时任务清理无关联的物理文件（通过 LEFT JOIN 查
files中
id不在任何业务表外键中的记录）
如果用云存储，
storage_path可存为
oss://bucket-name/path/to/file.jpg，应用层统一解析并生成预签名 URL，MySQL 本身不感知存储后端。
文件名和 mimetype 必须由服务端重写，不能信前端传的
前端提交的
filename和
Content-Type可被任意篡改，常见攻击包括：
../../etc/passwd路径遍历、
shell.php伪装图片、
text/plain冒充
image/jpeg绕过校验。
服务端要做三件事：
忽略原始filename，用服务端生成的 ID 重命名（如
7f8a2b1e-9c4d-4e6f-ba7c-3d9e8a1f2b4c.jpg） 用
file命令（Linux）或
libmagic库真实检测二进制头，覆盖前端传的
mimetype对允许类型做白名单检查（如只允
image/jpeg、
application/pdf），拒绝一切
application/x-php、
text/html等可执行/渲染类型
MySQL 层可加 CHECK 约束（8.0.16+）：
CONSTRAINT chk_mimetype CHECK (mimetype IN ('image/jpeg','image/png','application/pdf'))，但不能替代服务端校验。
删除文件要事务化：先删数据库记录，再删物理文件
顺序反了会留下“孤儿文件”——数据库里找不到记录，但磁盘上还占空间；更糟的是，如果删库成功、删文件失败，下次上传同名文件可能被误覆盖或报错。
推荐做法：
用数据库事务包裹DELETE FROM files WHERE id = ?事务提交成功后，异步发消息（如 RabbitMQ/Kafka）或调用清理队列，由独立 worker 执行物理删除 若必须同步删，确保
unlink()或
rm命令失败时抛异常并回滚整个事务（框架需支持嵌套事务或补偿逻辑）
另外，
files表建议加软删除字段
deleted_at DATETIME NULL，避免误删不可逆；物理清理任务只扫
deleted_at IS NOT NULL AND deleted_at 的记录。
最易被忽略的是：不同环境（开发/测试/生产）的
storage_path根目录必须隔离，否则本地调试时一删可能清掉测试服的文件。
