17370845950

MySQL无内置统计缓存，但可通过汇总表预计算、Redis缓存聚合结果、触发器维护统计字段等方式实现；需重点保障缓存与源数据一致性。

MySQL 中不直接提供“统计缓存”功能，但可以通过合理设计，在应用层或数据库层实现高效、可控的统计结果缓存，避免每次查询都实时聚合大量数据。核心思路是：把耗时的 GROUP BY、COUNT、SUM 等聚合结果预先算好、存起来，并在数据变更时及时更新。

用汇总表（Summary Table）做预计算

这是最常用也最可靠的方式：单独建一张表，只存统计结果，比如用户每日订单数、商品总销量等。

• 每天凌晨用定时任务（如 MySQL Event 或外部脚本）执行 INSERT INTO summary_orders SELECT DATE(create_time), COUNT(*), SUM(amount) FROM orders WHERE create_time >= 'yesterday' GROUP BY DATE(create_time)
• 查询时直接查 summary_orders，毫秒级响应
• 支持加索引（如 (date) 或 (date, status)），查询极快
• 注意：需配合业务逻辑保证源表更新时同步刷新对应汇总行（例如新订单插入后，立即 UPDATE summary_orders SET count = count + 1 WHERE date = CURDATE()）

利用 Redis 缓存聚合结果

适合变化不频繁、但查询非常频繁的统计场景，比如首页显示“当前在线用户数”“热门文章 TOP10”。

• 应用层首次请求时执行 SQL 聚合，将结果（如 JSON 字符串或哈希结构）写入 Redis，设置合理过期时间（如 30 分钟）
• 后续请求先查 Redis，命中则直接返回；未命中再查库并回填缓存
• 关键点：在数据变更（如用户登出、文章被点赞）时，主动失效或更新 Redis 中对应 key，避免脏数据
• 示例命令：SET stat:online_users 12412487 EX 1800 或 ZADD stat:hot_articles 98.5 "article:1024"

使用触发器维护统计字段

适用于强一致性要求高、统计维度简单（如单条记录关联的计数）的场景，比如“每个分类下的文章数”。

• 在分类表 categories 中增加 post_count INT DEFAULT 0 字段
• 在文章表 posts 上创建 INSERT/DELETE 触发器，自动增减对应分类的 post_count
• 查询分类列表时，直接 SELECT id, name, post_count FROM categories，无需 JOIN 或子查询
• 注意：触发器会略微增加写入开销，且跨库或复杂逻辑不易维护，不推荐用于多维、多表联合统计

借助 MySQL Query Cache（已弃用，仅作了解）

MySQL 5.7 及以前版本曾支持 Query Cache，对相同 SELECT 自动缓存结果。但8.0 版本已完全移除，且实际中问题较多：

• 任何表有写入，该表所有相关缓存全部失效，热点表下效率极低
• 缓存键区分大小写、空格、注释，容易重复缓存
• 无法按业务逻辑控制失效时机，不可靠
• 不建议新项目使用，老系统升级时需主动替换为其他方案

不复杂但容易忽略的是缓存与源数据的一致性保障。无论选哪种方式，都要明确“谁负责更新”“什么时候更新”“失败怎么兜底”，否则缓存就成了 bug 温床。