多用户多条目场景下图片关联数据库存储的最优方案是什么

首先直接给出结论：方案1（所有图片存同一目录）不推荐，方案2适合单车辆单图场景，单车辆多图场景建议追加车辆级子目录，具体分析如下：

不同方案的优劣对比 #

• 方案1（单目录存储所有图片）：属于极不合理的技术实践，完全不推荐。
  操作系统对单目录下的文件数量有性能瓶颈，不管是Windows还是Linux，单目录文件超过1万后，文件的读取、遍历、查找效率会出现断崖式下跌，用户量稍有增长就会触发性能问题。同时用用户名+序号命名的规则风险很高：如果用户名包含特殊字符（如/、空格、特殊符号）很容易导致路径解析错误，后续用户修改用户名时，批量修改关联文件名的成本也极高，很容易出现数据不一致。
• 方案2（按用户建独立目录）：单车辆单图场景下是合理方案，但需要做一点优化：不要用用户名当目录名，改用数据库中用户的唯一不可变ID（自增主键、UUID均可）作为目录名，避免用户名修改、特殊字符带来的维护问题。目录内的图片直接用车辆的唯一ID命名即可，比如路径格式为/{用户ID}/{车辆ID}.jpg，数据库直接存储该相对路径即可，后续查找、修改都很方便。
• 单车辆多图场景的处理：非常建议为每台车辆单独创建子目录，子目录用车辆的唯一ID命名，放在对应用户的目录下，路径格式可以参考/{用户ID}/{车辆ID}/{序号/时间戳}.jpg。
  这么做的优势很明显：后续要删除某台车辆的所有数据时，直接删除对应车辆目录即可，不需要遍历查找所有关联图片；要导出单台车的所有资料时，直接打包整个目录即可完成，运维成本极低，同时也方便做细粒度的权限校验。

额外优化建议 #

如果你的应用后续预期用户量会超过10万，可以额外加一层哈希散列目录，比如取用户ID的前2位作为一级目录，再放用户目录，避免一级目录下的文件夹数量过多触发性能瓶颈，中小体量的应用不需要做这个额外处理，按上述规则存储即可。

内容的提问来源于stack exchange，提问作者craftdeer