市场份额必须用sum(sales)/sum(sales) over()计算，分母为全表总销售额而非分组和；错误写法如sum(sales)/sum(sales) over(partition by category)仅得品类内占比，非全局份额。
窗口函数怎么算「市场份额」而不是简单求和？
市场份额本质是「某商品销售额 ÷ 所有商品总销售额」，不能直接用 SUM() 或 AVG() 得到。必须用窗口函数在分组内做全局聚合再做除法——关键是把分母设为整个数据集的总和，而不是当前分组的和。
- 错误写法：
SUM(sales) / SUM(sales) OVER (PARTITION BY category)→ 算的是品类内占比，不是全量市场份额 - 正确写法：
SUM(sales) / SUM(sales) OVER ()→ 分母不加PARTITION BY，代表全表总销售额 - 如果要按时间维度看变动（比如每月），需先用
GROUP BY month, product_id汇总月度销售，再套窗口函数
怎么加时间维度对比「上月份额」和「本月份额」？
窗口函数本身不处理跨行比较，得靠 LAG() 或 LEAD()。但注意：LAG() 是按排序顺序取上一行，不是按日历月自动对齐——你得先确保数据已按时间严格排序，且补全缺失月份（否则 1 月跳到 3 月，LAG() 就会拉错）。
- 排序必须显式写：
ORDER BY year_month（推荐用YYYYMM格式字符串或日期类型） - 避免用
ORDER BY date后直接LAG(share)：如果某月无销售记录，该月就不存在，LAG()会跳过它 - 补月要用
GENERATE_SERIES（PostgreSQL）或递归 CTE（MySQL 8.0+、SQL Server），再LEFT JOIN销售表
为什么 ROUND() 放窗口外才安全？
在窗口计算中直接对百分比字段 ROUND(share, 4) 可能导致「四舍五入后加总≠100%」——这不是 bug，而是浮点精度叠加四舍五入的必然结果。更稳妥的做法是先算出精确值，最后展示时再格式化。
- 错误示范：
ROUND(SUM(sales) / SUM(sales) OVER (), 4) AS share - 正确做法：保留原始小数（如
DECIMAL(18,6)），应用层或报表工具控制显示位数 - 若必须 SQL 内四舍五入，建议统一乘 100 再
ROUND(..., 2)得百分比数值，避免小数点后过多位干扰
MySQL 8.0 和 PostgreSQL 的语法差异在哪？
核心逻辑一致，但细节容易翻车。特别是 MySQL 对 OVER() 的括号要求更严格，而 PostgreSQL 允许省略空括号（但不推荐）。
- MySQL 必须写：
SUM(sales) OVER ()，不能写成SUM(sales) OVER（会报语法错误） - PostgreSQL 允许：
SUM(sales) OVER ()或SUM(sales) OVER，但后者可读性差，建议统一加括号 -
LAG()默认偏移是 1，但 MySQL 要求显式写LAG(share, 1)，PostgreSQL 可省略第二个参数 - MySQL 不支持
IGNORE NULLS，遇到空值会中断连续偏移；PostgreSQL 支持，可用LAG(share) IGNORE NULLS跳过空值
