为什么图片不放进表里
上一篇说数据库长得像电子表格，是适合一行行堆名字、日期和数字的结构。
照片和视频不是该塞进那些格子的东西。概念上是能塞的，只是效率不行。
原因在于取用的方式。为了画一个列表画面可能要查二十行，如果每一行里都整个装着图片，那些在画面上根本不会显示的图片也会被一并拖出来。数据库不是为这种沉重的一坨频繁往返而造的工具。
所以要分开。文件本身放进文件仓库，数据库里只记这个文件在哪里的路径。
posts 表
─────────────────────────────────────────────
id title cover_path
1 第一篇 /uploads/2026/09/cover-1.webp
2 第二篇 /uploads/2026/09/cover-2.webp
① 画面查询 posts 读出 cover_path
② 再用那个路径单独向存储请求文件存储与第二次请求
放文件的仓库叫存储。服务小的时候可能就是服务器里的一个文件夹，大了就单独用专门的文件服务。
在这个结构里，画面要请求两次。先问后端要值、拿到路径，再用那个路径单独请求文件。浏览器遇到图片地址会自己发出第二次请求，所以不需要人操心。
把给值的一方和给文件的一方分开，还能各用各的服务器。值由擅长应答值的服务器负责，文件由擅长送文件的服务器负责。活儿性质不同，分开各自更在行。
CDN — 处理距离与频次的那一层
这里还要加一件事：距离问题。
假设图片放在美国的服务器上，而看的人在韩国。请求要顺着海底光缆横跨太平洋。一行文字倒还好，图片视频这种大块头每次都跑这么远的往返，就慢了。
所以要预先铺副本。把常用文件复制到世界各地的节点，请求来了就由离这个人最近的节点送出。这张网叫 CDN，是内容分发网络的缩写。
它也处理频次。网站 logo 每位访客都会取，而冷门文章的图片几乎没人取。前者值得一直备在近处，后者不如等请求真的来了再从源站取。替你做这个判断，就是这一层在干的事。
| 层 | 放什么 | 决定什么 |
|---|---|---|
| 数据库 | 值与文件路径 | 哪些值如何相连 |
| 存储 | 文件原件 | 放在哪里才安全 |
| CDN | 常用文件的副本 | 给谁从哪里送出 |
「网站很慢」大半从这里开始
接到变慢的反馈，容易先去翻代码。实际上多半是这一层。
要查的项目是固定的几样。图片是不是原尺寸就发出去了？画面上只显示 400 像素宽的位置却送了 4000 像素的文件，那些时间就白白扔掉了。
还要看格式。同一张图，用为网页而生的格式会轻得多。然后看距离和缓存：副本是不是从近处送出的，已经取过一次的文件有没有配置成浏览器不必再取。
打开浏览器开发者工具的网络面板，哪个文件花了多久一目了然。动代码之前先看这里，答案通常就出来了。下一篇是最后一篇，讲把这一整套搬到另一台电脑上。