存储过程不适合高频计数器，因其调用开销大、易引发死锁、锁粒度粗且无法利用原子update优势；应直接使用主键上的update ... set count = count + 1，确保原子性、低延迟与小锁范围。
MySQL 8.0 中用存储过程做高频率计数器，不是不行，但容易踩坑——UPDATE ... SET count = count + 1 加上行锁就足够了，存储过程反而引入额外开销和死锁风险。
为什么存储过程不适合高频计数器场景
存储过程在每次调用时需解析、权限校验、上下文切换，对每秒数千次的计数请求来说，延迟明显高于直接 SQL。更关键的是，如果过程里用了 SELECT ... FOR UPDATE 再 UPDATE，会延长锁持有时间；而直接 UPDATE 是原子的，锁粒度更小、释放更快。
- 存储过程无法被查询缓存（MySQL 8.0 已移除查询缓存，但类似机制如 prepared statement cache 对简单语句更友好）
- 事务内调用存储过程可能隐式开启事务，导致锁等待累积
- 错误处理逻辑（如
DECLARE CONTINUE HANDLER）在高并发下增加分支判断成本
真正该用的写法：原子 UPDATE + 合理建表
高频计数器核心是“无条件原子自增”，不需要读再写。建表时确保主键明确，避免全表扫描：
CREATE TABLE page_views ( page_id VARCHAR(64) PRIMARY KEY, count BIGINT UNSIGNED NOT NULL DEFAULT 0 ) ENGINE=InnoDB;
更新语句必须走主键索引：
- ✅ 正确：
UPDATE page_views SET count = count + 1 WHERE page_id = 'home' - ❌ 危险：
UPDATE page_views SET count = count + 1 WHERE url LIKE '%home%'（触发全表扫描+锁表） - ✅ 可选增强：加
INSERT ... ON DUPLICATE KEY UPDATE处理首次插入
当真要封装逻辑时，如何最小化风险
如果业务强制要求用存储过程（例如统一审计或权限控制），务必满足三点：只做单行主键更新、不查不判、不带事务控制符：
DELIMITER $$ CREATE PROCEDURE inc_counter(IN p_page_id VARCHAR(64)) BEGIN UPDATE page_views SET count = count + 1 WHERE page_id = p_page_id; END$$ DELIMITER ;
- 不要在过程里写
START TRANSACTION或COMMIT，交给调用方控制 - 参数必须声明为
IN，避免INOUT引入变量拷贝开销 - 禁止出现
SELECT ... INTO或IF EXISTS判断——这些都会让锁从“记录锁”升级为“间隙锁”甚至“临键锁”
容易被忽略的底层细节
即使写对了 UPDATE，InnoDB 的 count 字段类型和默认值也影响性能：
-
BIGINT UNSIGNED比INT更安全，避免溢出后变负数（MySQL 不报错，但业务逻辑崩） - 必须设
NOT NULL DEFAULT 0，否则UPDATE遇到NULL会变成NULL + 1 → NULL，且WHERE条件匹配不到新记录 - 如果用
INSERT ... ON DUPLICATE KEY UPDATE，注意ON DUPLICATE KEY UPDATE子句不能引用未在INSERT中显式列出的列（比如想用VALUES(count)就会报错）
