在日常数据分析中，Excel 数据透视表几乎是每个人都会用、也都依赖的工具，以下面的数据结构为例：
选好字段：
再切换一下“求和 / 平均 / 最大 / 最小”，几下点击，就能得到一张清晰的统计结果。
直观、好用、上手快。
但当统计逻辑开始变复杂时，你可能也会慢慢遇到一些“用着不太顺”的时刻。
下面用一个真实的数据透视表场景，来对比看看：👉 这些事情，如果放到 SQL 里，会发生什么变化。
一、这个 Excel 透视表在做什么？
原始数据大致是这样的结构（和你日常见到的几乎一致）：
日期
ENB / 小区
网络制式（LTE / NR）
流量 GB
在 Excel 中，我们通过数据透视表完成了：
按日期作为行
按网络制式作为列
对流量 GB 求和
可随时切换为：
这一步，本身没有任何问题，而且对于一次性、临时统计来说，数据透视表依然是首选。
二、同样的事情，用 SQL 怎么做？
如果把这批数据放进 SQLite（或任何数据库）中，最基础的写法其实非常接近“数据透视表的本质”。
SELECT 日期, 网络制式,SUM(流量GB) AS 流量汇总FROM aaGROUP BY 日期, 网络制式;
如果你想要的不是求和，而是：
平均值 → AVG(流量GB)
最大值 → MAX(流量GB)
最小值 → MIN(流量GB)
只需要改一个函数即可。
这一点上，其实和数据透视表是完全等价的。
三、真正的差异，从“加条件”开始出现
问题往往不是“能不能算”，而是：
能不能在不打断流程的情况下，继续加条件。
1️⃣ 限制日期区间
在 Excel 中：
你可能需要：
改数据源范围
或复制指定日期的数据出来到一张新表中
再重新建一个透视表
在 SQL 中，只是一个 WHERE：
WHERE 日期 >='2026-01-01'AND 日期 <='2026-01-05'
原有统计逻辑，完全不用动。
2️⃣ 只统计“流量大于某个阈值的小区”
在 Excel 中：
而在 SQL 中，这类条件可以直接进入统计表达式本身：
SUM(CASE WHEN 网络制式 = 'LTE' AND 流量GB >10 THEN 流量GB ELSE 0 END ) AS LTE流量大于10G的流量求和
这一点非常关键：
SQL 的条件，不一定只能写在 WHERE 里，这个谁用谁知道，真的好使
四、一个完整的「SQL 版数据透视表」
把上面的需求组合起来，就得到了你给出的这个 SQL：
SELECT 日期,SUM(CASE WHEN 网络制式 ='LTE' AND 流量GB > 10 THEN 流量GB ELSE 0 END ) ASLTE流量_大于10, SUM(CASE WHEN 网络制式 ='NR' AND 流量GB > 10 THEN 流量GB ELSE 0 END ) AS NR流量_大于10,SUM(流量GB) AS 总流量,SUM(CASE WHEN 网络制式 = 'LTE' AND 流量GB > 10 THEN 流量GB ELSE 0 END) * 1.0 / SUM(流量GB) AS LTE流量大于10的小区流量占比--分子乘以1.0规避整数相除结果是整数的问题 FROM aaWHERE日期 >='2026-01-10'AND 日期 <= '2026-01-15'GROUP BY 日期;
这一条 SQL，其实完成了 Excel 中
多次来回操作才能做到的事情：
而且是在同一个统计上下文里完成的。
五、SQL 还能顺手做的几件“小但很爽的事”
这是 Excel 数据透视表很难自然做到的地方。
1️⃣ 直接在 SQL 中控制显示格式
比如：
ROUND(SUM(...) *100.0/SUM(流量GB), 2) ||'%'AS 流量占比
结果出来就是可以直接放进报表的格式。
2️⃣ 同一份数据，派生出多种统计口径
大于 10GB
大于 20GB
Top N 小区
不同网络制式占比
在 SQL 中，本质只是多写几个 CASE，而不需要复制多份数据、建多个透视表。
3️⃣ 统计逻辑可以被“保存”和“复用”
而不是只存在于某一个 Excel 文件里。
六、回到工具选择本身
说到这里，其实结论已经很清晰了：
真正的价值，并不在于“替代 Excel”，而在于：
把 Excel 中已经成熟的分析思路，升级为 SQL 工作流。
七、结语：这是一次范式的变化
你并不是在学“另一种工具”。
而是在把数据处理这件事，从：
转变为：
SQL 不是更复杂，而是更稳定。
而 SQLite 的意义，正是在于：它让这种能力，变得足够轻量，足够日常。
