很多数据团队处理报表变慢的方式，是先救火。
业务在群里说：“这个看板怎么又打不开？”运营等着开会，老板已经进会议室，BI 页面转了半天还没出来。数据同学赶紧去看任务、看查询、看集群资源。有人先加并发，有人先改 SQL，有人把时间范围缩短，有人临时导一份结果给业务。
问题解决了，群里安静下来。然后下周，它又慢一次。
报表慢看起来是一个体验问题，实际上经常是数据工程问题、模型设计问题和团队协作问题的交汇点。
如果每次都只把它当成临时故障处理，团队会一直在救火。
慢，不只是用户体验差
一个看板慢几秒，听起来好像没那么严重。比起数据错、任务挂、指标口径冲突，性能问题似乎只是“不够快”。
但在实际业务里，慢会改变使用方式。
报表太慢，业务就不愿意自己查，开始让数据同学代查。查询经常超时，分析师就不敢加维度，只能看粗粒度结果。会议上页面打不开，大家就会截图、导 Excel、建临时表，新的口径分裂又开始出现。
慢到一定程度，数据产品就会从“自助分析工具”退化成“数据团队人工客服”。
所以性能问题不只是技术洁癖。它会影响数据被使用的方式，也会影响团队信任。
不要一上来就改 SQL
查询慢时，很多人的第一反应是看 SQL。有没有全表扫描？有没有不必要的 join？有没有函数写在分区字段上？有没有笛卡尔积？有没有 distinct 太多？
这些都应该看，但不应该只看 SQL。
因为 SQL 只是问题出现的位置，不一定是问题产生的源头。
有时 SQL 写得确实差。有时是模型层没有提前聚合，导致 BI 每次都扫明细。有时是宽表字段太多，列裁剪不生效。有时是分区设计不合理。有时是看板默认查询一年数据。有时是同一时间太多人刷新。有时是底层资源被其他任务抢走。
如果只盯着 SQL，很容易陷入局部优化。
更好的办法，是把一次查询超时拆成几层看。
