二维码数据库怎么建立

别把二维码想得太玄乎。维码它本质上就是数据一张图片，里面存了一串字符。库建你扫一下，维码手机就把这串字符读出来，数据然后去干该干的库建事——打开网页、连WiFi、维码付钱。数据所以“二维码数据库”这个说法，库建其实不太准确。维码你不是数据在存二维码，你是库建在存那串字符，二维码只是维码它的“门牌号”或“钥匙”。

真正的数据问题变成：你手头有几千几万个二维码要管理，怎么让它们不乱？库建比如你给一家连锁奶茶店做了促销码，每个杯子印一个，顾客扫了能领优惠券。这些码得对应到具体门店、具体批次、具体有效期。这时候，你就需要一个后台，把“码”和“数据”绑在一起。

最土的办法，用Excel就能干。一列放码的编号（比如MILK20240601-001），一列放门店名，一列放生成时间，一列放状态（未扫/已扫/过期）。再把二维码图片文件名改成编号，扔进同一个文件夹。扫码时，手机跳转到你的服务器地址，服务器查一下这个编号在Excel里对应的门店，返回结果。够用，但麻烦——你得手动更新，而且并发一高，Excel直接卡死。

稍微像样点的做法，是建一张数据库表。用MySQL或PostgreSQL，字段大概这样：id（主键）、code（唯一索引，就是那串字符）、batch（批次号）、created_at、scanned_at、status。关键点是code必须唯一，否则两个码撞了，顾客扫出来信息就错乱。插入数据时，你可以用程序批量生成随机字符串，比如UUID或短码（Snowflake算法也行），然后循环INSERT。别用自增id当code，太容易被猜出来，别人改个数字就能扫别人的码。

生成二维码本身很简单，Python的qrcode库或者Java的ZXing，几行代码的事。但你要注意，二维码内容里存的URL，得带一个参数，比如https://yourdomain.com/scan?code=ABC123。这样扫码后，服务器就知道是哪个码被扫了。然后你在服务器端写个接口，接收这个code，查数据库，更新scanned_at，再返回业务数据。

有个坑我踩过：二维码图片不能存数据库里，除非你数据量小到无所谓。图片存服务器磁盘或对象存储（阿里云OSS、S3），数据库只存路径。否则数据库文件膨胀到几个GB，查询慢得你想摔键盘。

再提一个细节，二维码有容错级别，L、M、Q、H。别全用H，虽然不容易扫坏，但图案更密，打印在杯子上如果油墨晕开，反而更容易扫不出。我用M居多，打印在塑料或纸上，抗污能力够了。

最后说下实时性。如果码量不大（每天几百个），同步查数据库没问题。但如果搞活动，一分钟几千人扫，你的数据库会扛不住。这时候得加缓存，比如Redis，把热门码的状态先放内存里，扫描时先查缓存，没命中再落库。或者直接用消息队列，扫码请求先丢进Kafka，后台慢慢更新，用户那边显示“处理中”就行。

说白了，二维码数据库的核心不是二维码本身，而是你给每个码赋予的“身份信息”。码只是入口，数据才是价值。把入口和数据的关系理清，剩下的都是工程问题。