Memcached 比数据库快因数据全在内存、无磁盘I/O和SQL解析，get通常≤100μs，比MySQL快约100倍；需确保存热数据、key设计合理，并防范缓存穿透与过期误用。
为什么 memcached 比直接查数据库快得多
因为数据全在内存里，没有磁盘 I/O 和 SQL 解析开销。一次 get 通常在 100μs 内完成，而简单查询 MySQL 可能要 5–20ms —— 差两个数量级。但前提是：你存的是「热数据」，且 key 设计得当。
常见错误现象：get 返回 None 却没检查过期时间或是否真存进去了；缓存穿透导致大量请求直击数据库。
- 用
set(key, value, time=300)显式设过期，别依赖默认值（某些客户端默认永不过期） - key 必须是字符串，
user_id=123要转成"user:123"，别用str({"id": 123})这种不可控格式 - value 推荐用 JSON 序列化后的 bytes，避免 pickle（不安全、跨语言不兼容）
Python 中怎么安全接入 python-memcached
它轻量、成熟，支持连接池和自动重连，比 pylibmc 更少出奇奇怪怪的 segfault。但要注意：它默认不校验服务器响应，网络抖动时可能静默失败。
使用场景：Django/Flask 接口层做结果缓存，不适合存大对象（单 value 限制默认 1MB）。
立即学习“Python免费学习笔记（深入）”；
- 初始化时加
socket_timeout=1和connect_timeout=0.5，避免卡住整个请求 - 用
cache = memcache.Client(['127.0.0.1:11211'], debug=0)，debug=1 会打日志，线上必须关 - 调用
cache.get()后务必判空：if data is None: data = fetch_from_db(); cache.set(...)
get_multi 和逐个 get 的性能差距有多大
10 个 key 查一次 get_multi，耗时≈1 次 RTT；逐个 get 就是 10 次 RTT + 10 次解析开销。实测在千兆内网下，10 key 的 get_multi 约 0.8ms，逐个是 6–8ms。
参数差异：get_multi(['user:1', 'user:2', 'post:100']) 返回 dict，缺失 key 不出现，不是 None。
- 别对动态生成的长列表无脑用
get_multi，memcached 单次请求有包大小限制（默认 1MB），超了会静默截断 - 如果部分 key 缓存未命中，别立刻 fallback 到逐个查库 —— 先 collect 缺失 key，再
get_multi查库结果，减少 DB 压力 - 注意 Python 3 下传入的 keys 必须是
str，不能是bytes，否则返回空 dict
缓存失效策略选 delete 还是 set 覆盖
写多读少时用 delete，避免脏数据残留；读多写少且更新频繁时，用带版本号的 set 更稳妥。直接 set 覆盖看似简单，但并发更新可能把旧值写回去（“ABA 问题”）。
容易踩的坑：用 cache.delete("user:*") 想批量删 —— memcached 不支持通配符，这行代码完全没效果。
- 更新用户资料后，优先
delete("user:123")，下次读自动重建，而不是set("user:123", new_data) - 需要强一致性？加一个简单版本号字段，比如
"user:123:v2"，更新时递增 v，并让所有读逻辑感知该版本 - 永远不要在事务中依赖缓存状态 —— memcached 无事务，
delete成功不代表 DB 提交成功
最麻烦的不是怎么设缓存，而是怎么清理缓存。key 命名一旦嵌套层级深、拼接逻辑散落在多处，改一处漏三处就成常态。建议把 key 构造逻辑收拢到一个函数里，比如 cache_key("user", user_id)，别到处写 f"user:{uid}"。
