SQL查询无内置缓存，需应用层用Cache-Aside模式实现：先查缓存，未命中则查DB并回写；key须唯一标识语义，value序列化为JSON；写操作采用“先更新DB再删缓存”，失败须重试；防穿透雪崩需空结果缓存、TTL加偏移、布隆过滤器等。
SQL 查询本身不带缓存能力，必须由应用层主动把“查什么”和“结果是什么”对应起来存到缓存里；否则数据库每次都要重跑 SQL，压力白增。
用 Cache-Aside 模式控制读路径最稳
这是绝大多数业务落地的默认选择：先查缓存，没命中再查数据库，查完顺手写回缓存。它不依赖数据库自动缓存（MySQL 的 query cache 已被弃用），也不强求缓存和 DB 同时更新，可控性高。
- 缓存 key 要能唯一标识查询语义，比如
f"users:{user_id}"或f"orders:{user_id}:{status}"，别用 raw SQL 字符串——参数顺序、空格、换行都可能让 key 不一致 - 缓存 value 推荐序列化为 JSON，但得确保模型有
to_dict()或用pydantic转换，避免直接存sqlalchemy.orm.state.InstanceState这类不可序列化对象 - 读接口里别写“查缓存 → 查 DB → 写缓存 → 返回”四步全在一条请求里完成；高并发下容易因缓存未命中引发雪崩，要加
redis.lock或本地互斥锁兜底
写操作后只删缓存，别更新缓存
更新缓存看似省事，实则埋雷：两个服务同时改同一条数据，A 更新缓存、B 更新 DB、C 又更新缓存……最终缓存值可能比 DB 还新，或中间混入脏数据。删缓存是更安全的“懒加载”起点。
PHP 5 网站快速开发
下载
可以学到如何使用PHP5显示动态网页，构建联系人管理系统、产生客户报告、与XML协同工作等，英文，原名称PHP 5 Fast and Easy Web Development
- 务必采用「先更新 DB，再删缓存」顺序，删失败必须进重试队列（如
celery.delay(delete_cache_key, key)），不能静默吞掉异常 - 对强一致性要求高的场景（如用户余额），删完缓存后可额外加一层「主库直读校验」：删完立刻从主库查一次，对比旧缓存值是否已变，不一致就强制刷新
- 避免用
UPDATE ... RETURNING一类语句顺手塞缓存——DB 层看不到缓存服务状态，失败无感知，一致性彻底失控
Redis 缓存键设计要防穿透、防雪崩
key 设计不是技术问题，是业务风险问题。一个非法 user_id 导致大量空查询打穿缓存直击 DB，就是穿透；几百个 key 同时过期引发瞬时流量洪峰，就是雪崩。
- 空结果也得缓存，但 TTL 设短些，比如
r.setex(key, 120, json.dumps(None))，配合布隆过滤器拦截明显无效 ID（如负数、超长字符串） - TTL 别写死，加随机偏移：
ttl = 300 + random.randint(0, 300)，防止批量 key 集中失效 - 别把整个列表塞一个 key（如
all_orders），按分页维度拆：orders:uid_123:page_1，更新单条订单只删对应页，不影响其他缓存
真正难的从来不是“怎么把数据塞进 Redis”，而是想清楚哪条 SQL 值得缓、缓多久、谁来负责删、删失败怎么办——这些决策藏在业务逻辑深处，代码里看不见，但系统一抖动，它们立刻浮出水面。
