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"
使用触发器维护统计字段
适用于强一致性要求高、统计维度简单（如单条记录关联的计数）的场景，比如“每个分类下的文章数”。
DESTOON B2B网站管理系统
下载
DESTOON B2B网站管理系统是一套完善的B2B(电子商务)行业门户解决方案。系统基于PHP+MySQL开发，采用B/S架构，模板与程序分离，源码开放。模型化的开发思路，可扩展或删除任何功能；创新的缓存技术与数据库设计，可负载千万级别数据容量及访问。
- 在分类表
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 温床。
