核心是用INSERT INTO ... SELECT配合循环生成唯一码，而非逐条INSERT；必须加START TRANSACTION与异常ROLLBACK， coupon_code字段建唯一索引防重，高并发下用UUID_SHORT()或时间戳+随机数替代RAND()，发券前用LEFT JOIN判重优于NOT EXISTS，大用户量需分批处理并避免深分页。
存储过程里怎么批量插入优惠券记录
核心是用 INSERT INTO ... SELECT 配合循环生成唯一码，而不是逐条 INSERT。逐条执行在万级数据下会明显变慢，且容易触发锁等待。
常见错误是直接写 WHILE + INSERT，没加事务控制，中途失败会导致部分发券、状态不一致。
- 用
BEGIN ... END包裹整个逻辑，开头加START TRANSACTION，成功后COMMIT，异常时ROLLBACK - 优惠券码建议用
UUID_SHORT()或拼接时间戳+随机数，避免RAND()重复（尤其并发调用时） - 插入前先查
coupon_code是否已存在，但高并发下仍可能冲突，所以表必须在coupon_code字段建唯一索引 - 示例片段：
INSERT INTO coupon (user_id, coupon_code, status, created_at) SELECT u.id, CONCAT('C', UNIX_TIMESTAMP(), LPAD(FLOOR(RAND()*10000),4,'0')), 'unused', NOW() FROM user u WHERE u.level >= 3 LIMIT 1000;
怎么安全地把优惠券发给指定用户群
不能靠应用层传入大数组用户ID——MySQL 存储过程不支持数组参数，传字符串再 SUBSTRING_INDEX 拆分既低效又易出错。更稳的方式是让调用方先写目标用户到临时表，或用已有标签字段筛选。
典型场景：给「近30天下单≥2次且未领过该券」的用户发券。这时要小心子查询性能和 NULL 处理。
- 优先走索引字段过滤，比如
last_order_time > DATE_SUB(NOW(), INTERVAL 30 DAY)，别写DATE(last_order_time) > ... - 用
LEFT JOIN coupon c ON c.user_id = u.id AND c.template_id = xxx判断是否已领，比NOT EXISTS在大数据量下通常更快 - 如果用户量极大（如百万级），考虑分页处理，每次处理 5000 行，用
OFFSET+LIMIT配合主键范围扫描，避免深分页
存储过程中怎么防止并发重复发券
多个服务实例同时调用同一存储过程，最危险的不是 SQL 冲突，而是「判断-插入」之间的竞态窗口。即使加了唯一索引，报错后也要明确返回给调用方，不能静默吞掉。
- 在存储过程中捕获
SQLSTATE '23000'（唯一键冲突）和SQLSTATE '45000'（自定义异常），用DECLARE EXIT HANDLER统一处理 - 不要依赖
SELECT COUNT(*)判断发券数是否达标——它不阻塞其他写入，得用SELECT ... FOR UPDATE锁住相关行（比如锁住优惠券模板的配置行） - 发券完成后立即更新模板的
issued_count字段，并加WHERE issued_count + N 做原子校验
为什么用存储过程而不是应用层批量处理
不是因为“更高级”，而是当发券逻辑强耦合数据库状态（比如库存扣减、用户等级实时计算、多表一致性校验）时，把逻辑放在数据库侧能减少网络往返和分布式事务开销。
但代价是调试难、版本难管理、无法用应用层监控埋点。一旦存储过程里调用了外部 API 或写日志文件，就彻底失去可移植性。
- 纯数据操作（查用户、插券、更新计数）适合放存储过程；涉及短信通知、风控拦截、积分联动等，必须交还应用层
- MySQL 8.0+ 支持
JSON_TABLE，可以接收 JSON 格式的参数，但别用来传几百个用户ID——解析开销大，不如临时表 - 上线前务必在从库上
EXPLAIN关键查询，确认没走全表扫描；发券量超过 10 万时，留意max_allowed_packet和innodb_lock_wait_timeout设置
真正麻烦的从来不是写完存储过程，而是后续修改：加一个字段判断就得改三处，还要同步更新所有调用方的参数顺序。上线前多花十分钟画张数据流图，比事后查死锁快得多。
