本文针对高频并发调用 sms api（尤其是 otp 场景）导致 mysql 查询积压、响应延迟的问题，提出索引优化、数据结构重构、事务化扣减及 api 限流四重解决方案，兼顾实时性、一致性与抗压能力。
本文针对高频并发调用 sms api（尤其是 otp 场景）导致 mysql 查询积压、响应延迟的问题，提出索引优化、数据结构重构、事务化扣减及 api 限流四重解决方案，兼顾实时性、一致性与抗压能力。
在高并发 SMS 接口（如 example.com/send_sms?apikey=...&contact=...&text=...）场景下，原始实现每次请求都执行 SELECT SUM(credit) 查询并依赖应用层判断余额，不仅引发大量重复全表扫描，更因多行记录累加设计+无索引+非原子操作，造成严重的性能瓶颈与竞态风险。以下是系统性优化方案：
✅ 1. 索引加速查询（立即生效）
为 apikey 字段添加 B-Tree 索引，将 O(n) 全表扫描降为 O(log n) 精准定位：
ALTER TABLE `users_credit` ADD INDEX `idx_apikey` (`apikey`);
⚠️ 注意：若
apikey列存在大量重复值或为空，需先清洗数据；索引命名建议语义化（如idx_apikey），避免使用反引号包裹关键字。
✅ 2. 重构数据模型：单行总余额 + 原子扣减（核心改进）
废弃“多行流水累加”模式，改为每个 API Key 对应唯一余额记录，并通过数据库事务保障扣减原子性：
-- 初始化（确保每 apikey 仅一行）
INSERT INTO `users_credit` (`apikey`, `credit`, `description`, `create_date`, `update_date`)
VALUES ('abcdef', 1000.00, 'Initial balance', NOW(), NOW())
ON DUPLICATE KEY UPDATE `credit` = VALUES(`credit`);
-- 扣减逻辑（在应用中执行）
START TRANSACTION;
UPDATE `users_credit`
SET `credit` = `credit` - 1.50, `update_date` = NOW()
WHERE `apikey` = 'abcdef' AND `credit` >= 1.50; -- 条件前置校验
SELECT ROW_COUNT() AS `affected_rows`; -- 返回 1 表示扣减成功
COMMIT;✅ 优势：
- 消除
SUM()聚合开销；WHERE ... AND credit >= X实现“查+扣”一步完成，天然防止超扣；- 单行更新性能远高于多行扫描+聚合；
- 配合主键/唯一索引，彻底规避并发重复扣减（MySQL 行级锁自动生效）。
✅ 3. 强制 API 速率限制（防御性措施）
即使后端优化完成，仍需拦截恶意/缺陷客户端的无限重试。推荐分层限流：
-
Nginx 层（轻量级）：按 IP 或 API Key 限速
limit_req_zone $arg_apikey zone=api_limit:10m rate=5r/s; location /send_sms { limit_req zone=api_limit burst=10 nodelay; } - 应用层（精准控制）：使用 Redis 记录请求时间戳，支持按用户维度动态调整（如 OTP 用户允许 3 次/分钟，普通短信 60 次/小时）。
✅ 4. 补充健壮性实践
-
余额字段类型优化：将
DECIMAL(50,2)改为DECIMAL(12,2)（覆盖万亿级金额已足够，过大精度反而影响索引效率）； -
添加唯一约束：
ALTER TABLE users_credit ADD UNIQUE KEY uk_apikey (apikey);防止脏数据； -
异步日志归档：将
description等非核心字段移至独立日志表，主余额表保持极简； -
监控告警：对
users_credit表的慢查询、锁等待、连接数突增设置 Prometheus+AlertManager 告警。
通过以上组合策略，可将单次 SMS 请求的 DB 延迟从数百毫秒降至 5ms 内，同时杜绝超发、重复扣减与服务雪崩风险——真正满足 OTP 场景“毫秒级响应+金融级准确”的双重要求。
