WIDTH_BUCKET函数本身不能直接画直方图，仅返回数值所属桶的编号；需配合GROUP BY、COUNT(*)和ORDER BY才能完成直方图统计。
WIDTH_BUCKET 函数到底能不能直接画直方图
WIDTH_BUCKET 本身不绘图，它只是把数值分桶（assign bucket number），返回的是整数编号，不是图形。想出直方图，得靠它配合 GROUP BY 和聚合统计——这是最容易误解的点：有人以为调用一次函数就自动出柱状图，其实它只干“分组编号”这一件事。
正确写法：分桶 + 计数 + 排序缺一不可
典型流程是：WIDTH_BUCKET(value, min_val, max_val, num_buckets) 生成桶号，再按该桶号 GROUP BY，用 COUNT(*) 统计每桶频次，最后 ORDER BY 桶号确保横轴有序。漏掉排序，桶号可能乱序，图表横轴错位。
-
min_val和max_val必须覆盖全部数据范围，否则超出区间的值会被归入桶 0 或num_buckets+1（Oracle/PostgreSQL 行为），导致统计遗漏 - PostgreSQL 要求
min_val < max_val，且所有参数类型需一致（如全为NUMERIC），否则报错ERROR: invalid input syntax for type numeric - 桶数量不宜过大（如 >100），否则小样本下大量桶为空，
GROUP BY结果稀疏，前端渲染困难
SELECT WIDTH_BUCKET(amount, 0, 1000, 10) AS bucket_id, COUNT(*) AS freq FROM sales WHERE amount IS NOT NULL GROUP BY bucket_id ORDER BY bucket_id;
常见错误：NULL、边界值和跨数据库差异
NULL 值不会被分配到任何桶，默认被排除在结果外，必须显式过滤或用 COALESCE 处理；边界值（如恰好等于 min_val 或 max_val）在 PostgreSQL 中：左闭右开（[min, max)），所以 max_val 会进第 num_buckets+1 桶；Oracle 则是左闭右闭，行为不同。
- 如果数据中存在
amount = 1000，上面示例中它不会落在 bucket 10，而是被分到 bucket 11（溢出桶），需要额外WHERE amount < 1000或调整max_val为1000.0001 - MySQL 不支持
WIDTH_BUCKET，得用FLOOR((value - min) / ((max - min) / buckets)) + 1手动模拟，但要注意除零和浮点精度问题 - 当
min_val == max_val时，PostgreSQL 报错ERROR: width_bucket: first argument must be less than third argument，需提前校验极差
性能提示：别在大表上实时算桶再聚合
对千万级表每次执行都走全表扫描 + 计算 + 分组，响应慢。实际使用中，更稳妥的做法是：先用 WIDTH_BUCKET 在物化视图或临时表里预计算桶号，再查频次；或者结合分区字段（如按时间分区）缩小扫描范围。
- 在 WHERE 条件里提前过滤掉明显异常值（如
amount < 0 OR amount > 1e6），避免无效桶参与计算 - 如果只是看分布趋势，可先用
TABLESAMPLE（PostgreSQL）或LIMIT随机采样，再算桶，误差可控且快得多 - 注意
WIDTH_BUCKET是标量函数，无法利用普通 B-tree 索引加速，但若桶范围固定，可建表达式索引，例如CREATE INDEX idx_sales_bucket ON sales (WIDTH_BUCKET(amount, 0, 1000, 10))
真正卡住人的往往不是语法，而是 min/max 的选取是否贴合业务含义、溢出桶是否被意识到、以及不同数据库对边界的定义差异——这些细节不验证，结果看着像直方图，实际频次对不上。
