阶梯计费应使用函数而非存储过程，因存储过程无法返回标量值、不能嵌入查询、调试困难且易出错；仅适用于带事务的批量结算场景，如按月生成账单并回滚失败操作。
不推荐在存储过程中实现阶梯式计费逻辑——它无法返回标量值，不能嵌入查询，调试困难，且容易因变量作用域或隐式类型转换出错。真正该用存储过程的场景，只有带事务的批量结算（如“按月生成所有用户账单并写入 billing_history，失败则回滚”）。
为什么 CALL 不能替代 SELECT ... calc_fee(usage)
存储过程本质是执行单元，不是计算单元。你无法在 SELECT 里直接调用它来算每行的费用：
-
CALL calc_step_price(@qty, @fee)必须提前声明@fee变量，且只能返回单个 OUT 参数，不能用于聚合、排序或视图 - 想在报表中显示
amount, calc_step_price(qty) AS fee？语法报错：MySQL 不允许存储过程出现在表达式位置 - 调试时错误堆栈不指向具体行号，
DECLARE变量在嵌套BEGIN...END块中易混淆作用域
必须用存储过程时：只封装「事务性批量结算」
如果你的业务要求是“每月1号对全部活跃用户执行阶梯电费结算，并记录到历史表”，这时才轮到存储过程上场。关键约束有：
- 所有阶梯规则必须预加载进局部变量或查一次
pricing_tiers表缓存，避免循环中反复查表锁表 - 结算逻辑必须显式开启事务：
START TRANSACTION，并在 INSERT 到billing_history后检查ROW_COUNT() - 失败时用
ROLLBACK，成功后COMMIT；不要依赖 AUTOCOMMIT，否则部分用户写入成功、部分失败会导致数据不一致 - 禁止在存储过程中对触发它的表做 SELECT（比如在
bill_records的触发器里再查bill_records），MySQL 会直接报错
FUNCTION 才是阶梯计费的正确载体
函数支持 RETURN、可嵌入任意 SQL 上下文、能被视图和子查询复用。实现三档电量计费时，注意三个硬点：
- 输入参数必须用
DECIMAL(10,2)，不用FLOAT或DOUBLE，否则260.00 - 259.99可能得0.010000000000000009 - 每段用量必须显式截断：
part2 = LEAST(GREATEST(consumed - 260.00, 0), 340.00)，不能靠条件判断拼逻辑 - 最后一档边界设为
999999999.99或用GREATEST(consumed - 600.00, 0)，避免漏掉超大用量
复杂点不在“怎么写”，而在“怎么让每档边界严丝合缝”。很多人用 BETWEEN min AND max，结果 260.00 落进第二档——因为第一档写了 BETWEEN 0 AND 259.99，留下缝隙。统一用左闭右开区间，配合 ORDER BY min_amount DESC LIMIT 1 查档位，才是稳定解法。
