我在服务器上存储了一些高层文件（如果重要的话，100K+），并将它们组织在不同的库中。当有人访问图库时，我只显示缩略图和低分辨率版本的图像，在某些情况下会添加水印，而在其他情况下则不会。现在，由于我说的是大量的图片，显示在图库页面上的低分辨率版本在X天后从服务器上清除。如果有人访问了图库，而服务器上不存在该文件的低分辨率版本，则它是动态生成的，但当我生成低分辨率时，我可能需要对其进行水印处理。
目前，显示图像的脚本不执行任何SQL调用——这一切都基于文件系统（如果存在文件等），并且是否对图像加水印的决定基于：
if (strpos($file_name,"FREE")===false){ //add watermark }else{ //just resize}
我的逻辑认为，这比对文件名或fileid执行SQL查询并检查它是否应该是无水印图像更具性能。然而，我发现文件名中包含单词FREE有点不方便。
如果使用SQL查询而不是strpos，那么性能会有多大差异？
编辑/更新
总结答案和评论：
该系统被设计为运行几年，随着时间的推移，所有增加的画廊仍然可以访问。这意味着存储需求非常大，旧相册的高分辨率图像将在缓慢而廉价的专用存储上移动到场外，因此建议在所有缩略图上留出额外的开销，这是一个非常不可行的选择。去年我需要存储超过3TB的图像（这只是高层建筑的尺寸）。
我在Lighttpd上，我打算使用
rewrite-if-not-file来获得现有缩略图的最佳性能。我知道I/O写惩罚，我打算把它降到最低，只在必要时写，最好是阅读。然而，@N.B.的评论确实让我想到了将低分辨率图像存储在SSD上，所以即使我需要创建图像并将其写入磁盘，也比普通HDD有更好的I/O性能。
实际上，做一些测试会很困难（@Steve E.）我落后于计划，系统必须在本月底上线。（我今天刚收到炸弹，说他们正在拔掉旧系统的插头）。是的，灵活性是我想使用SQL的主要原因，但我预计SQL数据库会显著增长，除了文件信息之外，我还需要存储大量其他信息，如标记、购买、下载等，所以我也在努力确保我不会给SQL带来太大压力，当我可以通过良好的结构和文件系统访问来利用其中的一些功能时。
如果不进行测试，很难确定哪种方法会更快。简单的逻辑可能表明PHP访问磁盘更快，但这是基于许多假设的。
在配置良好的系统中，经常需要的变量将在RAM缓存中，而不是在磁盘上。这适用于文件系统的缓存以及MySQL缓存索引。缓存和其他机制的影响可能会产生与预期不同的结果。
在许多情况下，这两种解决方案都是有效的，并且是足够的，因为在设计良好的系统中，两种请求所需的时间都应该是最小的，而且一种方法的额外性能可能不值得在文件名中使用"FREE"带来的不便。同时尝试两种方法和衡量性能并不难。
从长远来看，还需要考虑MySQL为添加额外功能提供了更大的灵活性，如果所有状态都存储在文件名中，这些功能会变得更复杂。
如果性能确实是一个重大问题，那么在将请求传递给PHP之前，请考虑使用Web服务器检查磁盘上（或memcache等缓存中）的文件，并返回该文件（如果存在）。Nginx和Apache都可以做到这一点，这是高流量网站常用的加速方法。
您已经完成了最难的部分。SQL查询在您的情况下只会减慢您的速度。。。
user--->php-->filesystem-->php--->user
如果mysql进来，就是这样
user--->php--->mysql--->filesystem--->mysql-->php--->user
因此，在不使用mysql的情况下，您已经节省了一些时间。。。
如果有人访问了图库，而服务器上不存在该文件的低分辨率版本，则会动态生成
如果高分辨率版本不存储在数据库中，而是作为服务器文件存储，这意味着低分辨率缩略图与高分辨率图像成比例地占用非常小的空间。例如，假设低分辨率图像的大小是高分辨率图像的10%。保留所有服务器上可用的低分辨率图像只会增加10%的存储需求，如果您没有10%的备用容量，那么您需要购买更多的存储空间，而不是尝试编程解决方案。
从注释中，您似乎已经在数据库中存储了有关该文件的一些信息。如果是这种情况，那么您应该能够添加一列来确定它是否空闲，并在查询其他信息的同时获得额外的列，从而几乎不增加开销。