在项目初期,数据表的职能设计往往都会比较简单,但随着时间的推移和业务的发展变化,表经过多次修改后,其使用方向和职能都会发生较大的变化,导致我们的系统越来越复杂。 所以,当流量超过数据库的承受能力需要做缓存改造时,我们建议先根据当前的业务逻辑对数据表进行职能归类,它能够帮你快速识别出,表中哪些字段和功能不适合在特定类型的表内使用,这会让数据在缓存中有更好的性价比。 一般来说,数据可分为四类:实体表、实体辅助表、关系表和历史表,而判断是否适合缓存的核心思路主要是以下几点: 能够通过 ID 快速匹配的实体,以及通过关系快速查询的数据,适合放在长期缓存当中; 通过组合条件筛选统计的数据,也可以放到临时缓存,但是更新有延迟; 数据增长量大或者跟设计初衷不一样的表数据,这种不适合、也不建议去做做缓存。
相关推荐
IT规划师18 分钟前
编程术语中的同步与异步:从"等不等"到工程取舍孟陬1 小时前
Foobar 技术周刊#159:当看不懂代码时,如何高效排障调试。脏页陷阱:一条只读查询,写入数 TB 数据。推测解码:大模型加速利器GoGeekBaird1 小时前
别再给每个 AI 做自我介绍了:我做了一个「个人上下文」管理系统码事漫谈1 小时前
腾讯混元 Hy4 正式版发布了Mikko71 小时前
Redis 连接数满了服务端有错误信息吗?连接数不增加却命令超时?6.2 实测连接池、超时与大 key 怎么判定苍何3 小时前
DeepSeek的Super-agent 设计,和我们的工程实践Patrick_Wilson3 小时前
第一次读 Go 项目:从两个源码文件弄清 package、import 和 go.modPatrick_Wilson3 小时前
执行 go build . 后,Go 怎样找到代码并生成程序用户6919026813393 小时前
Redis 2:Redis 在怎么处理harness记忆Patrick_Wilson3 小时前
Go 变量不赋值时,为什么也有值