企业官网建设流程全解析

MySQL数据可视化这事儿，表面上看是给业务方画几张折线图、饼图，真正做起来才知道，最大的工作量从来不在图表库的配置上，而在“怎么把MySQL里的数据稳妥、准确、按时地喂到图表那一层”。我陆陆续续接过好几个看板项目，也帮同事排查过各类“报表又卡了”“数字怎么对不上”的工单，踩过的坑叠起来比需求文档还厚。这篇文章不聊那些PPT级别的架构图，只聊我在MySQL数据可视化实战里真正用得上的技巧：怎么取数不容易把业务库拖垮，怎么写SQL能让图表秒开，出了问题又该怎么一步步定位。

不管你是刚接触数据可视化的后端开发、运维，还是需要自己搭报表的业务同学，下面这些内容基本覆盖了从取数口径到图表刷新的完整链路。有些结论可能和你平时听说的不太一样，但都是我实际验证过的。

1. 从一个“卡死的报表”说起：MySQL可视化最常见的三种死法

1.1 业务方要数，研发为什么头疼

大部分MySQL可视化项目都不是从“这个图好看”开始的，而是业务方甩过来一句话：“把咱们的销售数据做成大屏，领导明天要看。”听上去很简单，可一旦开始做，你会发现真正要回答的问题一大堆：谁看这个数据？他关心哪些指标？数据多久刷新一次？需不需要下钻到省份、城市？同环比怎么算？

这些问题没聊清楚之前就动手建图表，基本等于埋雷。我见过最典型的场景是，开发同学半天就把页面搭出来了，数据也通了，结果业务方看完第一眼就问：“今天的销售额怎么和财务报给我的不一样？”这就是口径问题，不是技术问题，但它会让整个项目瞬间停顿。

所以我现在有个习惯，不管需求多急，都要先花半天把指标口径和刷新频率定下来，甚至写成一张简单的表格发给业务方确认。这一步省下来的返工时间，远大于你画图的时间。

1.2 死法一：直连数据库跑大SQL

这是新手最容易踩的坑。很多可视化工具都支持“直连数据库”，输入MySQL地址、账号密码，然后在界面上拖几个字段就能出图。确实方便，但问题在于，拖拽生成的查询往往没有经过优化，一次图表刷新可能就是把整张几千万行的明细表拉出来聚合一遍。

我见过一个运营看板，一共8张图，每张图都直连生产库，每5秒刷新一次。高峰期数据库连接直接被打满，业务线正常的订单写入都开始超时。运维半夜打电话给我，说MySQL报警了。查了半天才定位到是可视化工具在不停发查询。

直连没问题，但你要知道自己在干什么。给可视化工具用的查询，思想应该是“尽早在MySQL里把数据缩减到最小”，能查聚合后的结果就不查明细，能查一天就不查一年。另外生产库和大屏之间，至少隔一层只读账号、只读实例或者预聚合表，别让业务核心链路为看板数据陪跑。

1.3 死法二：图都画出来了，数字对不上

比性能问题更让人崩溃的是，图表确实显示出来了，但是上面的数字怎么都对不上。销售额这个简单的指标，至少有三种算法：按下单时间算、按支付时间算、按退款后的净额算。你按支付时间聚合，财务按开票时间聚合，业务按订单创建时间看数，三套数字放在一起，对比永远是乱的。

这个问题几乎每个MySQL可视化项目都会遇到，而且越到后期越难改，因为图表已经上线，业务方已经习惯看那组数字了。正确的做法是在建表阶段就冻结口径。比如统一定义：销售额=支付成功且未全额退款的订单金额；订单数=已支付订单去重ID数；时间字段统一用支付时间。然后把这些口径固化成SQL视图，图表只查视图，不直接写业务逻辑。

如果你们项目的指标口径已经散落到各个报表里，那就需要一张指标字典表，把每个指标的名称、定义、SQL片段、负责人全部登记在里面。虽然维护起来麻烦，但至少下次吵架的时候有据可查。

1.4 死法三：说好的实时刷新，变成定时轰炸

“实时大屏”这个词害人不浅。业务方觉得大屏上的数字就该像心跳一样每秒跳一下，但数据库受得了吗？我在一个项目里数过，一个刷新周期内，20多张大屏页面同时发请求，单张页面上十几个图表，每个查一次库，同一个SQL在5秒内被重复执行几十次。

其实很多指标根本没有“实时”的必要。今日销售额这种数据，分钟级刷新已经是极限了；真正需要秒级刷新的，往往只有在线人数、当前订单量这种少量指标。所以做实时看板的第一步，是跟业务方确认哪些模块必须秒级，哪些模块分钟级足够。

技术方案上，前端轮询是一种最朴素也最可靠的实时手段，但要注意加上缓存层，并且在页面隐藏时自动暂停刷新。如果连轮询都扛不住，就需要在后端做Redis缓存或预聚合表了。这个后面我单独开一节讲。

2. 取数前的三板斧：账号权限、连接串和SQL边界

2.1 给可视化工具开“只读账号”而不是复用业务账号

我第一次做可视化接入的时候，图省事，直接用了应用账号。这个账号有增删改查权限，连接串就明文放在配置里。后来想想真是后怕，万一配置泄露，别人就能直接改生产数据。做数据看板，务必给可视化工具单独开一个只读账号，并且只授予它需要的库表权限。

-- 创建只读账号，并限制连接数 CREATE USER 'bi_reader'@'%' IDENTIFIED BY '强密码占位符'; GRANT SELECT ON sales_db.* TO 'bi_reader'@'%'; ALTER USER 'bi_reader'@'%' WITH MAX_USER_CONNECTIONS 20;

顺便说一句，如果团队对权限管控比较严格，可以更进一步：只给账号查询视图的权限，不让它直接SELECT明细表。这样业务方就算拿这个账号去折腾，也永远只能看到你允许他看到的那几列数据。

给BI账号加上连接数限制也很重要。不然某个图表工具的连接池配置失误，瞬间就能把你的数据库连接耗尽。我遇到过连接池初始大小设成50，又开了自动扩容，高峰期直接开到200多个连接的情况，给MySQL的连接数限制上了一课。

2.2 连接串里容易被忽略的四个参数：字符集、时区、超时、连接池

MySQL可视化项目里很多“怪问题”，根子都在连接参数上。以最常见的JDBC连接串为例，下面这四个参数我基本每次都要检查一遍：

我讲一个真实发生过的场景。某次大屏上线，页面上的销售额趋势图整体前移了8小时，正好是中午12点，显示的却是凌晨4点的数据。查了一圈，问题出在可视化服务启动时，JVM默认时区是UTC，MySQL返回的DATETIME被当成UTC时间存进了缓存，再转换到东八区就偏了。把serverTimezone和JVM时区统一之后，数据立刻正常。

还有个容易忽略的是连接池大小。可视化应用不是高并发业务系统，连接池开个20就足够用了。开太大只会让你在数据库侧看到一堆空闲连接，白白占用资源。

2.3 什么SQL适合丢给BI，什么SQL应该在MySQL里先写好

没有统一标准的架构，但有一条边界我觉得很重要——凡是需要“多表关联+复杂逻辑”的指标，都别让可视化工具在前端拼接，应该提前在MySQL里封装好。举个例子，你想看“各省份销售额”，业务逻辑是订单表关联退款表，再剔除无效订单。这个逻辑你自己写一遍、写对就可以了，但如果每个图表都直连原始表去join，很快就会形成一版SQL一种口径的混乱局面。

我的做法分成三层：

1. 明细/基础层：原始表，只做简单清洗，BI账号只读。
2. 汇总/指标层：把各种指标口径写成视图。比如v_sales_by_day、v_sales_by_region、v_order_funnel，图表的SQL里只写SELECT * FROM v_sales_by_day WHERE day >= '2024-01-01'。
3. 预聚合层：对访问频繁、数据量大的指标，用定时任务把聚合结果写入summary表，图表直接查表。

这里有个容易产生的误会：视图不是性能银弹。视图本质上就是一条SQL，你把复杂的join和子查询塞进视图，执行起来该慢还是慢。视图的价值是统一口径，不是优化性能。真要优化性能，得靠预聚合表和合理的索引。

3. 图表类型和SQL的一一对应：别让前端硬扛

3.1 时间序列：GROUP BY时间粒度的正确写法

做趋势图的时候，最常见的错误是把原始时间戳一股脑传给前端图表库，让浏览器自己去分桶。数据量小可能没事，一旦超过几万点，页面就开始卡顿，而且前端JS的日期分组效率远不如一行SQL。

正确的方式是在MySQL里就把时间桶切好。按小时、按天、按周，都可以在SQL层完成。

-- 按小时聚合 SELECT DATE_FORMAT(pay_time, '%Y-%m-%d %H:00:00') AS hour_bucket, SUM(amount) AS sales_amount FROM orders WHERE pay_time >= NOW() - INTERVAL 24 HOUR GROUP BY hour_bucket ORDER BY hour_bucket;

趋势图的x轴就是hour_bucket，y轴就是sales_amount，前端拿到直接画线，连格式化都不用。还有一个细节：时间字段如果存的是int类型时间戳，可以用FROM_UNIXTIME(ts, '%Y-%m-%d')，别在应用层去转换，因为MySQL处理这个比JS快得多。

3.2 漏斗/下钻：多个SQL还是一个大SQL

下钻是可视化最常用的交互，比如从大区点到省份、从省份点到城市。实现上通常有两条路：第一，前端每次点击都重新请求接口，后端用不同粒度的GROUP BY响应；第二，前端一次性拿到最细的数据，自己本地聚合。

第二个方案看起来省事，但只适合数据量非常小、维度固定的场景。一旦最细粒度有几十万行，浏览器内存根本扛不住。我个人的经验是：需要下钻的场景，优先用“后端按粒度聚合”的方案，参数的粒度字段直接透传到SQL里。这样做还有一个好处，图表请求天然轻量，网络传输也快。

漏斗图的实现思路就更简单了。漏斗的每一层本质上就是一个COUNT，可以用UNION ALL把多个环节合并成一次查询：

SELECT 'step1_visit' AS funnel_step, COUNT(DISTINCT user_id) AS user_cnt FROM visit_log UNION ALL SELECT 'step2_cart', COUNT(DISTINCT user_id) FROM cart_log UNION ALL SELECT 'step3_pay', COUNT(DISTINCT user_id) FROM pay_log;

你可能会担心两个表之间的口径对齐问题，这就回到了前面的指标字典：每个环节的user_id是什么定义，提前说清楚，落到SQL里就不会乱。

3.3 环形图、地图：维度和度量怎么喂给图表组件

大多数图表库需要的不是宽表，而是一个“名字+数值”的数组。比如环形图的数据结构一般是[{ name: '华东', value: 1200 }, { name: '华南', value: 900 }]，正好对应SQL查出来的两列：维度列、度量列。

但地图有一个特别容易被坑的点：区域名称的统一。MySQL里存的地址可能是“内蒙古”“内蒙古自治区”混着写，而地图库内置的地理坐标系往往只认标准名称。解决办法是建一张维度映射表，在SQL里直接join：

SELECT r.standard_name AS region_name, SUM(o.amount) AS sales_amount FROM orders o LEFT JOIN dim_region_mapping r ON o.province = r.original_name WHERE o.pay_time >= CURDATE() GROUP BY r.standard_name;

顺带提醒一句，说完地图我要唱个反调：如果一个可视化项目里有超过五分之一的图都是地图，那大概率是凑图表类型，不是真的需要地图。地图不适合展示数值精度要求高的场景，它适合让读者快速感知“哪个区域强哪个区域弱”，仅此而已。

3.4 指标卡：一个SQL查多个聚合值的技巧

大屏上最常见的模块就是一堆指标卡，什么今日销售额、今日订单数、客单价、同比。很多人会为每个指标单独写一个查询，结果页面一刷新，数据库就要执行4次SQL。其实这些指标完全可以在一条SQL里算完。

SELECT SUM(CASE WHEN pay_time >= CURDATE() THEN amount ELSE 0 END) AS today_amount, COUNT(DISTINCT CASE WHEN pay_time >= CURDATE() THEN order_id END) AS today_orders, ROUND( SUM(CASE WHEN pay_time >= CURDATE() THEN amount ELSE 0 END) / NULLIF(COUNT(DISTINCT CASE WHEN pay_time >= CURDATE() THEN order_id END), 0), 2 ) AS avg_order_value, ROUND( SUM(CASE WHEN pay_time >= CURDATE() THEN amount ELSE 0 END) / NULLIF(SUM(CASE WHEN pay_time >= DATE_SUB(CURDATE(), INTERVAL 1 DAY) AND pay_time < CURDATE() THEN amount ELSE 0 END), 0) , 4) AS day_over_day_ratio FROM orders WHERE pay_time >= DATE_SUB(CURDATE(), INTERVAL 1 DAY);

这种SQL看起来很复杂，但实际执行起来比4次简单查询更快，因为它只扫了一遍数据。指标卡的特点是每张图数据量不大但请求频繁，所以除了用一条SQL合并外，还建议在前面加一层缓存。缓存过期时间根据业务来，一般30秒到5分钟之间就够了。

4. 可视化查询的性能闸门：从慢查询日志到结果集瘦身

4.1 先建立基线：哪些查询每天跑多少遍

我处理性能问题，从来不先看单条SQL多慢，而是先看“哪些SQL被跑得最多”。一个执行1秒的SQL被跑1万次，和一个执行10秒的SQL跑一次，前者的危害更大。

MySQL里可以借助performance_schema快速找出重复执行最频繁的查询：

SELECT SCHEMA_NAME, DIGEST_TEXT, COUNT_STAR, SUM_ROWS_EXAMINED, SUM_TIMER_WAIT / 1000000000 AS total_seconds FROM performance_schema.events_statements_summary_by_digest ORDER BY COUNT_STAR DESC LIMIT 20;

拿到这个列表之后，你才能分清哪些慢查询是可视化工具发出来的、哪些是核心业务产生的。我通常会把可视化相关的查询单独抽出来，看它在高峰期的执行次数和扫描行数。如果扫描行数和返回行数差了好几个数量级，那就特别值得优化，这也是最典型的“索引没用好”信号。

4.2 索引不是银弹：GROUP BY和ORDER BY的索引陷阱

聊到性能，一定会谈到索引。但很多索引问题不是“有没有索引”，而是“索引长得对不对”。可视化查询大部分是时间范围加上维度分组：

SELECT province, SUM(amount) FROM orders WHERE pay_time BETWEEN '2024-01-01' AND '2024-01-31' GROUP BY province;

这种查询想要走好索引，联合索引的顺序很关键。如果索引是(province, pay_time)，MySQL可以先按province定位所有范围，再在省内部聚合，效果通常比(pay_time, province)更优。当然具体怎么走要看数据分布，用EXPLAIN验证，不要想当然。

EXPLAIN SELECT province, SUM(amount) FROM orders WHERE pay_time BETWEEN '2024-01-01' AND '2024-01-31' GROUP BY province;

另外有个最常见的翻车点：在索引列上套函数。很多人喜欢这样写：

WHERE DATE_FORMAT(pay_time, '%Y-%m-%d') = '2024-03-01'

DATE_FORMAT之后，索引基本就失效了。正确写法是直接比较时间范围：

WHERE pay_time >= '2024-03-01' AND pay_time < '2024-03-02'

靠着这个改写，我帮项目解决过大屏看板从3秒降到0.3秒的问题。别小看这类细节，可视化场景里查询基本都是重复执行的，快一小点，体感就是“秒开”和“转圈”的差别。

4.3 结果集瘦身：只传聚合后的数据，不传明细

图表接口的返回值大小，常常是性能问题里最被忽视的一环。我曾经接手过一个项目，趋势图接口返回了60万行明细数据，浏览器渲染的时候直接卡死。查代码发现，前端其实要的是每个小时的平均值，但后端同学图省事，把明细全传上去了。

后来我给团队定了条规矩：**图表接口永远不返回明细，只返回最终要展示的那一两个数值维度。**如果确实有导出明细的需求，就走专门的导出通道，用异步任务生成CSV，别让大屏和报表页面承担这个压力。

还有一个小技巧，聚合后的结果如果还是很大，可以考虑在SQL里加ORDER BY LIMIT，只取TopN。对于“销售额Top10地区”这类场景，MySQL本身就能算出来，前端拿到10条数据就够了，完全不值得传几万条过去再排序。

4.4 连接数与超时：可视化工具把数据库拖垮的真实案例

有一次线上MySQL连接数告警，业务写入频繁失败。我上去之后先看processlist，结果整整几屏都是同一个查询。再向上追，发现来源是可视化工具的定时刷新，10个图表、每5秒刷一次、每次查询耗时2秒，连接池的100个连接全被占住排队。

这里有一个简单的计算：一个页面10个图表，每个查询耗时2秒，每5秒刷新一次，理论上需要的并发连接大约就是10*2/5=4个。但如果页面同时被多个业务方打开，这个数字就要翻倍。再加上查询如果优化不好，单次耗时拉长到5秒，情况会更糟。

这类问题靠数据库侧限流是治标不治本，真正要改的是刷新策略。我的经验是先把可视化工具连接池上限调小，比如20；再在业务上把刷新频率从5秒调到30秒或60秒；最后把高频查询的结果加上Redis缓存。只有三层一起做，才能既保证体验又不拖垮数据库。

5. 中文乱码、时区偏移和数据对不齐：三个高频怪问题的排查链路

5.1 中文乱码的根因：连接参数 vs 表字符集

乱码问题几乎是所有MySQL可视化项目都绕不开的。好多人一看到中文乱码就急着去改表结构，把字段改成utf8mb4，但有时候问题根本不在表上，而在连接层面。

我的排查链路是固定的三步：

1. 看表的字符集：SHOW CREATE TABLE your_table;，重点看DEFAULT CHARSET。
2. 看连接串参数：JDBC有没有characterEncoding=utf8mb4，ODBC有没有charset=utf8mb4。
3. 看数据本身有没有存错：SELECT HEX(name) FROM your_table WHERE id = 1;。如果看到e4bda0e5a5bd这种正常UTF-8字节，说明表里存储没问题，乱码发生在读取展示环节。

大部分情况是连接串没带字符集参数，或者可视化工具默认用了latin1。解决办法就是在连接串显式加上characterEncoding=utf8mb4，同时在MySQL侧把会话字符集也设置一下。修改表字符集属于重型操作，如果是几十万行的小表可以顺手改，几千万的大表就别硬来了，优先从连接参数解决。

5.2 时间永远差8小时：时区配置的关键点

时间差8小时的排查链路也很清晰。先确认数据库当前时间：

SELECT NOW(), @@global.time_zone, @@session.time_zone;

如果数据库的时间符合预期，问题八成出在应用侧。JDBC连接串一定要带serverTimezone=Asia/Shanghai；如果你用的是浏览器直连的HTTP接口，还要看后端接口返回的是时间戳还是字符串，以及返回的字符串带不带时区后缀。

我在实践中发现一个隐患：只要用了连接池，数据库重启或者连接串改配置之后，旧连接的时区信息可能不会自动刷新，哪怕你改了URL，它还是沿用老连接。这时候最简单的办法是重启可视化应用，或者等连接池的自然回收周期。别折腾半天以为自己改错了，先重启验证一次，能省掉很多自我怀疑的时间。

5.3 数据对不齐：统计口径不一致，还是去重方式不同

“大屏上的订单数和报表导出的订单数不一样”，这个工单我接过无数个。排查之后，大部分原因不在BUG，而在去重逻辑。

最典型的是多表关联造成的重复计数。比如订单表LEFT JOIN退款表，一单如果有两次部分退款，就会变成两行，再COUNT(*)自然就多了。正确写法有两种，要么用COUNT(DISTINCT order_id)，要么先按订单聚合退款金额再join到订单维度：

-- 正确：先按订单聚合退款，再关联订单 SELECT o.order_id, COALESCE(r.refund_amount, 0) AS refund_amount FROM orders o LEFT JOIN ( SELECT order_id, SUM(refund_amount) AS refund_amount FROM refunds GROUP BY order_id ) r ON o.order_id = r.order_id;

这个坑在数据可视化里非常隐蔽，因为图表工具通常不提醒你“两行其实是同一笔订单”，界面看上去只是数字对不上。遇到这种问题，一定要回到SQL去复现，别在可视化工具里反复切换汇总方式，那是浪费时间。

我在团队里也立了条规矩：所有涉及多表关联的指标，SQL必须由写数据层的人 review，不允许直接在可视化工具里写join。因为工具里的join逻辑很难测试和复用，写到视图里至少后续还能排查。

6. 实时看板的数据链路：从SQL到前端刷新的三种做法

6.1 方案一：前端定时拉接口（轮询）

实时看板最简单的实现方式，就是前端定时向后端接口发起请求，后端实时查MySQL返回结果。这个方案最朴素，也最容易排查问题。适合刷新频率在10秒以上的场景，而且每次查询都必须是轻量级的聚合查询。

前端轮询有一个容易被忽略的细节：上一次请求还没返回，下一次定时器又触发了。这样会导致请求堆积，响应越来越慢。比较好的做法是使用setInterval加请求防重，或者直接用setTimeout来串行轮询。

async function refresh() { const controller = new AbortController(); const timeoutId = setTimeout(() => controller.abort(), 10000); try { const res = await fetch('/api/sales/trend', { signal: controller.signal }); const data = await res.json(); renderChart(data); } finally { clearTimeout(timeoutId); } finally { setTimeout(refresh, 30000); } } refresh();

还可以监听页面可见性变化，在标签页隐藏时暂停请求，回到前台再立即刷新一次。别小看这个优化，大屏往往被挂在电视或会议室电脑上，没人时刻点着鼠标，省下来的后端请求相当可观。

6.2 方案二：后端缓存 + 增量刷新

如果轮询方案扛不住并发，或者数据库压力很大，就该引入缓存了。最简单的是加一层Redis，接口先取缓存，缓存没有或过期了再查MySQL，同时把结果回填缓存。这样数据库面对的真实查询频率，只和缓存过期时间有关，而不受前端页面数量影响。

更进一步，可以把“全量重查”改成“增量更新”。比如每5分钟跑一次定时任务，把过去5分钟的订单累加到Redis的当日统计值上，查询接口直接返回Redis里的累计值。数据库只需要在每次定时任务里查最近5分钟的数据，查询数据量小，压力自然小。

这个方案的缺点是代码复杂度上升，而且要自己考虑缓存一致性和持久化问题。如果业务需求只是“分钟级准实时”，我建议先停留在全量缓存这一步就够了。真的到了数据量特别大、更新频率特别高的阶段，再考虑增量架构。

6.3 方案三：基于binlog的旁路采集（能不碰就不碰）

还有一类更“高级”的实时方案，是通过解析MySQL的binlog，把变更同步到OLAP数据库或缓存里，大屏再直接查这个旁路系统。优点是延迟可以做到秒级甚至毫秒级，缺点是链路长、组件多、排查困难。

我自己比较谨慎：除非已经明确有复杂实时数仓需求，否则一开始不推荐搞这个。一个普通销售大屏，几分钟刷一次完全能接受；强行上binlog采集，只会增加维护成本。做技术选型讲究循序渐进，先满足需求，再谈优化，而不是让架构跑在需求前面。

6.4 我的推荐：先轮询，再加缓存，最后再考虑消息队列

把三种方案放在一起看，边界其实很清楚：

我给大多数团队的建议是先上车轮询，跑通业务，然后在数据库出现压力的苗头时上缓存。不要为了技术而技术，实时看板的核心是先让业务方用起来，数据准确了再谈快。

7. 一个可复用的实战骨架：销售看板的SQL和图表配置

7.1 需求清单和指标口径

最后用一个销售看板的案例，把前面提到的技术点串起来。假设需求是这样：

• 大屏上展示：今日销售额、今日订单数、客单价、昨日对比、近7日销售趋势、销售额Top5商品、区域分布热力图。
• 刷新节奏：指标卡5分钟，趋势图15分钟，区域图10分钟，Top商品5分钟。
• 下钻：区域图支持点省份查看城市明细。

先把口径固定下来：销售额=支付成功且未全额退款的订单金额；订单数=支付成功订单去重ID数；今日=自然日0点到当前时刻。这张表写清楚了，后面谁来看数都不会吵。

7.2 核心SQL

指标卡的合并SQL前面已经给过了，这里补一条趋势和Top商品的示例。

近7日趋势，按天聚合：

SELECT DATE(pay_time) AS day, COUNT(DISTINCT order_id) AS orders, SUM(amount) AS sales_amount FROM orders WHERE pay_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(pay_time) ORDER BY day;

Top5商品：

SELECT product_name, SUM(amount) AS sales_amount, COUNT(DISTINCT order_id) AS orders FROM orders WHERE pay_time >= CURDATE() GROUP BY product_name ORDER BY sales_amount DESC LIMIT 5;

区域分布用前面提到的维度映射表join，拿到标准区域名，再按省份分组。

这些SQL有个共同特点：全部是聚合后的小结果集，返回的数据都在几百行以内，前端渲染毫无压力。而且时间条件都写得很显式，方便MySQL利用索引。

7.3 图表组件的配置要点

图表组件本身没什么神秘的，但我有几个经验值分享。

第一，颜色不要超过一个主色系。大屏通常背景比较深，图表高亮色一多，视觉上会显得很杂乱。我自己常用“一个主色+一个警示色”的搭配，比如主色系用青色系，同比变差用橙红色提示。

第二，坐标轴和标签格式化要提前想好。金额类的y轴，建议在前端统一格式化成“万”“亿”的单位，不要直接在SQL里除以10000，因为不同指标的单位不同，前端统一处理更灵活。

第三，动画能关就关。大屏上的图表动画除了刚开始加载时有一点“炫”的效果，常态运行下只会让刷新变得拖沓。把过渡动画时长设短或者关闭，节奏会干净很多。

7.4 刷新节奏和下钻交互

刷新节奏我习惯用一个调度配置来统一管理，而不是在每个图表组件里写死定时器。维护一张配置表：

下钻交互方面，点击区域图某个省份后，前端请求/api/sales/region?level=city&province=山东省，后端把GROUP BY字段从province换成city，再按同样的口径聚合一次。SQL的写法保持高度一致，只改维度和过滤条件，这样下钻越多，越不容易出口径偏差。

最后补一句我自己实践下来的经验：大屏项目上线前，一定打开慢查询日志，连续观察至少半天，把所有超过1秒的可视化查询全部处理掉。上线之后再排查性能问题，体感成本至少是上线前的三倍。把这套思路先跑通，MySQL数据可视化项目基本就不会再出那些让人头疼的“小毛病”了。