应将原图与衍生图分离存储：photos表存原始文件信息，photo_versions表通过外键关联并启用ON DELETE CASCADE自动清理，按photo_id索引高效查询各版本路径。
怎么存多尺寸图片才不乱
直接一张表存所有尺寸的路径，后期查起来像翻抽屉——找不到、删不干净、改个逻辑要改十处。核心是把「原图」和「衍生图」拆开，用外键绑定。
-
photos表只存原始文件信息：id、original_filename、storage_path（比如/orig/2024/05/abc123.jpg）、mime_type、width/height（原图尺寸） -
photo_versions表存所有变体：id、photo_id（外键到photos.id）、version_name（如"thumb"、"webp_800"）、storage_path、width/height、mime_type - 不要在
photo_versions里冗余存原图尺寸，它只该知道自己这版的参数
外键删原图时怎么连带清理缩略图
靠应用层手动删容易漏，MySQL 的 ON DELETE CASCADE 是最省心的选择，但得确认存储引擎支持（InnoDB 支持，MyISAM 不行）。
- 建
photo_versions表时，外键定义必须显式加ON DELETE CASCADE：FOREIGN KEY (photo_id) REFERENCES photos(id) ON DELETE CASCADE
- 别依赖 ORM 自动级联——有些框架默认关掉或只做软删，数据库层才是最终防线
- 测试时故意删一条
photos记录，立刻查photo_versions看对应行是否消失，别等上线后发现缩略图变“幽灵文件”
查询某张相册图的所有版本怎么写才快
用户点开一张图，前端要一次性拉出原图、缩略图、高清 WebP 版——不能发三次 SQL，也不能用 SELECT * 把整张 photo_versions 扫一遍。
- 查的时候固定用
photo_id过滤，别用模糊字段（比如version_name LIKE "%webp%"） - 给
photo_versions(photo_id)加普通索引，不是唯一索引（因为一个原图对应多个版本） - 示例查询：
SELECT version_name, storage_path, width, height FROM photo_versions WHERE photo_id = 123;
- 如果版本类型固定（就那 3–5 种），可以加
ENUM或CHECK约束，避免存错值导致查询空跑
文件路径存在数据库里安全吗
存在数据库里没问题，但必须保证路径不拼接用户输入、不暴露真实服务器结构、不带可执行扩展名。
-
storage_path字段用VARCHAR(512)足够，别用TEXT——没意义还拖慢索引 - 路径里别出现
../、~、绝对路径（如/var/www/），统一用相对存储根目录的路径，比如orig/2024/05/abc123.jpg - 上传时校验文件头（magic bytes），别光看后缀；入库前把
.php、.jsp这类后缀直接拒掉，哪怕它真是图片 - Web 服务器（Nginx/Apache）要配置禁止执行图片目录下的脚本，这是最后一道保险
事情说清了就结束。真正麻烦的是版本命名策略和清理冷数据——比如三年前的“iphone_retina”版没人访问了，删不删？什么时候删？这得结合业务日志，不是单靠数据库设计能解决的。
