嘿，这个Bingo中奖判定的问题挺接地气的，我来分享几个在实际项目里验证过的优化方案，帮你挑最适合的：

方案1：基于集合包含的直接查询（适合中小用户量+快速落地） #

这是最容易实现的方案，核心是利用数据库的集合包含能力来快速匹配：

• 数据库设计：给用户彩票表（比如user_bingo_cards）加一个card_numbers字段，用数组类型存储15个数字（比如PostgreSQL的integer[]，MySQL的JSON数组）
• 查询逻辑：每次抽取新数字后，把所有已抽数字拼成集合，执行查询：
  • PostgreSQL：SELECT user_id, card_id FROM user_bingo_cards WHERE card_numbers <@ ARRAY[1,3,5,...,30] AND is_winner = false;
  • MySQL：SELECT user_id, card_id FROM user_bingo_cards WHERE JSON_CONTAINS_ALL(card_numbers, JSON_ARRAY(1,3,5,...,30)) AND is_winner = false;
• 优化点：给card_numbers加GIN索引（PostgreSQL）或者函数索引（MySQL），能大幅提升集合匹配的速度
• 优缺点：实现简单，不需要额外的字段或逻辑，但用户量上万后，每次查询的开销会逐渐上升——毕竟要扫描所有未中奖用户的彩票。如果你的用户量级在几千以内，这个方案完全够用。

方案2：维护匹配计数（适合高并发+大用户量场景） #

这个方案把查询的开销转移到了每次抽数字的更新阶段，让中奖判定的查询速度达到极致：

• 数据库设计：在用户彩票表中新增matched_count（默认0，记录已匹配的数字数量）和is_winner（默认false，标记是否已中奖）两个字段
• 执行流程：
  1. 每次抽取数字n时，先更新所有包含n且未中奖的彩票：UPDATE user_bingo_cards SET matched_count = matched_count + 1 WHERE n = ANY(card_numbers) AND is_winner = false;
  2. 接着只需查询SELECT user_id, card_id FROM user_bingo_cards WHERE matched_count = 15 AND is_winner = false;，找到后立刻标记is_winner=true
• 优化点：给card_numbers加GIN索引（加速找到包含目标数字的彩票），给(is_winner, matched_count)加复合索引（让中奖查询直接命中索引）
• 优缺点：中奖查询速度极快（几乎是瞬间返回），但每次抽数字的更新操作可能成为瓶颈——如果某个数字被大量用户的彩票包含，更新的行数会很多。可以用分批次更新、异步队列处理等方式缓解这个问题，适合用户量几万以上的高并发场景。

方案3：位掩码运算（性能天花板，适合极致速度要求） #

利用位运算的CPU级速度优势，把数字匹配转化为二进制位的逻辑运算，性能拉满：

• 数据库设计：因为数字范围是1-90，我们可以用两个64位整数（mask_high和mask_low）或者数据库原生的BIT类型（比如PostgreSQL的bit(90)）来存储位掩码。每个数字对应一个位，比如数字1对应第0位，数字90对应第89位，用户彩票上的数字对应的位设为1。
• 查询逻辑：每次抽取数字后，生成已抽数字的位掩码drawn_mask，然后执行查询：SELECT user_id, card_id FROM user_bingo_cards WHERE (card_mask & drawn_mask) = card_mask AND is_winner = false;（这里的&是按位与运算，结果等于card_mask说明用户的所有数字都在已抽集合里）
• 优化点：给card_mask加GIN索引或者哈希索引，进一步加速匹配
• 优缺点：性能是三个方案里最高的，位运算本身是极快的操作，但实现稍微复杂一点，需要处理位掩码的生成和转换。如果你的用户量达到几十万甚至上百万，这个方案能帮你扛住压力。

总结怎么选 #

• 中小用户量（几千人）：选方案1，快速落地，成本最低
• 大用户量+高并发：选方案2，把查询开销转移到更新，中奖查询秒出
• 极致性能要求：选方案3，位运算的速度优势无可替代

内容的提问来源于stack exchange，提问作者DonJoe