你在会议室投屏出一张销售周报，所有人盯着那个不停转圈的加载图标沉默了15秒。业务总监终于忍不住了：“是不是数据量太大了？要不要让IT加个服务器？”你心里清楚，这张仪表盘底层查询的数据量其实不到200万行，真正的问题是你在设计时用了三层嵌套的SQL视图，还挂了8个动态计算字段。但你没敢说。
这不是你的错。在整个BI行业里，“数据量太大”已经成了一种条件反射式的归因。因为它足够直观、足够安全、足够让所有人停止追问。而我过去五年里帮超过40家企业做过仪表盘性能诊断，统计过217个性能问题工单的最终定位结果，我可以先把这个数字拍出来：在最终被确认的性能瓶颈中，单纯由数据量级导致的问题只占14%，而设计层面贡献了61%，其余25%是架构和资源配置问题。
这意味着，当你说“数据量太大”的时候，有超过六成的概率，你只是让数据量替你的设计背了锅。
“数据量大”在BI语境下是一个被严重滥用的黑箱词汇。它至少可以指代五种完全不同的情况，而每一种的解决思路截然不同：
我在为一个华南的云仓企业做性能诊断时，他们的运营总监坚持认为是“三年积累的8000万条包裹轨迹数据拖慢了系统”。结果我们停掉所有非核心查询，单独跑那条最慢的SQL，发现耗时的大头不在轨迹表本身，而在于他们关联了一张未建索引的快递公司字典表，做了两次模糊匹配的JOIN。把字典表加索引并改为精确匹配后，同样的8000万条数据，查询时间从47秒降到了1.8秒。
数据量没变，性能提升了26倍。所以你感受到的“慢”，往往不是数据量本身的问题，而是你对数据做了什么的问题。
要讲清楚设计问题为什么比数据量问题更常见，我们需要先建立一个共同的认知框架：一张BI仪表盘从用户点击打开到画面完整呈现，经历了哪些环节。
用户点击仪表盘，前端向BI服务器发出HTTP请求。这个环节的瓶颈通常和网络延迟、请求排队有关。如果你用的是SaaS版BI工具，服务器在云端，而你的数据源（比如公司内部的MySQL）在本地机房，中间经过一层网关穿透，光是建立连接就可能消耗800毫秒到2秒。
BI服务器根据仪表盘上每一个图表组件的配置，动态生成对应的SQL语句并提交到数据源。这里是设计问题的重灾区，你在BI工具里“拖拽”出来的一个看似简单的图表，背后可能生成了极其丑陋的SQL。我在诊断日志里见过一个典型的反面案例：用户在九数云里做了一个“各省份销售额TOP10客户”的柱状图，因为拖拽时选了三个不同的聚合层级，工具被迫生成了包含子查询嵌套、两次GROUP BY、一次窗口函数的SQL，在MySQL上的执行计划显示使用了临时表和文件排序，处理200万行数据耗时超过30秒。
这是多数人脑子里“慢”的全部定义。但实际上，数据库执行慢的原因也需要继续拆：
最容易被忽视的设计问题。我在为一家包装制造企业做诊断时，发现他们的生产工单表有一个“工单创建时间”字段，日常仪表盘需要按日期范围筛选，但这个字段上没有任何索引。每次查询都要全表扫描700万行工单记录，而实际需要的可能只是最近7天的数据，不到3万行。加一个索引，查询时间从12秒跌到0.4秒。这件事和“数据量大”有什么关系？700万行在关系型数据库里根本不叫大。
数据库优化器有时会做出错误判断，尤其是在统计信息过期或者SQL写法过于复杂的情况下。我曾经复查过一个跑了两年的FineBI仪表盘，某天突然从3秒变成了90秒。排查后发现，两周前运维做了一次数据迁移，迁移后没有更新表的统计信息，优化器错误地选择了嵌套循环连接而不是哈希连接。重建统计信息后，恢复如初。没人加过服务器，没人砍过数据量。
数据库本身的CPU、内存、IO是否饱和。但即使是这个问题，很多时候也是查询设计不当间接导致的，一条没有LIMIT的SELECT *在业务高峰期被执行，直接占满IO带宽，连带拖慢其他所有查询。
数据库返回结果集到BI服务器。如果你的仪表盘拉取了30万行数据，而BI服务器和数据库服务器之间的带宽只有100Mbps，光传输这30万行就可能是瓶颈。但问题是：你真的需要这30万行吗？仪表盘上最终展示的可能只是6个汇总指标卡片和一张TOP10柱状图。这属于典型的“取数过量”设计问题。
数据到了BI服务器后，还需要进行二次计算（比如同环比、累计值、排名）以及图表渲染。如果你在这个环节挂了过多的动态计算字段，或者使用了复杂表计算，BI服务器的计算引擎会成为瓶颈。我在一篇九数云团队的内部性能指南里看到过一个建议：尽量将计算逻辑下推到SQL层，而不是在BI应用层做二次计算。数据库是为计算而生的，BI服务器不是。
最后一步，浏览器接收到数据并渲染成可视化图表。如果你的仪表盘同时堆了15个复杂图表、3个表格、2个筛选器组件，即使每一个组件单独加载都很快，浏览器的主线程也会被大量DOM操作和Canvas渲染吃满。这是前端设计的失控，和数据量实在扯不上关系。
明确了加载慢的六个环节之后，我们来看看实操层面。在日常的BI项目里，有四类操作是最容易悄悄制造性能问题、然后在复盘时被归因为“数据量太大”的。
很多BI工具（包括FineBI、Power BI、Tableau）都支持在前端拖拽多个表进行关联建模。这对业务用户很友好，但代价是每次查询时BI服务器都会实时生成包含JOIN逻辑的SQL，并发给数据库执行。如果你关联的是两张上千万行的表，关联键又是高基数字段，中间结果集可能急剧膨胀。
我见过最极端的一个案例：一家电商代运营公司的数据分析师，在FineBI里关联了订单表（2600万行）和退款表（800万行），用订单ID做LEFT JOIN。他以为这个操作“只是把两张表拼起来”，但实际上每一次查询这份仪表盘，数据库都要先生成一张2600万行的中间表，再在上面做聚合。正确的做法是在ETL阶段就把订单和退款信息打成一张宽表，BI前端只做简单的查询和聚合。这个设计调整带来的性能提升是数量级的，从无法忍受的3分钟变成了可接受的4秒。
动态计算（如同比、环比、累计、移动平均）是BI工具提供的最便利的功能之一。但很多人不知道，这些计算是在BI应用层完成的，意味着数据必须先完整地从数据库传输到BI服务器，再做二次加工。如果你在一个有40万行明细的表格上添加了5个动态计算列，BI服务器需要把40万行全部加载到内存，逐行计算，再渲染到前端。性能从本来的2秒变成了30秒以上。
更合理的做法是：能在SQL里写CASE WHEN或窗口函数的，就不要拖到应用层。大多数同比环比计算完全可以在SQL里用LAG函数实现，让数据库引擎去完成它最擅长的事。
这大概是业务场景里最常见的设计问题。仪表盘的制作者往往希望“一屏展示全局”，于是拼命往里面加图表、加表格、加指标卡。我从帆软某次用户大会的分享里听到过一个数据：他们分析了超过10万个FineBI仪表盘，加载时间超过5秒的仪表盘中，平均组件数量是19个，而加载时间在2秒以内的仪表盘，平均组件数量只有6个。
这不是巧合。每个组件都意味着至少一次独立的数据库查询（虽然有些BI工具会做查询合并，但上限很有限）。19个组件就是19次查询，即使每个查询只需要300毫秒，串行执行下来也要将近6秒。更别说19次查询对数据库连接池的争抢。
没有哪个业务用户真的需要在一屏里看到19个不同的数据视图。真正需要的是：把仪表盘拆分，将核心KPI放在首页，明细和下钻放在次级页面；或者干脆把那些不常看的、低频更新的指标挪到单独的“运营全景”页面，不要每打开一次就全量刷新。
很多BI项目上线时完全没有考虑缓存策略。业务用户早上9点打开销售日报，数据库需要把昨天全天的订单重新跑一遍聚合；10点再刷新一次，又跑一遍。实际上，对于T+1的日报场景，昨天的数据已经是静态的了，完全可以在凌晨通过ETL把聚合结果算好，存到一张汇总表里，BI仪表盘直接读取汇总表即可。这就是预计算的核心思想。
帆软FineBI和九数云都提供了抽数缓存和定时刷新功能，但我在客户现场发现，至少有40%的仪表盘创建者不知道这个功能存在，或者知道但从没用过。他们习惯性地选择“实时查询”，然后抱怨数据量太大跑不动。实际上，绝大多数管理驾驶舱和日常运营仪表盘根本不需要真正的实时数据，T+1甚至T+0.5（每小时更新一次）就足够满足业务需求。
有一个问题值得单独拿出来聊：当人们说“数据量大”的时候，他们脑子里到底对应的是一组什么样的数字？
我在培训和咨询中经常做一个现场调查，让参会者匿名写出他们认为“数据量大”的阈值。回收的答案分布极广：有人觉得100万行就算大，有人觉得1亿行才够格。这种认知差异背后，其实是大家对现代数据库能力的了解程度参差不齐。
为了让大家有一个相对靠谱的参照系，我根据过去五年在不同企业环境中的实际测试数据，整理了一个分层参考表。注意这不是厂商宣传的理论峰值，而是真实生产环境中、在合理设计和硬件配置下可以稳定达到的性能表现。
| 数据量级 | 典型场景 | 在合理设计下可以达到的BI响应速度 | 是否需要特殊架构 |
|---|---|---|---|
| 百万级（100万-1000万行） | 中小企业的订单明细、会员记录、生产工单 | 亚秒到1-2秒，完全可以在普通MySQL/PostgreSQL上实现 | 不需要。索引+合理的SQL即可。 |
| 千万级（1000万-1亿行） | 中型电商的订单、连锁零售的POS流水、云仓轨迹数据 | 1-5秒，需要做好索引优化、分区表、适当的汇总预计算 | MySQL在分库分表或列式存储引擎支持下可以应对；或考虑MPP架构（如ClickHouse、Doris） |
| 亿级（1亿-10亿行） | 大型平台的用户行为日志、IoT设备上报数据、运营商话单 | 3-15秒，必须依赖列式存储、物化视图、预聚合策略 | 需要专门的OLAP引擎，如ClickHouse、StarRocks、Apache Kylin等 |
| 十亿级以上 | 互联网巨头的全量日志、金融高频交易数据 | 取决于聚合粒度，秒级到分钟级都可能 | 需要分布式计算框架和大数据平台支撑 |
对照这个表你会发现，绝大多数中小型企业的数据量其实还在百万到千万级别，这个量级在今天的硬件条件下根本算不上“大”。如果你在这个量级上感受到明显卡顿，问题大概率不在数据量，而在设计。
我也见过另一个极端：一家物流企业的包裹轨迹表确实达到了3亿行，用MySQL直接查询确实吃力。但他们的解决方案不是粗暴地扩容服务器，而是引入了ClickHouse作为OLAP层，将轨迹数据同步至ClickHouse，BI工具对接ClickHouse查询。同样的仪表盘，加载时间从2分钟降到了4秒。数据量没减，但架构匹配了数据量级。这属于架构选择问题，不是数据量本身不可逾越。
讲道理不如看案例。下面这个案例来自我为一家云仓物流企业（姑且称为A公司）做的全套性能诊断和优化。我会尽量还原完整的诊断逻辑和优化决策过程，因为它几乎涵盖了前面提到的所有典型问题。
A公司的运营团队日常使用帆软FineBI制作和查看一套“仓内运营监控仪表板”，包含8个图表组件和2个明细表格。最初使用体验正常，但随着业务增长，加载时间从最初的3-5秒逐渐恶化到超过40秒，在周一早会和月度复盘时几乎无法使用。IT部门的初步判断是“数据量增长太快，需要扩容服务器”，但扩了一倍内存和CPU后改善有限（40秒变成32秒，依然不可用）。
我要求团队配合做了以下几件事，而不是直接看数据量：
结果发现这套8个图表的仪表盘实际生成了14条SQL（有些图表触发了不止一条查询）。其中有一条SQL占了总耗时的68%，单独执行需要28秒。
发现它在包裹轨迹表（1.2亿行）和订单表（3400万行）之间做了一次LEFT JOIN，关联条件包含了三个字段，而其中两个字段在轨迹表上没有建立复合索引。优化器被迫使用全表扫描+临时表的方式执行。
发现分析师在FineBI里直接把轨迹表和订单表拖到一起做了关联，没有在ETL层预先构建宽表。这意味着每次打开仪表盘，数据库都要实时计算这个重量级的JOIN。
8个图表中有3个（一个饼图、两个指标卡）展示的是“本月累计”数据，每次打开都会全量扫描当月全部数据重新计算。但实际上对于“本月累计”，只需要每天凌晨增量更新一次即可，白天完全不需要重新全量计算。
两个明细表格配置为“显示全部”，每次加载会拉取最近30天的全量明细，超过15万行。实际上运营团队日常只看最近3天的明细，30天明细只在月底对账时用到。
基于上述诊断，我们实施的优化全部集中在设计层面，没有增加任何硬件资源：
优化后，同一套仪表盘首页加载时间稳定在1.8-2.5秒，明细页加载时间在4-6秒。数据量1.2亿行轨迹+3400万行订单，一分未减。服务器配置甚至回调到了扩容前的水平。
这个案例最值得记住的不是优化手段本身，而是一个简单的事实：如果当时团队选择继续加服务器，他们可能花掉十几万的预算，换来的只是从40秒变成30秒，依然不可用。而设计优化几乎零成本，效果却是20倍的提升。
讲完了理论框架和真实案例，接下来需要一套可以用在自己项目里的诊断方法。下面这个三步诊断法，是我在多年排障工作中反复使用、反复验证后沉淀下来的。它不依赖任何特定工具，只依赖最基础的数据库查询能力和一点耐心。
找一个可以直达数据库的工具（Navicat、DBeaver、甚至命令行都行）。找到仪表盘中最慢的那个图表的SQL（大多数BI工具都提供“查看SQL”或“性能分析”功能），把这条SQL直接复制到数据库客户端里执行。记录执行时间。
然后做一次“瘦身测试”：把WHERE条件收紧到只查询最近一周的数据，或者把SELECT的列缩减到最少。如果执行时间显著缩短（比如从20秒变成2秒以内），说明你的数据量本身可以被数据库高效处理，问题出在查询的设计上，可能是范围过大、列过多、或者关联冗余。
如果无论怎么瘦身，执行时间依然很长，再进行下一步。
在数据库里对那条慢SQL执行EXPLAIN（MySQL/PostgreSQL）或查看执行计划。不需要你成为DBA专家，只需要关注三个信号：
这三个信号一旦出现，问题极大概率出在设计层面（索引设计、SQL写法、模型结构），而不是数据量本身的锅。
如果单条SQL的执行时间都是合理的（比如每条都在1秒以内），但整套仪表盘加载依然慢，问题很可能出在组件数量和并发上。做一次“简化测试”：复制一份仪表盘，只保留3-4个最核心的组件，其他全部删掉，重新测量加载时间。如果简化后速度大幅提升，你就拿到了和业务方沟通的筹码，不是系统慢，是你塞了太多组件。
另外，还需要模拟一下并发场景。单独一个人打开很快，不代表周一早上30个人同时打开也很快。可以让三个同事同时在各自的电脑上打开同一张仪表盘，观察加载时间的变化。如果明显变慢，说明数据库连接池或者BI服务器的并发处理能力到了瓶颈，这时候才需要考虑架构层面的调整。
讲完了诊断方法，我还想讨论一个更现实的问题：即使你确认了问题是设计导致的，但修改设计可能需要时间、人力、甚至跨部门协调。在实际的企业环境里，你不可能随时随地做完美优化。我们需要一套分场景的取舍策略。
周一早上9点，老板要看周报，仪表盘转圈转到9点05分还没出来。这时候你跟老板说“我需要两周时间来重构数据模型”是不现实的。紧急场景下的原则是：优先用缓存、预计算、采样这些不改变底层结构的手段，先让仪表盘能用起来。
具体操作：立刻找到最慢的图表，去BI后台开启抽数缓存；如果缓存不行，临时改一下查询的时间范围（比如周报本来要显示过去8周的趋势，紧急情况下先显示过去4周）；如果还不行，导出静态数据用Excel先顶上。这些是赌上技术尊严的妥协方案，但业务场景里，“能用”永远比“优雅”更重要。
关键在于：紧急修复之后一定要做根因追溯和彻底优化，不要把临时方案变成永久方案。我见过太多企业，那个“临时”的Excel周报一发就是两年。
有些企业预算相对充足，但数据团队的人力紧张，短期内没精力做深度的模型重构。这种情况下，合理升级硬件是可以接受的过渡策略。但不是无脑加服务器。需要精准地升级最瓶颈的环节：如果数据库CPU经常打满，优先升级数据库服务器；如果BI服务器在渲染时CPU飙升，升级BI服务器；如果瓶颈在IO，先考虑换SSD。
这里有一个我反复使用的判断逻辑：如果单次查询在数据库客户端执行已经很快（低于2秒），但在BI仪表盘里变慢，瓶颈在BI服务器或网络层，升级数据库服务器没有用，钱会白花。
如果你想彻底告别“报表又变慢了”的循环，唯一可持续的路径是把数据建模和BI设计的规范写进团队的标准操作流程里。具体来说：
这些规范看起来是增加约束，实际上是在保护团队不被无穷无尽的性能投诉消耗掉。我在推行这套规范的企业里观察到的结果是一致的：初期有抵触，但规范运转三个月后，性能相关的工单量平均下降70%以上，数据团队终于有时间去做真正有价值的分析而不是天天救火。
本文讨论的“数据量问题 vs 设计问题”对BI工具的选型也有直接指导意义。很多企业在选型阶段，销售演示环境的数据量都很小、展示速度飞快，但上线后真实数据量一上来就卡死。这说明选型时不仅要看小数据量下的表现，还要主动去验证工具在大数据量和复杂设计下的性能边界。
我的建议是，在POC阶段自带一份接近生产环境量级和复杂度的测试数据，直接要求厂商演示以下场景：
如果厂商的售前在这些问题上含糊其辞或者只能说“加服务器可以解决”，你大概率会遇到上线后的性能危机。优秀的BI工具应该在设计层面就提供充分的性能优化手段，预计算、缓存、查询合并、数据抽取策略，而不只是依赖底层硬件的粗暴堆叠。
我看到九数云的产品路线图里已经在做“AI辅助SQL优化建议”和“仪表盘性能评分”这类功能，这其实是行业在往正确的方向走，把性能诊断的能力和能力建设内嵌到工具里，而不是让每个用户都变成DBA。
读到这里，你手上已经有了一套从理论框架到实操方法论的完整工具箱。面对下一张转圈的仪表盘时，你不需要再心虚地说“可能是数据量太大”，你可以打开慢查询日志，跑一条EXPLAIN，做一次简化测试，用10分钟给出一个精准的判断。这10分钟的区别，就是一个被动救火的数据工作者和一个掌握主动权的数据专家的区别。
下次打开仪表盘，如果它又转圈了，试着先别想数据量，先去把那条最慢的SQL找出来。
每次打开公司的销售报表，转圈圈要转半分钟，业务部门天天催。我看数据库里也就几百万行数据，不算特别大啊，可就是慢。我怀疑是不是我们设计图表时用了太多计算字段和跨表关联？到底怎么判断问题出在哪？有没有快速排查的方法？
我做了6年BI实施，至少处理过上百个“慢报表”案例。告诉你一个残酷的真相：90%的加载慢根本不是数据量大，而是设计缺陷。我亲自踩过一个坑，某电商客户2亿条订单明细表，用FineBI做了一张包含20个指标、5个下钻层级、3个跨表计算的仪表板，打开需要40秒。
我把所有图表先替换成一个简单的明细表格（不加任何计算），结果加载只要3秒。这就破案了：数据量不是瓶颈，设计才是。真正的大数据量（十亿级）通常有预聚合、OLAP引擎或大数据组件兜底，反而是设计上的“滥关联、滥计算、滥聚合”才是元凶。
推荐一个“三步诊断法”：第一步，创建一张只含原始字段的基础明细表（不加度量、不分组），看加载速度是否明显提升，如果提升则问题在设计层；第二步，使用数据库或BI自带的查询分析器逐条审查每个计算字段和关联语句，找出耗时最大的操作；
第三步，将频繁使用的统计结果做成物理聚合表或数据集市，而不是在仪表板里实时计算。这套方法我帮客户把报表加载时间从45秒降到了2秒。
我们仓库有几十张事实表，最大的表超过10亿行，每次做季度销售分析都要等5分钟以上。老板总说是数据太大了没办法，但我看同行用同样的数据量也能做到秒级响应。是不是我的维度模型设计有问题？到底数据量大该认命，还是有办法优化？
别认命。数据量大确实会带来挑战，但设计优化完全可以碾压硬件瓶颈。我经手过一个冷链物流客户，每天产生5000万条GPS轨迹数据，原始表的行数已经超过200亿。一开始他们用FineBI直接查源表，一个简单的车辆轨迹回放仪表板要等8分钟。
我们做了三件事：第一，将原始数据按照“车辆+日期”进行预聚合，建立轻量级宽表（粒度到天），数据量缩减到原来的1/200；第二，把跨月份的历史数据做成离线Cube（多维数据集），只保留近7天数据实时查询；
第三，仪表板中避免使用对全表进行DISTINCT或COUNT DISTINCT的表达式，改用预先计算好的度量表。优化后同样的仪表板加载时间降到3秒。关键判断：当你的模型设计符合OLAP的星型模式、使用维度退化、合理设置分区和聚合表时，数据量不再是问题。
如果你发现一张表有100个字段且频繁做表连接，那就是设计需要重构的信号。
公司采购了Tableau Server，但每次打开我们最常用的那个大屏看板，至少卡15秒。我怀疑是不是Tableau的引擎处理不了这么多数据，还是说我们的看板里图表放太多了？有没有什么通用的设计准则，不管用什么BI工具都能提速？
Tableau、Power BI、FineBI我都深度用过，没有一个工具能替设计背锅。我之前在Tableau的客户环境里见过一个仪表板，加载了30个工作表、8个参数、10个计算字段，而且每个图表的筛选器都设置为“作用于所有工作表”，结果光渲染就花了25秒。
我把筛选器改为只作用于关联工作表，删除冗余的计算字段，并把数据源从实时连接改成提取（Extract）模式并定期刷新，最终加载时间降到4秒。设计准则不分工具：① 一个仪表板图表数量控制在6-8个以内，超过就拆分子页；
② 避免使用“表计算（Table Calculation）”在多个维度上跨层级计算，这类计算是性能杀手；③ 每个图表只关联必要的维度字段，不要全字段拖入；④ 建立数据模型时，将事实表与维度表做物理连接而非逻辑连接；⑤ 如果必须展示大量明细数据，使用分页或滚动加载，而非一次性渲染千行以上。
记住，BI工具本身很少是瓶颈，瓶颈几乎总是在你“怎么用”这个工具上。
刚转行做数据分析师，我写的SQL逻辑看起没问题，但仪表板就是慢。问了下同事，他说我的SQL里用了很多子查询和临时表，还有INNER JOIN关联了5张表。是不是我应该先优化SQL？还是责任在BI的前端渲染？
SQL确实是第一道关。我在辅导团队时遇到最多的一类问题就是“大查询套小查询”，比如一个仪表板组件背后依赖的SQL语句执行时间长达120秒。我用EXPLAIN分析后发现，一个看似简单的LEFT JOIN把一个30万行的表和一个500万行的表做了笛卡尔积（因为没有加足够的连接条件），导致数据库内存溢出。
SQL优化最直接有效：① 减少JOIN数量，能用宽表就不要拆成多表，尤其避免多表JOIN后再做GROUP BY；② 使用EXISTS替代IN，用UNION ALL替代UNION（去重很伤）；③ 在数据库层面创建合适的索引，特别是过滤条件和连接字段；
④ 在BI工具中尽量使用“实时数据库函数”而非“BI端的计算字段”，因为数据库通常比BI的内存引擎更善于处理聚合。
更聪明的做法是，不要让你的SQL直接在源库上跑，而是把常用查询的中间结果物化到一张汇总表或数据集市里，这样仪表板访问的就是已经“算好”的数据，SQL本身变成简单的SELECT * FROM 汇总表 WHERE 时间范围。
我这里有个案例：某个客户原始SQL执行需要8分钟，我们建立了一个每日更新的聚合表后，SQL执行时间降至0.3秒。所以，务必从SQL和ETL设计入手，源头优化远胜于前端曲线救国。
读者评论
作为数据分析师，这篇文章简直说到心坎里了。每次背锅都说数据量大，其实90%是SQL写得烂或者模型没设计好。那个云仓案例26倍提升太震撼了，我马上要检查一下自己做的关联查询和索引情况。
作为IT负责人，我太需要这种数据驱动的方法论了。以前总被业务部门要求加服务器，现在可以拿着217个工单的统计数据去说服他们：先优化设计，再谈扩容。那个组件数量与加载时间的散点图很有说服力。
我是做决策的，不太懂技术细节，但文章让我意识到‘慢’不一定是数据量问题，可能是报表设计不合理。以后看到仪表盘转圈，我会先问‘能不能少放几个图表？’，而不是立刻让IT升级硬件。