SQL中不直接存储文件，而是通过file_info主表保存元数据（如original_name、stored_name、path、size_bytes等），配合外部存储实现文件管理；支持按业务扩展category、versions、permissions等关联表，并强调软删、索引优化与安全过滤。
SQL中不直接存储文件本身，而是保存文件的元数据（如名称、大小、路径、类型、上传时间、所属用户等），配合外部存储（如本地磁盘、对象存储OSS/S3）实现安全高效的文件管理。关键在于结构清晰、扩展性强、查询友好。
核心表结构设计
建议至少包含一张主表 file_info，覆盖通用字段：
- id：主键（BIGINT或UUID，推荐UUID便于分布式场景）
- original_name：原始文件名（VARCHAR(255)，保留用户上传时的名字）
- stored_name：存储后唯一文件名（如uuid4_1720123456789.jpg，避免重名和路径遍历）
- path：相对或完整存储路径（VARCHAR(512)，如 /uploads/user/2024/07/，不建议存绝对系统路径）
- size_bytes：文件大小（BIGINT，单位字节，便于排序和校验）
- mime_type：MIME类型（VARCHAR(100)，如 image/png，用于前端渲染或安全拦截）
- uploader_id：上传人ID（INT/BIGINT，关联用户表，支持NULL表示匿名）
- status：状态（TINYINT或ENUM，如 0=待处理、1=已就绪、-1=已删除）
- created_at / updated_at：时间戳（DATETIME或TIMESTAMP）
关联与扩展建模
按业务需要灵活扩展，避免过度设计：
- 若需记录文件用途（如头像、合同、附件），增加 category（VARCHAR）或外键到 file_categories 表
- 若支持多版本（如文档修订），建 file_versions 表，用 file_id 关联主表，并标记 is_current
- 若需权限控制（如仅指定用户可读），建 file_permissions 表，记录 file_id + subject_type + subject_id + permission
- 敏感文件可额外加字段：is_encrypted（TINYINT）、checksum_sha256（CHAR(64)）用于完整性校验
实际插入与查询示例
上传成功后，用参数化语句写入元数据（以MySQL为例）：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
INSERT INTO file_info (original_name, stored_name, path, size_bytes, mime_type, uploader_id, status, created_at) VALUES (?, ?, ?, ?, ?, ?, 1, NOW());
常用查询场景：
- 查某用户所有图片： SELECT * FROM file_info WHERE uploader_id = 123 AND mime_type LIKE 'image/%' ORDER BY created_at DESC;
- 查未处理的大文件（>10MB）： SELECT * FROM file_info WHERE status = 0 AND size_bytes > 10485760;
- 逻辑删除（推荐软删）： UPDATE file_info SET status = -1, updated_at = NOW() WHERE id = ?;
注意事项与避坑点
几个容易忽略但影响长期维护的关键点：
- 文件路径不要拼接在SQL里，必须由应用层生成并参数化传入，防止路径穿越或注入
- original_name 必须做过滤（如去除控制字符、截断超长名、转义特殊符号），避免前端XSS或日志污染
- 大字段（如base64内容）绝不能存进数据库，SQL只管元数据，二进制交给专业存储系统
- 为 uploader_id、status、created_at 建联合索引，支撑高频分页查询
- 定期归档历史文件元数据（如>2年且 status=-1），避免单表膨胀影响性能
基本上就这些。模型不复杂，但字段含义、约束逻辑和边界处理决定后期是否好维护。
