收银小程序在苏州工业园区的小商户里铺开速度极快，但很多团队把精力全砸在功能堆叠上，忽略了最要命的底层——数据库。我们渔师傅软件开发工作室接过不少“半路翻车”的项目，客户反馈收银卡顿、账单对不上、高峰期扫码支付转圈，根源往往不是代码写得烂，而是数据选型从一开始就错了。

选型不是选“最火”，而是选“最合适”

不少定制软件需求方开口就要MySQL，觉得免费又通用。可收银场景是典型的高并发短事务，一天几万笔流水，每笔还要关联商品、库存、会员积分。这时候MySQL的锁机制和行竞争会让写入延迟飙到200ms以上，顾客等不起。我们最近一个园区餐饮客户，高峰期每秒并发写入约40笔，改用PostgreSQL搭配UNLOGGED TABLE做临时流水，写入耗时直接压到3ms，差距肉眼可见。

如果业务量再往上走，比如连锁便利店要跨店汇总，就得考虑TiDB这类分布式方案。但注意，分布式不是银弹，事务一致性开销在收银场景里反而拖后腿。我们一般建议：单店日流水低于2万笔，PostgreSQL单机足够；超过这个量，再按店铺维度分库，别一上来就上重武器。

性能优化：索引、缓存与写入路径

数据库选完，真正的仗在优化。收银小程序最怕的是慢查询拖垮整个收银流程。我们给一个烘焙连锁做系统开发时，发现商品表查询经常扫全表，原因是索引建错了——把索引建在“商品名称”上，而实际查询条件全是“条码+门店ID”。把复合索引调整为(branch_id, barcode)，查询耗时从800ms降到12ms，这就是索引设计的价值。

缓存层也至关重要。但别盲用Redis，收银数据强一致要求高，缓存只适合放商品目录、促销规则这类低频变更数据。我们用Redis存门店配置，用本地内存缓存热商品信息，命中率做到92%以上，数据库读压力直接减半。写入路径上，我们强制走“先写本地队列，再异步批量落库”的模式，既保证不丢单，又避免频繁fsync拖慢响应。

另外，SQL语句别写花活。收银里最怕SELECT *和嵌套子查询，我们代码规范里直接禁止，改成分页查+JOIN拆分，每一条查询都走EXPLAIN看执行计划。

• 索引策略：每个查询模式只保留一个最优复合索引，冗余索引一律删
• 连接池：HikariCP配最大20连接，超过就排队，绝不放无限连接
• 归档策略：三个月前的流水自动迁移到历史库，保持热表体积在1GB以内

实践建议：从运维视角反推设计

我们程序运维团队有个铁律——数据库设计必须给“未来备份”留路。收银数据是商户的命根子，每天凌晨全量备份，每半小时增量binlog同步，这个不能省。而且备份恢复演练每月做一次，真出事时能15分钟内拉起整套环境。还有一点容易被忽略：数据库账号权限最小化，收银小程序只用写权限账号，查询报表走另一个只读账号，防止SQL注入拖库。

技术定制上，我们还会给商户提供“降级预案”。比如断网时，收银端自动切到本地SQLite暂存，网络恢复后批量同步到中心库。这种设计看着简单，但真正实现好，需要把冲突合并逻辑写清楚——按时间戳+流水号做唯一键，基本能避免重复入账。

总结来看，收银小程序的数据库选型与优化，本质是在一致性、可用性和性能之间找平衡。没有万能方案，只有针对业务体量的精准匹配。苏州工业园区渔师傅软件开发工作室这几年深耕这一行，最大的体会是：别迷信技术时髦，把基础的数据路径打磨扎实，比什么都强。

如果你也在做软件开发或小程序开发，卡在数据库性能上，不妨从索引和写入路径先查起。很多时候，问题不在数据库本身，而在你如何用它。技术定制不是堆功能，是让每一个查询都跑在刀刃上。我们愿意多聊几句实操细节，毕竟这行经验就是靠一个个坑填出来的。