MySQL可作为轻量级限流存储，核心是设计合理表结构与滑动窗口时间片，通过INSERT...ON DUPLICATE KEY UPDATE实现原子计数，并配合定时清理保障性能。
控制接口访问频率的核心是“记录+判断”，MySQL 可以作为轻量级限流数据存储，适合中小流量场景。关键不是强依赖 MySQL 性能，而是设计合理的表结构、索引和写入/查询逻辑，避免成为瓶颈。
限流维度与时间窗口设计
限流必须明确“对谁限、在多长时间内限多少次”。常见维度包括：
• 用户 ID（uid）
• IP 地址（client_ip）
• 接口路径（path）
• AppKey 或 Token（适用于开放平台）
时间窗口建议用“滑动窗口”的简化版——固定时间片（如 60 秒），配合 UNIX_TIMESTAMP 向下取整（如 FLOOR(UNIX_TIMESTAMP()/60)），生成唯一时间片标识（time_slot），便于分组统计和过期清理。
MySQL 表结构建议
一张精简的限流记录表即可，无需复杂关联：
CREATE TABLE api_rate_limit ( id BIGINT PRIMARY KEY AUTO_INCREMENT, scope VARCHAR(64) NOT NULL COMMENT '限流维度值，如 uid:123 或 ip:192.168.1.1', scope_type TINYINT NOT NULL COMMENT '1=uid, 2=ip, 3=path, 4=appkey', time_slot INT NOT NULL COMMENT '时间片，单位秒，如 FLOOR(UNIX_TIMESTAMP()/60)', count INT NOT NULL DEFAULT 1, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_scope_time (scope, scope_type, time_slot), INDEX idx_time_slot (time_slot) ) ENGINE=InnoDB COMMENT='接口访问频次记录';
说明：
• 联合唯一索引 (scope, scope_type, time_slot) 防止重复插入，支撑“存在则 UPDATE，不存在则 INSERT”逻辑
• time_slot 索引 支持定时任务清理过期数据（如保留最近 2 小时数据）
• 不存具体时间戳字段，用 time_slot 做整型比较，查询更快、更省空间
核心操作：原子计数与判断
每次请求需完成“读当前次数 → 判断是否超限 → 未超则+1写入”三步。推荐用 INSERT ... ON DUPLICATE KEY UPDATE 一条语句完成，避免竞态：
INSERT INTO api_rate_limit
(scope, scope_type, time_slot, count)
VALUES
('uid:123', 1, FLOOR(UNIX_TIMESTAMP()/60), 1)
ON DUPLICATE KEY UPDATE
count = count + 1;
<p>-- 再查一次当前 count 是否超限（例如每分钟最多 100 次）
SELECT count FROM api_rate_limit
WHERE scope = 'uid:123' AND scope_type = 1 AND time_slot = FLOOR(UNIX_TIMESTAMP()/60);</p>注意：
• 先 INSERT/UPDATE 再 SELECT 是安全的，因唯一索引保证同一 time_slot 下只有一条记录
• 若要求严格原子性（如不允许任何超限请求），可改用 SELECT ... FOR UPDATE + 事务，但会增加锁开销，一般非必要不启用
• 应用层需处理 MySQL 的 Duplicate entry 异常（即已存在记录），这是正常流程
清理与维护策略
不清理会导致数据无限增长，影响性能：
- 每日凌晨执行 DELETE FROM api_rate_limit WHERE time_slot < FLOOR(UNIX_TIMESTAMP()/60) - 120（保留最近 2 小时）
- 为避免单次 DELETE 太重，可按 time_slot 分批删除，或使用分区表（按 time_slot RANGE 分区）
- 定期（如每周）分析 top 访问 scope，辅助识别异常调用方
不复杂但容易忽略。MySQL 做限流不是最优解，但在已有数据库、QPS 不高（如
