MySQL数据可视化三种方案：SQL聚合、BI直连与自研报表实战

我常跟业务同学说一句话：数据存在库里不叫资产，只有被用起来才叫资产。很多团队MySQL用了好几年，订单表、用户表、商品表堆得满满当当，结果业务方要看个销售趋势，还是得找开发帮忙导Excel，导出来还要自己用透视表捣鼓半天。数据躺在库里“吃灰”，这是比没有数据更可惜的事情。

做可视化，很多人第一反应是上大数据平台，或者引入一套很重的BI系统。但以我这几年的实操经验来看，大多数场景压根不用那么折腾，MySQL本身就能扛下可视化链路里最重的那部分活。我在这里分享三种硬核姿势：第一种是纯SQL派，在MySQL内部完成数据加工，把表变成图表可直接消费的指标；第二种是开源BI工具直连MySQL，拖拽配置出运营看板；第三种是自研轻量可视化，用后端接口加前端图表库，把MySQL的数据灵活呈现在自己的页面上。无论你是后端开发、运维还是业务数据分析师，这三条路总有一条适合你。

1. 三种硬核姿势的整体设计：先把 MySQL 的位置摆正

1.1 为什么我坚持让 MySQL 留在可视化链路里

现在一提数据分析，很多人就想到Hadoop、Spark、ClickHouse、云数仓，架设起来周期长、成本高，团队如果没有专职数据开发，光同步数据就能折腾掉半条命。MySQL当然不是万能的，但它在大部分团队里已经是现成的核心库，订单、用户、库存每天都在这里产生。与其把数据搬到别处再分析，不如先问问自己：MySQL这张牌打好了没有？

可视化这件事，本质上不是把数据库做得花里胡哨，而是把“表中几百万行明细”变成“人一眼能看懂的几条曲线、几个数字”。MySQL擅长的是存储和聚合，恰好是这个过程最核心的部分。一张订单明细表，你用GROUP BY按天、按分类刷一遍，再对结果做折线图、柱状图，图表的数据源就已经有了。很多看板上看起来高大上的指标，究其根本就是一次写得还算可以的SQL查询。

所以我现在的习惯是：拿到任何可视化需求，先不急着选工具，而是先在MySQL里把查询写出来，把指标口径定下来。口径稳了，后面用什么姿势都顺；口径没定，换再多工具都是在“花式吃灰”。

1.2 三种姿势的取舍与适用场景

既然叫三种硬核姿势，它们之间没有绝对的优劣，只是解决的问题不一样。我习惯用下面这个方式给大家做选择参考：

这里有个很重要的观念：可视化链路不是越重越好，而是匹配团队能力最好。你要是连SQL都还没写利索，硬上一个重量级BI平台，最后只会多一个没人维护的系统。先把简单方案用透，再根据痛点升级。

1.3 后面要用的示例表：一张订单明细表

为了让下面的SQL和接口代码可以直接落地复现，我们先把一张最典型的订单表建出来。实际业务里可能叫order_info、orders或者t_order，字段大致都差不多。核心字段包括订单号、用户ID、门店ID、商品类目、支付金额、订单状态和下单时间。

CREATE TABLE order_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id VARCHAR(64) NOT NULL, user_id BIGINT NOT NULL, store_id INT NOT NULL, category VARCHAR(32) NOT NULL, pay_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0 COMMENT '1已支付,2退款,0未支付', create_time DATETIME NOT NULL, KEY idx_create_time (create_time), KEY idx_user_id (user_id), KEY idx_store_category (store_id, category) );

这张表的设计有一个默认细节：下单时间和支付状态是分析里最高频的过滤条件，所以我首先给create_time建了索引。后面讲慢查询时，你会看到这一步有多重要。如果你是在自己电脑上做实验，可以用下面这段MySQL 8.0的写法造一批演示数据，往表里塞个几千行就够用了。

-- 造演示数据用，生产环境不要这么玩 INSERT INTO order_info(order_id, user_id, store_id, category, pay_amount, status, create_time) SELECT CONCAT('ORD', LPAD(id, 10, '0')), id % 2000 + 1000, id % 5 + 1, ELT(id % 4 + 1, '数码', '服装', '食品', '日用'), ROUND(RAND() * 500 + 20, 2), 1, DATE_SUB(NOW(), INTERVAL (id % 90) DAY) FROM seq_1_to_10000;

这里用了一张辅助数字表seq_1_to_10000，如果本地没有可以自己临时建一张只有一列数字的辅助表。演示数据嘛，图的是能跑SQL，不追求业务真实性。

2. 姿势一：纯 SQL 派，先拿 SQL 把图表要的“料”备好

2.1 给图表准备数据，其实就是写聚合查询

我最早做报表的时候，习惯把明细数据全部导出来，在Excel里用数据透视表折腾半天。后来发现，MySQL一条GROUP BY语句能干完的事，非要在Excel里人工操作，既慢又容易出错。把明细聚合成指标，是SQL可视化最基础也最硬核的一步。

比如运营想看最近30天每天的订单量和销售额，那么查询可以这么写：

SELECT DATE(create_time) AS dt, COUNT(DISTINCT order_id) AS order_cnt, COUNT(DISTINCT user_id) AS buyer_cnt, SUM(pay_amount) AS gmv, ROUND(SUM(pay_amount) / COUNT(DISTINCT order_id), 2) AS avg_order_price FROM order_info WHERE status = 1 AND create_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY DATE(create_time) ORDER BY dt;

这个结果直接喂给折线图、柱状图，天粒度趋势就有了。这里有几个细节值得你注意：

第一，COUNT(DISTINCT order_id)在order_id本身唯一时完全是浪费，直接COUNT(*)就行，除非你确认同一订单会拆成多行。第二，过滤条件必须先写status=1，把退款和下单单但未支付的记录排除，否则GMV会虚高。第三，GROUP BY后面最好和SELECT里非聚合字段保持一致，这是SQL基本功，也是避免误解的防线。

我在实际写这类查询时，会给自己定三条规矩：只SELECT图表需要的字段，把过滤条件写成能走索引的形态，能用GROUP BY在数据库解决的绝不放应用层循环。这样出来的SQL既快又可维护。

2.2 视图固化业务口径，图表背后有一个统一标准

如果你只写一次查询，那直接复制SQL就行。但BI工具、Python接口、Excel导出都需要同一套口径时，问题和矛盾就出来了：运营说GMV是已支付订单金额，开发却把未支付也算进去了，最后两张表数字对不上，会上吵翻天。

解决办法是用视图把口径固定下来。视图在MySQL里就是一个“保存好的SQL查询”，你查视图时它才会去执行底层查询。我们可以把上面那段汇总逻辑做成视图：

CREATE OR REPLACE VIEW v_order_daily_stat AS SELECT DATE(create_time) AS dt, COUNT(*) AS order_cnt, COUNT(DISTINCT user_id) AS buyer_cnt, SUM(pay_amount) AS gmv, ROUND(SUM(pay_amount) / COUNT(*), 2) AS avg_order_price FROM order_info WHERE status = 1 AND create_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY DATE(create_time);

这样一来，BI工具、Python代码、临时取数统一查v_order_daily_stat，口径天然一致。以后如果GMV的计算规则从“已支付金额”变成“已支付金额减去退款金额”，只需要改视图定义，所有下游图表一起更新，不需要一个个改报表。

但这里我必须泼一盆冷水：视图并不存储数据，查询视图等于执行视图背后的SQL。所以视图没法让一个本来很慢的查询变快，底层表的索引和查询条件该优化还是得优化。视图解决的是“口径一致”问题，不是“性能翻倍”问题。

2.3 存储过程加事件：让每日统计自动落成快照宽表

如果每天都要算近30天趋势、分类销售额、门店排名，每次都实时去扫几百万行明细，你会明显感觉到数据库压力。这里我更推荐“物化快照”的思路：用存储过程把计算结果提前算好，存进一张很小的汇总表，再让BI或接口查这张小表。

先建一张按天存储的汇总表：

CREATE TABLE order_daily_snapshot ( dt DATE PRIMARY KEY, order_cnt INT NOT NULL, buyer_cnt INT NOT NULL, gmv DECIMAL(12,2) NOT NULL, avg_order_price DECIMAL(8,2) NOT NULL, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

然后写存储过程，计算当天数据并写进去：

DELIMITER // CREATE PROCEDURE proc_refresh_order_daily() BEGIN INSERT INTO order_daily_snapshot(dt, order_cnt, buyer_cnt, gmv, avg_order_price) SELECT DATE(create_time), COUNT(*), COUNT(DISTINCT user_id), SUM(pay_amount), ROUND(SUM(pay_amount) / COUNT(*), 2) FROM order_info WHERE status = 1 AND create_time >= DATE_SUB(CURDATE(), INTERVAL 1 DAY) GROUP BY DATE(create_time) ON DUPLICATE KEY UPDATE order_cnt = VALUES(order_cnt), buyer_cnt = VALUES(buyer_cnt), gmv = VALUES(gmv), avg_order_price = VALUES(avg_order_price); END// DELIMITER ;

接着创建一个每天凌晨执行的定时事件：

CREATE EVENT IF NOT EXISTS ev_refresh_order_daily ON SCHEDULE EVERY 1 DAY STARTS '2025-01-07 00:30:00' DO CALL proc_refresh_order_daily();

这样每天早上业务打开看板时，数据已经算好了。查询一个几十行的汇总表，比实时聚合一张百万行明细表快几个数量级，而且不影响线上业务。

使用定时事件前，记得确认MySQL的event_scheduler开关是打开的，执行一下：

SHOW VARIABLES LIKE 'event_scheduler';

如果是OFF，要么在配置文件里加上event_scheduler=ON，要么用SET GLOBAL event_scheduler = ON临时开启。生产环境建议写进配置文件，否则实例重启后事件不会自动恢复。

2.4 姿势一的边界：数据准备好，可视化才刚刚开始

纯SQL这一派做到这里，其实已经完成了可视化链路里最难也最容易被忽略的部分：数据建模。如果你只是自己看数据，把查询结果复制到CSV，再丢进Excel或在线表格工具做透视表，完全够用。但如果你要服务一群用户，让他们自己筛选日期、点击门店下钻，就需要考虑把结果接到交互工具上。

这也是为什么我在实战中通常不是只用姿势一，而是把它当作姿势二和姿势三的地基。无论后面接BI还是自研接口，SQL视图和快照表都是我最信任的数据来源。

3. 姿势二：开源 BI 工具直连 MySQL，快速交付运营看板

3.1 为什么选择直连，以及工具怎么选

自己写前端做图表，周期再快也要几天。如果运营今天就想要一张销售看板，明天要加上分类占比，后天又要换一种图表，最省力的方式就是引入开源BI工具，直接连MySQL。像Metabase、Superset、Grafana这类开源项目，本质都是“配置数据源，然后拖拽出图表和看板”，对手头有MySQL的团队来说，相当于白捡一套可视化后台。

选型时我的建议是看团队使用频率。轻量级BI工具更适合内部运营看板，配置简单，学习成本低；重一点的平台适合需要更复杂权限、图表类型更丰富的团队。Grafana则更偏向监控和时序数据，如果你的数据本身就是按时间点采样的指标，用它反而顺手。不要一上来就追最重的，先看团队里谁能维护它。

3.2 给 BI 准备一个最小权限的只读账号

开源BI工具直连MySQL，第一件要做的事不是配图表，而是创建只读账号。这个账号只给SELECT权限，绝不能复用业务系统的高权限账号。

CREATE USER 'report_read'@'%' IDENTIFIED BY '这里换成强密码'; GRANT SELECT ON shop.* TO 'report_read'@'%'; FLUSH PRIVILEGES;

如果你对数据安全敏感，甚至可以只授权视图像限的业务。比如业务同学只能看到已支付订单，不能看到用户明细表里的手机号，那就把视图授权给BI账号，不授权底层明细表：

GRANT SELECT ON shop.v_order_daily_stat TO 'report_read'@'%';

连接串配置时也有一点容易踩坑：如果BI是用JDBC连MySQL，建议在连接参数里把编码和时区显式写清楚，类似：

jdbc:mysql://内网地址:3306/shop?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8mb4

这个配置能省掉后面很多字符乱码和时区错位的麻烦。

3.3 在 BI 里建模：日期字段和维度表很重要

连上MySQL之后，BI工具会读取数据库的表结构。此时你不要把几十上百张业务表全暴露出来，最好只暴露业务需要的那几张视图或快照表。BI工具后台一般都能标记表的字段类型，这里日期字段一定要确认被识别成日期类型，否则图表上它会按字符串排序，折线图的时间轴会乱得没法看。

另外，很多BI工具支持模型JOIN，但我不建议BI直连时做太复杂的多表关联。MySQL不是专业分析型数据库，BI每触发一次查询都要实时执行SQL，关联得越复杂，慢查询概率越高。我宁可提前在MySQL里把宽表做好，BI只需要做单表聚合。

有一个小技巧：如果你的团队看板很多，可以对快照表和汇总视图设置BI的缓存刷新时间，比如每5分钟或者每1小时刷新一次。内部经营看板对实时性的要求没那么高，缓存能大幅减轻MySQL的查询压力。

3.4 典型看板的图表配置思路

假设现在要给运营搭一块日常销售看板，我一般会从下面几张图开始：

• 核心指标卡：总GMV、总订单量、总购买用户数、客单价
• 每日GMV趋势折线图：按天展示销售额变化
• 分类销售柱状图：按商品类目汇总
• 门店销售Top榜单：按门店排名

这些图表在BI里配置起来都不复杂，但要注意每个图表的过滤条件必须统一。例如GMV只统计status=1的记录，退款要单独拆一个指标展示，否则销售趋势会因为退款订单被包含进去而出现误导。BI的优势是你可以在全局层设置默认过滤条件，但前提是你在MySQL视图里已经把status=1的口径写死了。

我见过很多BI看板做着做着数字就对不上，原因不在工具，而在数据口径分散。所以我还是建议，BI直连的表尽量用视图和宽表，不要直接把原始明细表拖出来让大家自由探索。自由是有代价的，代价就是口径崩坏。

3.5 BI 方案的软肋：定制化能力有限

BI方案最适合内部看板和运营自助分析，但当你要把图表嵌入客户系统、做成大屏、还要配合特定交互时，它就有点不够用了。开源BI本身也是前后端项目，改样式就是在改开源代码，后续升级维护成本很高。真到了那一步，我倾向切换到第三种姿势，自己写一个轻量可视化页面。

4. 姿势三：自研轻量可视化，把 MySQL 数据画成自己的页面

4.1 思路概述：自己写接口画图，还是围着 MySQL 转

自研不等于抛弃MySQL，恰恰相反，它依然把MySQL当作唯一数据源。核心流程是：前端页面发起请求，后端接口从MySQL查询数据，返回JSON给前端，前端用图表库渲染。这样做的优势在于，你可以完全控制接口的入参、数据的筛选逻辑和页面上的交互反馈。

适用场景也很明确：要给客户做一个数据大屏，要把销售趋势嵌入到内部管理系统，或者说BI工具满足不了你想要的交互。我做过不少这类项目，整体技术栈通常以Python写后端接口、ECharts画图为主，下面按步骤拆解。

4.2 后端接口：从 MySQL 取数的正确姿势

第一步是建立一个数据接口。以Python Flask为例，先写一个简单的查询接口，返回每日GMV趋势数据：

from flask import Flask, jsonify, request import mysql.connector app = Flask(__name__) def get_conn(): return mysql.connector.connect( host='127.0.0.1', user='report_read', password='这里换成强密码', database='shop', charset='utf8mb4' ) @app.route('/api/sales_trend', methods=['GET']) def sales_trend(): date_from = request.args.get('date_from', '2025-01-01') date_to = request.args.get('date_to', '2025-01-31') sql = """ SELECT DATE(create_time) AS dt, SUM(pay_amount) AS gmv, COUNT(*) AS order_cnt FROM order_info WHERE status = 1 AND create_time >= %s AND create_time < DATE_ADD(%s, INTERVAL 1 DAY) GROUP BY DATE(create_time) ORDER BY dt """ conn = get_conn() cursor = conn.cursor(dictionary=True) cursor.execute(sql, (date_from, date_to)) rows = cursor.fetchall() cursor.close() conn.close() return jsonify(rows) if __name__ == '__main__': app.run(host='0.0.0.0', port=8000)

这个接口里有几个关键点值得你细品。第一，用了参数化查询而不是把外部传入的date_from直接拼进SQL，这是防SQL注入的基本底线。第二，日期过滤用了半开区间，create_time >= %s AND create_time < DATE_ADD(%s, INTERVAL 1 DAY)，这样会完整包含date_to当天，而且能利用到下单时间索引。第三，查询只返回到聚合后的JSON，前端不需要处理百万行明细。

实际生产里我不建议在每个请求里都新建MySQL连接，最好用连接池，或者直接使用SQLAlchemy这类ORM封装。这里写法是为了把核心逻辑展示清楚，生产环境请再封装一层。

4.3 缓存层：挡在 MySQL 前面的一张网

自研接口最容易踩的坑是“前端每刷新一次，MySQL就被打一次”。数据看板的特点是一屏图表基本固定，凌晨的汇总数据白天不会有太大变化。所以我在接口和MySQL之间加一层缓存，用Redis或者本地内存都行。

推荐做法是加上TTL缓存，下面这段伪代码可以直接套进你的Flask接口里：

import redis import json r = redis.Redis(host='127.0.0.1', port=6379, db=0) @app.route('/api/sales_trend', methods=['GET']) def sales_trend_cached(): cache_key = 'sales_trend_20250101_20250131' cached = r.get(cache_key) if cached: return jsonify(json.loads(cached)) # 这里调用上面那段MYSQL查询逻辑，拿到rows rows = query_mysql(...) r.setex(cache_key, 300, json.dumps(rows, ensure_ascii=False)) return jsonify(rows)

缓存的TTL设多少，取决于你对实时性的要求。内部看板五分钟更新一次足够；对外大屏要求秒级刷新，就不适合把底层明细表扫描拿来做，而是查快照表，再配合短TTL缓存。总之，不要让每个用户的每一次操作都穿透到MySQL。

4.4 前端图表渲染与动态筛选

后端接口就绪后，前端可以用任何图表库。我习惯用ECharts，因为它的折线图、柱状图配置简单，社区案例也多。给一个最小可运行的HTML页面：

<div id="trendChart" style="width: 900px; height: 400px;"></div> <script src="https://cdn.jsdelivr.net/npm/echarts@5"></script> <script> fetch('/api/sales_trend?date_from=2025-01-01&date_to=2025-01-31') .then(res => res.json()) .then(data => { const chart = echarts.init(document.getElementById('trendChart')); chart.setOption({ title: { text: '每日 GMV 趋势' }, tooltip: { trigger: 'axis' }, xAxis: { type: 'category', data: data.map(item => item.dt) }, yAxis: { type: 'value' }, series: [{ name: 'GMV', type: 'line', data: data.map(item => item.gmv), areaStyle: {} }] }); }); </script>

这段代码看起来简单，但它已经是一个完整链路：浏览器发起请求到Flask，Flask查MySQL，返回JSON，ECharts渲染出折线图。你可以在页面里加上日期选择器、门店筛选下拉框，每次变化时带参数重新请求接口，就成了一个能做动态筛选的自研看板。

4.5 自研方案怎么继续扩展

有了这套最小链路之后，可以扩展的方向很多。我把实践中常用到的几种写在下面：

• 加权限：在接口层校验token，根据当前登录用户限制只能看某些门店或类目的数据。
• 定时刷新：不一定要用户在页面刷新时才看数据，可以用服务器定时任务每天触发存储过程，把数据先聚合到快照表，接口只查快照。
• 大屏自动刷新：前端每隔30秒用setInterval重新请求一次接口，配合短TTL缓存实现“准实时”效果。
• 导出CSV：后端增加一个导出接口，把相同查询结果生成CSV文件，让领导“数据没吃灰”的同时还能拿Excel二次加工。

这个方案最大的优点就是没有黑盒。SQL、接口逻辑、图表样式全都在你手上，业务出任何问题都能快速定位。代价也很直接：你得会写后端和前端，而且运维、缓存、权限这些事情都归你管。所以我不建议一个人初学者硬上自研方案，而是先积累前两种姿势的经验，觉得BI不够用了再自研。

5. 我踩过的坑和排查技巧实录

5.1 图表加载慢，先怀疑 WHERE 条件是否破坏索引

可视化看板最要命的就是图表转圈。我第一次做BI直连的时候，运营反馈“每日趋势图打开要十秒”，排查后发现分析同事写的自定义SQL里用了DATE(create_time) >= 这种写法，对列套函数会导致索引失效。

-- 错误示范：对日期列套函数，大概率走不上索引 SELECT DATE(create_time) AS dt, SUM(pay_amount) FROM order_info WHERE DATE(create_time) >= '2025-01-01' GROUP BY DATE(create_time); -- 正确示范：把过滤条件改成范围区间，走索引 SELECT DATE(create_time) AS dt, SUM(pay_amount) FROM order_info WHERE create_time >= '2025-01-01' AND create_time < '2025-02-01' GROUP BY DATE(create_time);

排查这类问题，直接用EXPLAIN看看执行计划：

EXPLAIN SELECT ...

如果看到type从range变成了ALL，或者rows扫描行数异常大，多半是索引没利用好。索引不是越多越好，像这张演示表，create_time上的索引支撑时间范围过滤，已经覆盖了绝大多数可视化查询，再加过多索引反而拖慢写入。

5.2 时区配置不一致，早上的报表看着总是不对

有段时间业务反馈“每天凌晨的数据少了一个小时”，查到最后发现MySQL系统时区和BI应用时区不一致。MySQL里CURDATE()和NOW()都是按服务器的time_zone返回，如果库里存的是UTC时间，BI按北京时间展示，凌晨零点的数据就会被划到上一天。

统一方案不复杂：生产环境确认所有环境都使用同一个时区，比如Asia/Shanghai，连接参数里显式声明。千万不要一部分用time_zone默认值，一部分用连接串指定值，两套逻辑跑出来的时间边界对不上。排查时可以先跑一句SQL看当前数据库时区和系统时间：

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

5.3 字符集没统一，图表上出现一堆问号

MySQL默认的utf8其实不是完整的UTF-8编码，遇到用户昵称里的Emoji或者生僻字就会变问号。建库建表的时候，直接用utf8mb4：

CREATE DATABASE shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

如果表已经建成了，低峰期可以执行ALTER转换，但要注意这会锁表，最好先在测试环境演练一遍：

ALTER TABLE order_info CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

同时，Python和BI连接串里也要带charset=utf8mb4。这个问题在图上通常表现为“用户名显示成???”，数据本身没丢，只是写入或读取时编码转换出了问题。

5.4 连接数被 BI 打满，业务系统跟着遭殃

还有一次故障，BI平台定时拉取多个看板，把MySQL连接数打满了，线上业务开始报Too many connections。这个坑特别隐蔽，因为数据库本身没慢，是连接数被看板查询占满了。

后来我调整了三个地方：给BI用独立只读账号，限制它的最大连接数；在BI侧把连接池上限调小；重查询全部改为查快照表。只读账号限制连接数可以这样写：

ALTER USER 'report_read'@'%' WITH MAX_USER_CONNECTIONS 20;

用这个账号连接MySQL，最多只能有20个连接，无论BI平台开启多少个线程，都不会无限制地挤占数据库连接池。这个配置的效果不会影响业务账号，适合保护共享实例。

5.5 权限没管好，差点把明细表全暴露了

BI上线后，运营提需求说要看某个数据表，开发图省事直接给了整张表权限。我当时检查后发现，通过这张表能查到用户手机号、地址等敏感信息。后面改成了方案：先建视图把敏感字段过滤掉，再把视图权限授给BI账号。这个教训让我养成了一个习惯：外部系统访问MySQL，一律按“先视图、后只读、最小列”的原则来授权。

6. 我的选型建议和一点体会

6.1 到底选哪种姿势，我给你一个判断方法

经常有人问我这三种姿势到底选哪个，我的回答是先看手里有什么牌。如果你是一个后端工程师，公司没有专职前端，那尽量别一上来就自研，先用纯SQL把指标算对，再用开源BI快速出图，效果立竿见影。如果你本身有前端开发能力，业务又需要把图表嵌到某个管理后台里面，那自研就是最优解，它能让你不再被BI工具的既定样式绑住手。

另外，团队规模也决定了方案走向。两三个人的小团队，开源BI是最低成本的看板方案；二三十人的研发团队，自研可视化反而更容易维护。还有一个判断标准是看MySQL的压力：如果查询都跑在明细表上而且越来越慢，说明该把物化快照做起来了。如果做了快照还是扛不住，那时才需要考虑把分析查询迁到更合适的列式存储，但这是另一个话题。

6.2 数据可视化这件事，口径永远比图表重要

我做过很多次看板之后，越来越觉得最该花时间的不是ECharts配置，也不是BI拖拽，而是跟业务方把“什么是GMV”“什么是活跃用户”“退款算不算销售额”这些问题掰扯清楚。口径定不好，数字对不上，再漂亮的看板也会被业务弃用。只要你能让MySQL里的指标口径稳定、查询高效，后面接BI也好，自研大屏也好，都会顺理成章。先让数据不再吃灰，再谈怎么把可视化做得更好看，这是我个人的实践经验，也是我每次接到可视化需求时提醒自己的第一件事。