PHP图表优化核心是缓存计算结果而非SQL,用APCu或Redis按业务+时间粒度键名存储JSON数据,数据更新时主动删键;MySQL聚合替代PHP循环;前端限制请求天数并配合懒加载。
图表加载慢,80% 情况不是前端渲染问题,而是后端每次请求都重新查库、聚合、计算——尤其涉及 GROUP BY、SUM()、时间窗口滑动统计时,MySQL 扫描几万行很常见。直接优化思路:把「结果」缓存下来,而不是缓存 SQL 或连接。
推荐用 apcu_store()(本地进程级)或 redis_setex()(分布式场景),键名建议带业务标识+时间粒度,比如:"chart:order_daily_202506"。缓存失效策略别用固定过期时间,而是在数据更新后主动删键(apcu_delete() / redis_del()),避免脏数据。
json_encode() 后的图表数据数组,体积小、反序列化快__construct() 或中间件里无条件读缓存——先判断是否命中,未命中再走计算流程if (getenv('APP_ENV') === 'local') { return $rawData; }
常见错误是查出全部明细(如 5 万条订单),再用 PHP foreach 分月/分状态统计。这既占内存又慢。正确做法是让 MySQL 直接返回聚合结果,PHP 只做轻量格式转换。
例如要画「近 30 天每日订单金额趋势」,写法应该是:
SELECT DATE(created_at) as date, SUM(amount) as total FROM orders WHERE created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY DATE(created_at) ORDER BY date;
而不是 SELECT * FROM orders WHERE ... 再 PHP 里 date('Y-m-d', $row['created_at']) 分组。
created_at 字段有索引,且类型是 DATETIME 或 TIMESTAMP,别用 VARCHAR 存时间INDEX idx_stats (created_at, region, status, amount)
WHERE 中对字段用函数,如 WHERE YEAR(created_at) = 2025 会失效索引后端缓存再快,前端强行请求一年的日粒度数据(365 条)也会卡顿,尤其用 Chart.js 渲染时 canvas 绘制压力大。得从前端配合降载。
方案一:默认只查最近 30 天,加「查看全部」按钮触发二次请求;方案二:用时间范围选择器(如 ),参数传到 PHP 时严格校验,比如 $_GET['days'] 只允许 7/30/90,超限则 400 返回。
if ($days > 180) { http_response_code(400); exit('max days: 180'); }
loading 状态遮罩,避免用户连点触发重复请求DATE_FORMAT(created_at, '%Y-%m')),数据点从 365 降到 12用 apcu_store() 却发现缓存没刷新,大概率是 PHP-FPM 配置问题。APCu 是进程内缓存,如果用 static 或 ondemand 模式,worker 进程重启后缓存就丢了;更糟的是,多个 worker 各自存一份,删一个不影响其他。
验证方式:在脚本里写 var_dump(apcu_cache_info()['num_hits'], apcu_cache_info()['num_misses']);,看命中率。若长期 num_misses 高,说明缓存根本没复用。
static 模式 + 固定 pm.max_children,并确保 apc.enable_cli=0(CLI 下不启用)"chart:v2:order_daily",升级逻辑时改版本号,自然淘汰旧缓存apcu_clear
_cache() 全局清空——影响其他业务,只删明确键名缓存和 SQL 剪枝能解决大部分图表慢的问题,但最容易被忽略的是:没有监控实际耗时。加一行 $start = microtime(true); ... $end = microtime(true); error_log("chart_gen: ".($end-$start)."s");,比猜快十倍。