在项目初期,数据表的职能设计往往都会比较简单,但随着时间的推移和业务的发展变化,表经过多次修改后,其使用方向和职能都会发生较大的变化,导致我们的系统越来越复杂。 所以,当流量超过数据库的承受能力需要做缓存改造时,我们建议先根据当前的业务逻辑对数据表进行职能归类,它能够帮你快速识别出,表中哪些字段和功能不适合在特定类型的表内使用,这会让数据在缓存中有更好的性价比。 一般来说,数据可分为四类:实体表、实体辅助表、关系表和历史表,而判断是否适合缓存的核心思路主要是以下几点: 能够通过 ID 快速匹配的实体,以及通过关系快速查询的数据,适合放在长期缓存当中; 通过组合条件筛选统计的数据,也可以放到临时缓存,但是更新有延迟; 数据增长量大或者跟设计初衷不一样的表数据,这种不适合、也不建议去做做缓存。
相关推荐
咖啡八杯2 小时前
GoF设计模式——解释器模式掘金码甲哥2 小时前
这块终端神器, 必须吹爆!糖果店的幽灵2 小时前
【DeepAgents 从入门到精通】Context Management 上下文管理Csvn3 小时前
📊 SQL 入门 Day 8:集合操作 — 用 SQL 做数学里的"并交差"码事漫谈6 小时前
告别数据孤岛与AI“水土不服”:金仓多模融合时序库如何让数据真正服务于业务IT_陈寒6 小时前
Redis的持久化配置把我坑惨了:你以为数据安全了?星栈6 小时前
Node 接口该写同步还是异步?红烧大青虫6 小时前
HarmonyOS应用开发实战:小事记 - UIAbility 的冷启动/热启动/后台启动三种场景与 launchParam 解析码事漫谈6 小时前
AI Token 缓存:命中省 10 倍,不命中白扔钱65岁退休Coder6 小时前
LangChain v1.3.4 笔记 - 04 Agent 中间件