企业官网建设流程全解析

先说一个我自己的真实体会：不少团队做数据可视化，第一反应是选图表库、调样式、配颜色，折腾半天发现效果依然不行，最后定位到根因——从MySQL查出来的数据，根本就不是图表想要的结构。

图表组件要的是干净、规整、语义清晰的数组和对象，而业务库里存的往往是几十个字段、上百万行明细。这个中间隔着的一层，恰恰是MySQL最能发力的地方。用SQL把数据聚合成“图表友好”的形状，这件事做扎实了，可视化项目至少成功一半。这篇文章我就围绕“怎么用MySQL把可视化数据准备做到位”来展开，会包含大量可以直接抄走的SQL写法、案例和避坑经验。

1. 可视化不好看，先别怪图表库：数据形状才是根源

很多做可视化的朋友，把大量精力放在图表配置上：坐标轴怎么隐藏、图例放左边还是右边、颜色用渐变还是纯色。这些当然有影响，但真正决定一个看板高不高级的，是底层数据规整不规整。与其说在用图表库画图，不如说是在用SQL“喂数据”给图表。数据喂对了，图表库默认样式都能很耐看；数据喂错了，再怎么调参数都是白搭。

1.1 图表在等什么形状的数据？

绝大多数图表库，不管是国内的ECharts还是国外的Chart.js、Highcharts，接收的数据都可以归成几类：维度值、指标值、系列名、时间点。饼图要的就是一组“名称+数值”，柱状图要的是“分类+数值”，折线图要的是“时间点+数值”，多系列图则会多一个“系列名”用来分组。

也就是说，在MySQL里做可视化数据准备，核心任务就是：把一张宽表、乱表，通过GROUP BY、聚合函数、日期函数、窗口函数，整理成图表组件能够直接消费的二维结构。很多开发者在写SQL时只想着“把数据查出来”，没有想过“图表拿到之后怎么渲染”，于是到了前端又要Java或者Python二次加工，绕了一大圈，性能和可维护性都很差。

1.2 常见图表类型和SQL返回结构对照表

我把常用图表和它们对应的SQL返回结构整理成一个表，方便你在写查询之前先对号入座：

当你心里有了这个对照表，再去看市面上那些可视化需求，本质上就两类活：第一类是把明细变成维度+指标；第二类是让维度和指标按照图表要求的时间粒度、排序方式、过滤条件输出。这两类活，MySQL全都能干。

1.3 为什么说90%的图表问题出在SQL

我说个有点武断但很真实的结论：可视化项目里绝大多数“图不对”的情况，比如柱子串位、折线断点、饼图加起来的比例不等于100%、双轴对不上，根源都不在图表配置，而在SQL返回的数据有重复、有缺失、有类型混乱。尤其是多表JOIN之后忘了去重，明细行数翻倍，SUM出来的数字就全错了。这个我在第5部分会专门展开讲，先记住一句话：可视化SQL的第一原则是保证“行语义”正确，即每一行代表什么、唯一不唯一，必须心里有数。

只要你在SQL层面把结构、粒度、空值都处理干净，图表库那边基本不需要什么骚操作，默认配置就能出来很专业的效果。这也是“用MySQL玩转数据可视化”这句话的真正含义——重点在数据准备，不在画图。

2. 让MySQL直接吐出图表需要的JSON：JSON聚合函数实战

如果你做的是前后端分离项目，后端要把数据返给前端图表组件，传统做法是查出结果集，再在业务代码里循环拼JSON。实际上MySQL从5.7开始就支持JSON类型和相关函数，8.0进一步增强了JSON_ARRAYAGG和JSON_OBJECTAGG这类聚合函数。完全可以直接在SQL里把结果拼成图表需要的JSON结构，省掉一层中间代码。

2.1 JSON_ARRAYAGG和JSON_OBJECT的组合：饼图案例

假设有一张订单表：

CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32), user_id INT, amount DECIMAL(10,2), category VARCHAR(20), city VARCHAR(20), status TINYINT, created_at DATETIME );

我需要按订单状态做一个环形图，图表需要的数据格式是：

[ {"name": "已完成", "value": 108}, {"name": "待付款", "value": 43}, {"name": "已取消", "value": 12} ]

一种直接的写法是：

SELECT JSON_ARRAYAGG( JSON_OBJECT( 'name', CASE status WHEN 1 THEN '已完成' WHEN 2 THEN '待付款' ELSE '已取消' END, 'value', cnt ) ) AS pie_data FROM ( SELECT status, COUNT(*) AS cnt FROM orders GROUP BY status ) t;

这里有个小细节：JSON_ARRAYAGG是按分组聚合的，而子查询已经把GROUP BY的结果算好了，外层只要负责把多行拼成数组。这样返回的单行单列里就是一个可以直接塞进图表data字段的JSON字符串。前端拿到以后，连循环都不需要，直接JSON.parse之后丢给图表组件。

2.2 多系列折线图：按系列生成多层JSON

多系列折线图的格式通常是：

{ "dates": ["2024-01-01", "2024-01-02", "2024-01-03"], "series": [ {"name": "直营", "data": [3, 5, 7]}, {"name": "加盟", "data": [2, 4, 6]} ] }

要让MySQL直接产出这种结构，可以先按“日期+渠道”聚合，再用窗口函数或者分组拼接。下面是一个推荐写法：

SELECT JSON_ARRAYAGG( JSON_OBJECT( 'name', channel, 'data', ( SELECT JSON_ARRAYAGG(day_value) FROM ( SELECT DATE(created_at) AS day, SUM(amount) AS day_value FROM orders o2 WHERE o2.channel = o1.channel GROUP BY DATE(created_at) ORDER BY day ) t ) ) ) AS series_data FROM ( SELECT DISTINCT channel FROM orders ) o1;

这个写法虽然嵌套了一层关联子查询，但对数据量不大的看板完全够用，而且返回结构天然对齐图表。如果数据量大，建议不要用关联子查询，改用普通的三列结果集，在前端一次遍历分组。

2.3 版本提醒与JSON函数使用注意

使用JSON聚合函数时，有几点要特别注意：

• MySQL 5.7虽然支持JSON类型，但JSON_ARRAYAGG和JSON_OBJECTAGG是8.0才有的，5.7只能用GROUP_CONCAT拼字符串再转换，比较别扭。
• JSON_OBJECT的键名不要带中文，建议用英文键，前端再映射中文显示文案。中文键不是不能用，但在某些HTTP传输框架下容易出现编码问题，不值得冒这个险。
• 拼出来的JSON字段顺序，建议严格按照图表组件的字段顺序约定，因为有些图表库会按数组顺序渲染，顺序不一致图例就会对不上。
• 数字类型要注意：DECIMAL在JSON里会被转成带小数的数值，如果你不想要小数，提前用ROUND或者CAST处理掉。

把数据拼成JSON这个能力，在可视化项目中最大的价值不是炫技，而是把“取数+转换格式”这两步合并成一步，SQL查询结果就是最终的交付物。接口层只做透传，可维护性会明显提升。

3. 时间序列数据：日期聚合、环比同比、移动平均的SQL写法

可视化里最常用的就是时间序列，折线图、面积图、双轴图统统离不开时间。时间序列数据最大的坑有两个：一是日期粒度不对，二是日期有空洞。这两个问题不解决，折线图必断点。

3.1 按粒度聚合：日、周、月的正确打开方式

先看最基础的按日聚合：

SELECT DATE(created_at) AS day, SUM(amount) AS total_amount FROM orders WHERE created_at >= CURDATE() - INTERVAL 29 DAY GROUP BY DATE(created_at) ORDER BY day;

这里要注意DATE(created_at)和DATE_FORMAT(created_at, '%Y-%m-%d')的区别。前者返回DATE类型，排序、比较都方便；后者返回字符串，看着像但排序容易出问题。能用DATE()就不用字符串格式化。

按周聚合，我用的是周一到周日作为自然周：

SELECT YEARWEEK(created_at, 1) AS week, SUM(amount) AS total_amount FROM orders GROUP BY YEARWEEK(created_at, 1) ORDER BY week;

YEARWEEK的第二个参数1表示周从周一开始，这是国内比较常用的口径。如果业务上用的是周日开始，参数改为0就行。很多看板周数据对不上，基本都是这里口径不一致导致的。

按月聚合更简单：

SELECT DATE_FORMAT(created_at, '%Y-%m') AS month, SUM(amount) AS total_amount FROM orders GROUP BY DATE_FORMAT(created_at, '%Y-%m') ORDER BY month;

3.2 用窗口函数算环比、同比和移动平均

MySQL 8.0引入了窗口函数，这对时间序列分析是质的提升。以前算环比要么写子查询自连接，要么取出来在程序里算，现在一条SQL就能搞定：

SELECT DATE_FORMAT(created_at, '%Y-%m') AS month, SUM(amount) AS total_amount, LAG(SUM(amount), 1) OVER (ORDER BY DATE_FORMAT(created_at, '%Y-%m')) AS prev_month_amount, ROUND( (SUM(amount) - LAG(SUM(amount), 1) OVER (ORDER BY DATE_FORMAT(created_at, '%Y-%m'))) / LAG(SUM(amount), 1) OVER (ORDER BY DATE_FORMAT(created_at, '%Y-%m')) * 100, 2 ) AS mom_ratio FROM orders GROUP BY DATE_FORMAT(created_at, '%Y-%m') ORDER BY month;

同比就把LAG的偏移改成12，前提是数据按月连续。这里有个重要提醒：LAG是按行顺序取上一行的值，如果中间有月份缺失，它取到的不是上个月，而是上一条记录。所以用窗口函数算环比同比之前，最好确保时间维度是连续的，不连续就先补日期。

移动平均（比如7日平均）用窗口函数的行范围来写：

SELECT DATE(created_at) AS day, SUM(amount) AS total_amount, AVG(SUM(amount)) OVER ( ORDER BY DATE(created_at) ROWS BETWEEN 6 PRECEDING AND CURRENT ROW ) AS moving_avg_7d FROM orders GROUP BY DATE(created_at) ORDER BY day;

这里的ROWS BETWEEN 6 PRECEDING AND CURRENT ROW表示取当前行和前面6行的值求平均，正好是7天。需要注意，窗口函数和GROUP BY一起用时，窗口函数是在分组聚合之后才计算的，所以AVG(SUM(amount))这种写法是合法的，别慌。

3.3 日期空洞补零：用递归CTE生成连续日期序列

如果某天没有订单，上面查询返回的行里就会缺少那一天，折线图画出来就是断的。补零的通用思路是：生成一个连续日期序列，再左连接聚合结果。

MySQL 8.0可以用递归CTE生成日期序列，SQL写起来干净多了：

WITH RECURSIVE date_range AS ( SELECT CURDATE() - INTERVAL 29 DAY AS day UNION ALL SELECT day + INTERVAL 1 DAY FROM date_range WHERE day < CURDATE() ) SELECT dr.day, COALESCE(t.total_amount, 0) AS total_amount FROM date_range dr LEFT JOIN ( SELECT DATE(created_at) AS day, SUM(amount) AS total_amount FROM orders WHERE created_at >= CURDATE() - INTERVAL 29 DAY GROUP BY DATE(created_at) ) t ON dr.day = t.day ORDER BY dr.day;

这个SQL把“没有数据的日期补0”这件事在数据库层面就完成了，前端拿到的是连续完整的时间序列。注意递归CTE默认有1000次的递归上限，生成30天、365天的序列没问题，但如果是几年级别的可能要用SET cte_max_recursion_depth调大上限。

补零这个操作，看起来是小细节，但对图表的观感影响极大。一张有断裂的折线图和一张平滑连续的折线图，业务方对数据质量的信任度是完全不同的。

4. 一整套销售看板Demo：从建表到图表配置一次打通

前面讲了不少零散的SQL写法，这一节我串一个完整的Demo——模拟一套销售看板，从建表、造数、写查询到最终对接图表配置，把整个链路走一遍。你完全可以照着这个结构去套自己的业务。

4.1 造一张订单表和一批模拟数据

为了方便测试，先造表再插数据：

CREATE TABLE sales_orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32), user_id INT, product_name VARCHAR(32), category VARCHAR(20), city VARCHAR(20), amount DECIMAL(10,2), status TINYINT, channel VARCHAR(10), created_at DATETIME, KEY idx_created_at (created_at), KEY idx_category (category) ); INSERT INTO sales_orders (order_no, user_id, product_name, category, city, amount, status, channel, created_at) SELECT CONCAT('SO', LPAD(seq, 8, '0')), seq, CONCAT('商品', seq % 20), ELT(MOD(seq, 5) + 1, '家电', '数码', '服饰', '食品', '日用'), ELT(MOD(seq, 8) + 1, '北京', '上海', '广州', '深圳', '杭州', '成都', '武汉', '南京'), ROUND(RAND() * 500 + 50, 2), MOD(seq, 3) + 1, ELT(MOD(seq, 3) + 1, '直营', '加盟', '电商'), DATE_SUB(NOW(), INTERVAL seq DAY) FROM ( SELECT @rownum := @rownum + 1 AS seq FROM information_schema.tables t1, information_schema.tables t2, (SELECT @rownum := 0) r LIMIT 300 ) seq_gen;

一共造300条近300天的订单，量级不大，但足够覆盖我们Demo里所有查询场景。注意我把created_at和category都建了索引，这是后面性能能扛住的基础。

4.2 需求拆解和对应的查询SQL

现在假设业务方提了四个看板需求：

第一个是总销售额大数字卡片，直接一条SUM：

SELECT SUM(amount) AS total_amount, COUNT(*) AS order_cnt FROM sales_orders;

第二个是近30天每日销售额趋势折线图：

SELECT DATE(created_at) AS day, SUM(amount) AS total_amount FROM sales_orders WHERE created_at >= CURDATE() - INTERVAL 29 DAY GROUP BY DATE(created_at) ORDER BY day;

第三个是类别占比环形图：

SELECT category AS name, ROUND(SUM(amount), 2) AS value FROM sales_orders GROUP BY category ORDER BY value DESC;

第四个是城市销售额Top8柱状图：

SELECT city, ROUND(SUM(amount), 2) AS total_amount FROM sales_orders GROUP BY city ORDER BY total_amount DESC LIMIT 8;

这四个查询覆盖了大数字、折线、饼图、柱状图四类最常见组件，而且每个查询返回的结构都和图表组件的数据接口一一对应。

4.3 多系列扩展：按日、按渠道同时看趋势

业务方往往不满足于看总量，还要看拆分。比如近30天直营和加盟两条线对比，SQL加一个渠道维度即可：

SELECT DATE(created_at) AS day, channel AS series, SUM(amount) AS value FROM sales_orders WHERE created_at >= CURDATE() - INTERVAL 29 DAY AND channel IN ('直营', '加盟') GROUP BY DATE(created_at), channel ORDER BY day, channel;

返回的三列结果，前端遍历一次按series分组，就能得到多系列折线图的数据。这种方式比用JSON_ARRAYAGG嵌套子查询的方式对大数据量更友好，也更容易让后端同学理解和维护。

4.4 前端图表配置对接示例

以ECharts为例，折线图的核心配置大概是这样的：

const response = await fetch('/api/sales/trend'); const rows = response.data; // [{day:'2024-06-01', series:'直营', value: 120}, ...] const dates = [...new Set(rows.map(r => r.day))]; const seriesNames = [...new Set(rows.map(r => r.series))]; const seriesData = seriesNames.map(name => ({ name, type: 'line', data: dates.map(day => { const item = rows.find(r => r.day === day && r.series === name); return item ? item.value : 0; }) })); const option = { xAxis: { type: 'category', data: dates }, yAxis: { type: 'value' }, series: seriesData };

注意我在这段代码里做了补零——item ? item.value : 0，这一步是为了防止MySQL返回的数据缺失某一天。理论上SQL侧用递归CTE补零更彻底，前端再兜底一次，双保险，图表就永远不会断线。这个习惯我做了很多年，基本没出过问题。

5. 我用MySQL做可视化数据时踩过的五个隐蔽坑

做可视化数据准备这么多年，有些坑反复遇到，而且都不是什么高深理论，全是实操里容易忽略的细节。我把最典型的五个整理出来，每一个都值得你在自己的项目里自查一遍。

5.1 多表JOIN导致的行数放大：SUM翻倍还不自知

这是可视化统计里最常见的错误。比如订单表和订单明细表JOIN，一条订单有3条明细，直接JOIN之后再SUM订单金额，订单金额就被算了3遍。这种错误特别隐蔽，因为图表看起来有变化，只是数值比实际高，业务方如果记得大概量级还能发现，不记得就直接上线了。

正确做法是：先把明细表按订单ID聚合好再去JOIN订单表，或者直接在明细表上算指标，避免多表JOIN后直接聚合。举个例子，错误的写法：

-- 错误示范：订单金额被明细行数放大 SELECT o.user_id, SUM(o.amount) AS total_amount FROM orders o JOIN order_items i ON o.id = i.order_id GROUP BY o.user_id;

改成先在明细层聚合：

SELECT o.user_id, SUM(o.amount) AS total_amount FROM orders o JOIN ( SELECT order_id, SUM(item_amount) AS item_total FROM order_items GROUP BY order_id ) i ON o.id = i.order_id GROUP BY o.user_id;

这能保证订单金额只被计算一次。可视化项目里，每次SUM之前都要问自己一句：这个表JOIN之后行数变了吗？变了，就要么去重，要么先聚合再JOIN。

5.2 ONLY_FULL_GROUP_BY模式：SELECT列不在GROUP BY里直接报错

MySQL 5.7之后默认开启ONLY_FULL_GROUP_BY，也就是SELECT出来的非聚合字段必须出现在GROUP BY里。这个约束本质上是在保护你，避免聚合结果里出现随机值。但很多从5.6过来的老开发不适应，常常报错。

报错信息一般是这样的：

Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column...

解决办法不是去修改sql_mode把ONLY_FULL_GROUP_BY关掉，而是规范写法。如果确实需要SELECT一个不在GROUP BY里的字段，比如想取订单表中某个用户的最近订单时间，就改用窗口函数或者子查询：

SELECT user_id, MAX(created_at) AS last_order_time FROM orders GROUP BY user_id;

这条没问题，因为MAX是聚合函数。但如果想取最近一单的订单号，写SELECT user_id, order_no ... GROUP BY user_id就会报错。这种情况可以这样：

SELECT user_id, order_no FROM ( SELECT user_id, order_no, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders ) t WHERE rn = 1;

把SQL写规范，比改数据库配置靠谱一万倍。改sql_mode一时爽，后面埋雷的概率非常大。

5.3 NULL和0的语义陷阱：饼图统计口径全错

可视化里NULL和0是两回事。COUNT一个全是NULL的字段会得到0，但SUM一个包含NULL的字段会有个奇特的行为：NULL会被直接跳过，不参与计算也不报错。这意味着，如果金额字段为NULL，SUM出来的值可能比实际“小”，但你在图上根本看不出区别。

看一个典型场景：统计各渠道订单金额占比，某渠道的金额字段存在NULL，SUM时会自动忽略，占比算出来就不对。更麻烦的是，饼图上有些图表库会把NULL对应的分类直接不渲染，导致所有分类加起来不等于100%。

在SQL里提前处理是关键：

SELECT channel, SUM(COALESCE(amount, 0)) AS total_amount FROM orders GROUP BY channel;

COALESCE把NULL转成0，这样SUM就不会漏数据。另外，统计人数用COUNT(DISTINCT user_id)时，NULL用户会被忽略，如果你统计的是登录用户就没问题，但如果要统计所有访问者，就得用COUNT(DISTINCT COALESCE(user_id, id))之类的手段把NULL顶上。

5.4 日期时区不一致：图上前几天数据对不上

时区问题在可视化中的常见表现是：每天早上看昨日数据，发现少了几小时的量。原因通常是数据库连接串没指定时区，或者服务器时区是UTC，业务时间存的是UTC时间，而看板按北京时间展示。

处理这类问题的统一思路是：存什么就按什么查，展示口径单独转。如果表里存的就是UTC时间，查询时用CONVERT_TZ做转换：

SELECT DATE(CONVERT_TZ(created_at, '+00:00', '+08:00')) AS day, SUM(amount) AS total_amount FROM orders GROUP BY DATE(CONVERT_TZ(created_at, '+00:00', '+08:00'));

这个写法对索引不友好，因为对字段用了函数以后，idx_created_at就失效了。更稳妥的做法是建表时把created_at直接建成业务时区的时间，或者查询时先用时间范围过滤（范围条件可以用索引），再做时区转换。总之，先按索引过滤，再在SELECT里做展示层的转换。

5.5 COUNT(DISTINCT)在大数据量下慢到怀疑人生

COUNT(DISTINCT)本身是精确去重统计，但在几千万行上跑，性能非常差。可视化看板里如果高频刷新精确UV、唯一用户数这类指标，数据库压力会非常大。

几种优化思路：如果业务能接受近似值，用APPROX_COUNT_DISTINCT函数（MySQL 8.0.13开始支持）——它会用HyperLogLog算法估算，误差通常在1%到2%，速度提升非常明显。如果必须精确，那就把明细数据提前预处理，比如每天凌晨跑一次定时任务，把UV写进汇总表，看板只查汇总表，不要直接查明细。

示例：

-- 大数据量下用近似去重加速 SELECT APPROX_COUNT_DISTINCT(user_id) AS approx_uv FROM user_visit_log WHERE visit_date = CURDATE();

我自己的原则是：可视化甩大屏的场景，绝大多数指标都能用预聚合解决；真要实时精确去重，那不是MySQL的强项，换个专门的数据库引擎更合适，别在MySQL上死磕。

6. 查询越来越慢？可视化数据供给的性能优化思路

可视化看板有一个特点：同一批SQL会以很高频次反复执行。业务库可能一天跑一次报表，大屏是每5秒刷一次。这导致同样的查询要在MySQL上反复跑，如果不做性能优化，数据库迟早被拖垮。

6.1 索引设计的核心：过滤条件优先，分组列跟上

可视化SQL一般长这样：WHERE里面有时间范围，GROUP BY里面有维度列。针对这种模式，索引设计有一条基本法则：把WHERE里的等值条件和范围条件放在索引前面，GROUP BY或排序字段跟在后面。

比如查询某个城市近30天的销售汇总：

SELECT DATE(created_at) AS day, SUM(amount) AS total_amount FROM sales_orders WHERE city = '上海' AND created_at >= CURDATE() - INTERVAL 29 DAY GROUP BY DATE(created_at);

推荐的联合索引是：

CREATE INDEX idx_city_created ON sales_orders(city, created_at);

这样MySQL可以先通过city = '上海'快速定位数据范围，再通过created_at范围条件和分组排序，避免全表扫描。

但要注意，GROUP BY DATE(created_at)里对created_at套了函数，索引对分组操作可能失效，不过因为WHERE已经用created_at过滤了一大片数据，剩下的量级分组压力不大。如果你有时间，可以试试把created_at存成DATE类型，或者再加一个day_date列专门用于分组，索引效果会更好。

6.2 避免SELECT *：拖慢查询的不只是网络，还有临时表

很多开发习惯写SELECT *，这在可视化场景里特别坑。一个订单表可能30个字段，图表只需要金额和状态两个字段，结果你把用户详情、备注、地址全查出来了。MySQL执行时如果排序或分组需要临时表，这些大字段都会被带进去，占用内存和磁盘，速度自然慢。

可视化SQL的基本原则是只查需要的列。比如做图只需要三列，SQL就只写三列。此外，如果发现查询计划里出现了Using temporary或者Using filesort，要特别关注，因为这两个往往意味着MySQL在磁盘上做临时排序，性能会断崖式下跌。EXPLAIN一下：

EXPLAIN SELECT city, SUM(amount) FROM sales_orders WHERE created_at >= '2024-06-01' GROUP BY city;

看输出里的Extra列，如果出现Using index condition是好事，如果出现Using temporary; Using filesort就要考虑调整索引或者改写SQL。

6.3 预聚合表：看板性能问题的终极解法

可视化看板如果数据量过了几百万，而且大量指标是固定的，直接查明细就是给自己挖坑。我强烈建议做一张“预聚合表”，把常用的维度组合和指标先算好，看板只查这张小表。

比如做销售看板，建一张日维度汇总表：

CREATE TABLE daily_sales_summary ( stat_date DATE, city VARCHAR(20), category VARCHAR(20), channel VARCHAR(10), order_cnt INT, total_amount DECIMAL(12,2), PRIMARY KEY (stat_date, city, category, channel) );

然后定时任务每天凌晨把前一天的数据汇总进去：

INSERT INTO daily_sales_summary (stat_date, city, category, channel, order_cnt, total_amount) SELECT DATE(created_at), city, category, channel, COUNT(*), ROUND(SUM(amount), 2) FROM sales_orders WHERE created_at >= CURDATE() - INTERVAL 1 DAY AND created_at < CURDATE() GROUP BY DATE(created_at), city, category, channel;

这张汇总表可能只有几千行，查起来毫秒级。大屏频繁刷新完全没压力。等到要看更细的维度，比如某天某个SKU的明细时，再单独走明细查询，把这种偶发查询挡在预聚合之外。

预聚合表这种思路，本质上是用空间换时间，用一次性的批处理代价，换取整个可视化系统的高性能。做可视化项目的团队如果不上预聚合，靠死磕MySQL优化，迟早会碰到天花板。

6.4 避免看板查询之间互相干扰：读写分离和超时控制

一个容易被忽视的问题是：大屏端查询一旦写的很烂，会拖垮同库的在线业务。生产环境建议把可视化查询放到从库上跑，或者至少给看板查询设置max_execution_time超时控制。

MySQL 8.0可以给单条查询设置执行超时：

SELECT /*+ MAX_EXECUTION_TIME(3000) */ city, SUM(amount) FROM sales_orders GROUP BY city;

超过3秒直接终止，避免慢查询一直占着连接。可视化场景里，一个查询超过3秒本身就该被优化，加个超时是对数据库的自我保护。把慢查询日志也打开，定期review那些排在前面的大查询，基本能把可视化数据供给的性能问题消灭在萌芽阶段。

7. 不想写前端时，用Grafana直连MySQL给自己搭个监控盘

并不是所有可视化都需要自己开发前端。如果你只是想看系统指标、订单趋势、错误数量这类运营监控，Grafana直接连MySQL数据源，几分钟就能出一个专业大盘。这算是我个人比较喜欢的MySQL可视化玩法，因为完全不用写代码。

7.1 Grafana和MySQL的对接配置

在Grafana里添加MySQL数据源，关键配置有四项：地址、端口、数据库名、账号权限。账号建议用一个只读账号，权限只要SELECT，避免可视化账号误写数据。

CREATE USER 'grafana_reader'@'%' IDENTIFIED BY '强密码'; GRANT SELECT ON mydb.* TO 'grafana_reader'@'%';

这样即使Grafana被拖库，业务数据也只会被读，不会被改。

数据源配置完成后，新建Panel选MySQL查询类型。Grafana对MySQL有一个宏变量的体系，最常用的是$__timeFilter和$__timeGroup，它们会自动把你选择的Panel时间范围拼到SQL里。

7.2 用宏变量写一个订单量趋势面板

Panel查询示例：

SELECT $__timeGroup(created_at, '1h') AS time, COUNT(*) AS order_cnt FROM sales_orders WHERE $__timeFilter(created_at) GROUP BY 1 ORDER BY 1;

$__timeGroup(created_at, '1h')会自动把created_at按小时分组，$__timeFilter(created_at)会自动加上时间范围条件。这样你在Grafana右上角切换“最近24小时”“最近7天”，图表的粒度会自动适配，不需要手动改SQL。

类似地，做一个状态分布饼图，直接用查询返回name和value：

SELECT CASE status WHEN 1 THEN '已完成' WHEN 2 THEN '待付款' ELSE '已取消' END AS name, COUNT(*) AS value FROM sales_orders WHERE $__timeFilter(created_at) GROUP BY status;

Grafana会自动把两列映射成饼图的数据。整个过程不用写一行前端代码，而且大盘的刷新频率、告警规则、分享链接这些，Grafana都内置好了。

7.3 Grafana的局限和适用边界

Grafana适合的是“监控型”可视化：系统指标、业务趋势、错误量、接口耗时。它的图表类型相对固定，不适合做复杂的分析型可视化，比如交互式下钻、自定义布局、复杂报表。当业务方要的是那种像素级还原的BI大屏时，Grafana就不够用了，还是得回到自研前端+MySQL取数这条路。

我的经验是：能用Grafana的场景，就别自己造轮子；需要定制化时，再回到SQL取数 + 图表库的路线。两条路都以MySQL为核心，前者省开发量，后者保灵活性，按需选择。

做MySQL可视化这么久，我最深的一个体会是：无论前端图表库多花哨，数据部分的SQL写得好不好，才是决定一个可视化项目成败的隐藏变量。只要把数据形状理清楚、把坑踩明白、把性能优化做到位，MySQL完全能够支撑起从监控大盘到业务分析报表的一大片可视化需求。希望这篇文章里那些可以直接照抄的SQL和避坑经验，能帮你少走一些我当年走过的弯路。