数据存在哪？得看用法
你有没有遇到过这种情况：打开一个购物App，商品列表刷一下就出来了，可刚下单后刷新，订单却要等好几秒才显示？这背后很可能就是数据库和缓存的配合在作怪。
很多人觉得缓存就是数据库的“快照”，其实它们的角色完全不同。打个比方：数据库像是家里的大衣柜，所有衣服都规规矩矩挂着，找起来肯定准，但翻找费时间；而缓存更像是床头柜，只放你最近穿的几件，拿取飞快，但不可能塞下全部衣物。
数据库：永久存储的“档案室”
数据库干的是持久化的事儿。用户注册信息、订单记录、商品库存——这些必须长期保存、不能丢的数据，全都老老实实存在数据库里。哪怕服务器重启，数据还在。
常见的比如 MySQL、PostgreSQL、MongoDB，都是靠磁盘存储，读写相对较慢，但胜在可靠。每次写入都会记录日志，支持事务，保证数据一致性。
INSERT INTO users (name, email) VALUES ('张三', 'zhangsan@email.com');这条语句执行完，数据就稳稳落盘了，下次查询依然在。
缓存：临时提速的“快捷抽屉”
缓存存在的唯一目的就是快。它把数据库里常被访问的数据拷一份到内存里，下次请求直接从内存返回，速度能提升几十倍。
最常用的缓存工具是 Redis 和 Memcached。它们数据存在内存中，断电就丢，所以只适合存那些“丢了也能重新生成”的内容，比如首页轮播图、热门商品列表。
SET home_banner "{\"img\": \"url.jpg\", \"link\": \"/sale\"}" EX 300这行命令把首页广告图存进 Redis，5分钟后自动过期。既减轻了数据库压力，又让页面加载飞起。
什么时候该用哪个？
如果你在开发一个用户登录系统，密码、用户名这种核心信息必须存在数据库，这是底线。但用户头像、昵称这类不常变又频繁读取的信息，完全可以先查缓存，没有再回源数据库，查到后顺手存进缓存。
反过来，如果把订单状态全依赖缓存，万一机器重启，用户订单“消失”了，那可就出大事了。缓存可以加速读，但不能替代写。
实际项目中，常见做法是“数据库 + 缓存”搭配使用。读请求优先走缓存，命中不了再去数据库捞，然后回填缓存；写请求则先更新数据库，再主动删掉相关缓存，保证下次读取拿到最新值。
理解清楚两者的定位，才能避免把缓存当成数据库使，也不会因为死守数据库而拖垮性能。