Liquid是否会拖慢Looker仪表盘性能？LookML改写性能确认方法

• 直接对比两端生成SQL的数据库执行效率
  分别在改写前后，从Looker的查询详情页拿到Explore、仪表盘实际下发到数仓的完整原生SQL，跳过Looker层直接在数仓侧执行，对比执行计划、扫描分区/数据量、实际运行时长。核心判断逻辑是：如果改写后生成的SQL能根据用户选择的参数，砍掉原CASE WHEN里不需要计算的分支，甚至能直接命中表索引、分区裁剪规则，大幅减少扫描数据量，就会带来明确的查询提速；如果改写后生成的SQL嵌套了更多无效判断、扫描数据量和改写前一致甚至更高，就会拖慢速度。
• 基于Looker内置监控做同维度历史对比
  进入System Activity的查询历史看板，筛选改写前后至少1周的同范围查询（保持筛选条件、访问时段、访问用户群一致，排除缓存命中的查询样本），对比三个核心指标：数仓执行耗时、Looker SQL生成耗时、仪表盘前端渲染耗时，统计P50、P95分位的耗时变化，不要拿单次查询的结果下结论。
• 做控制变量的场景化压测
  复制两份完全一致的仪表盘/Explore，分别保留原CASE WHEN逻辑和改写后的{% if %}逻辑，覆盖日常常用筛选组合、全参数选中的极端场景，用相同并发量重复跑20次以上，去掉首尾极值计算平均耗时，重点关注极端场景下会不会出现改写后SQL冗余度飙升、性能骤降的问题。

• 常规规范使用的前提下，Liquid本身不会带来可感知的性能损耗。Liquid的逻辑是在Looker服务端生成SQL的阶段做字符串拼接，整个处理过程耗时基本在毫秒级，和数仓侧SQL执行动辄秒级甚至分钟级的耗时比，占比可以忽略。
• 只有不规范的Liquid写法才会间接拖慢整体性能，常见问题包括：
  • 写了上百层嵌套的{% if %}分支，SQL生成阶段要做大量冗余判断
  • 滥用{% render %}这类需要关联拉取大量其他LookML元数据的语法，拉长SQL生成时间
  • 没做参数兜底逻辑，特定参数选择下会生成无分区过滤、带笛卡尔积的错误SQL，导致数仓侧执行耗时暴涨——这类问题本质是SQL逻辑错误，不是Liquid本身的性能问题
• 额外需要注意：如果Liquid动态拼接的逻辑导致相同用户查询的缓存键频繁变化，会拉低Looker的默认缓存命中率，相同查询重复下发到数仓，会间接让用户感觉仪表盘加载变慢，测试时需要同步关注缓存命中率的变化。

内容的提问来源于stack exchange，提问作者Hung Ho Phan