PHP分页查数据绘散点图时必须裁剪：只查x/y两列、用游标分页、加WHERE过滤、yield返回Generator、服务端抽样（等距或分箱）、强转浮点数、禁用坐标归一化。
PHP 分页查数据时如何避免内存溢出
直接 SELECT * 查几十万行再丢给前端绘图，PHP 进程大概率会因内存超限崩溃（Fatal error: Allowed memory size exhausted）。关键不是“能不能查”，而是“要不要全查”。散点图通常只需坐标（x, y）两列，且前端渲染有上限（比如 Canvas 画 10 万点已卡顿），所以服务端必须做裁剪。
- 用
LIMIT+OFFSET或游标分页（推荐后者，避免深分页性能退化） - 只
SELECT x_column, y_column，禁用* - 加
WHERE条件缩小范围（如时间范围、状态过滤），比纯靠分页更有效 - PHP 中用
yield返回 Generator，避免一次性加载全部结果集（尤其配合 PDO::FETCH_ASSOC）
前端绘图前，PHP 要不要做数据抽样
不是“要不要”，而是“几乎必须”。浏览器 Canvas 渲染超过 5 万点就会明显卡顿，ECharts/Victory 等库内部也有默认采样逻辑。如果后端不控制，前端要么白屏，要么疯狂请求下一页——但用户根本不需要看全部点。
- 简单等距抽样：取第 1、第 N、第 2N… 行（N = 总数 / 目标点数），适合均匀分布数据
- 分箱抽样（binning）：按 x 轴分段，每段取均值/中位数+极差，更适合展示趋势（需 PHP 计算，但减轻前端压力）
- 用
ORDER BY RAND() LIMIT 1000随机抽？慎用——大数据表执行极慢，改用应用层随机索引或预生成抽样表
PHP 输出 JSON 给 ECharts 时的格式陷阱
ECharts 的 series.data 接收两种格式：[ [x1,y1], [x2,y2] ] 或 [ {name: "...", value: [x,y]} ]。PHP 数组转 JSON 时容易踩坑：
- MySQL 返回的数字是字符串（如
"123.45"），ECharts 会当文本处理导致坐标错乱；用(float)或floatval()强转 - 空值（NULL）转成
null是合法 JSON，但 ECharts 可能跳过该点；若需保留空点，显式传["-", "-"]或NaN（注意 JSON 不支持 NaN，得前端处理） - 大数组用
json_encode($data, JSON_UNESCAPED_UNICODE | JSON_INVALID_UTF8_SUBSTITUTE)防乱码和非法字符中断
为什么别在 PHP 里做坐标归一化或缩放计算
散点图的 x/y 轴范围、缩放、平移，本质是视图逻辑，应交给前端图表库（ECharts 的 grid、dataZoom 已足够健壮）。PHP 提前算好 min/max 再传给前端看似省事，实则埋雷：
立即学习“PHP免费学习笔记（深入）”；
- 分页后每页的 min/max 不同，前端无法平滑缩放（比如第 1 页 x∈[0,100]，第 2 页 x∈[1000,1100]）
- 用户拖拽、缩放时，PHP 无法实时响应，只能重新请求——体验断层
- 精度损失：PHP float 与 JS Number 在边界值上可能有微小差异（如
0.1 + 0.2 !== 0.3）
真正该由 PHP 做的，只是确保原始数值准确、类型正确、无非法字符。其余交给前端，更灵活也更可控。
