我正在寻找使用 SQL 表构建简单 SMS 计费功能的最佳方法。
我有一种机制，通过该机制将SMS购买到表中：例如+1000。
我将有正在执行的交易，并且随着SMS的使用，一次将减少-1。
我需要有一个流程，在处理交易之前首先检查余额是否高于 1。
我在这里担心的是，在每 -1 次 SMS 交易之前，我需要对余额进行查找，然后只有在余额高于 +1 时才处理 SMS 交易，这可能会对性能产生不利影响。
实现此目的的"性能"方法是什么？像下面这样的"运行总余额"？
TID amt balance user_Id
--- ----- ------- -------
1 +100 100 a
2 -1 99 a
3 -1 98 a
4 -1 97 a
5 -1 96 a
一个查询来检查运行总值，如果为正值，则执行运行余额更新并继续？
这个规模会有多大？此表每秒可能会执行数百个此类事务。
谢谢
您可以按以下公式计算运行总计：
select t.*, sum(amt) over (partition by user_id order by tid) as balance
from t;
这是否满足您的性能需求尚不确定。 您可能需要添加一个触发器来维护每个user记录中的余额，以便您可以轻松访问最新值。
你的问题很难回答，这取决于许多权衡。
每秒数百个事务并不是一个巨大的负载，我将从"干净"的方式开始构建它而不进行非规范化。
在非常一般的术语中，只要您的数据库可以使用索引进行搜索，从许多事务中计算 SUM 不会比从一条记录中读取它明显慢。
在现实世界中，预计算实际上可能更慢。使用触发器更新预计算的值可能会变慢(额外的查找/事务(，并且由于额外的查找和计算工作，更新运行总计可能会变慢。
我会构建一个负载测试环境，并针对真实的、可观察到的性能挑战不断优化，而不是提前优化。