在项目初期,数据表的职能设计往往都会比较简单,但随着时间的推移和业务的发展变化,表经过多次修改后,其使用方向和职能都会发生较大的变化,导致我们的系统越来越复杂。 所以,当流量超过数据库的承受能力需要做缓存改造时,我们建议先根据当前的业务逻辑对数据表进行职能归类,它能够帮你快速识别出,表中哪些字段和功能不适合在特定类型的表内使用,这会让数据在缓存中有更好的性价比。 一般来说,数据可分为四类:实体表、实体辅助表、关系表和历史表,而判断是否适合缓存的核心思路主要是以下几点: 能够通过 ID 快速匹配的实体,以及通过关系快速查询的数据,适合放在长期缓存当中; 通过组合条件筛选统计的数据,也可以放到临时缓存,但是更新有延迟; 数据增长量大或者跟设计初衷不一样的表数据,这种不适合、也不建议去做做缓存。
相关推荐
行百里er15 小时前
Redis 完结篇——Redis 热点问题在 Spring Boot 项目中实战高频因子挖掘机16 小时前
只取最近 60 个交易日,却每次拉全历史:量化脚本变慢的原因与改法孟健17 小时前
从5000亿Token到83%字节匹配:AI逆向工程与重构的工程闭环实践码事漫谈17 小时前
丢得静悄悄,谈一谈 Agent 的记忆是怎么没的迪飞特科技18 小时前
智慧物业平台实战:Spring Boot 整合小程序实现报修巡检费用全流程考虑考虑18 小时前
@JsonInclude注解使用IT_陈寒18 小时前
Vite的这个问题坑了我三天,原来如此解决!网易云信18 小时前
大模型能上岗做销售吗?我们让 12 款国产模型交了 420 份作业CCblandy18 小时前
HTTP 长连接 3 类故障实测:[WinError 10053]、99 个 TIME_WAIT、69 次多余握手,4 种对策怎么选蜗牛互联网18 小时前
Python Agent工具调用的白名单、参数校验与审批门禁