数据库与后端工具

这个类别解决什么问题

让用户数据、业务状态和生成记录能被可靠地保存和查询，并处理权限与并发。

什么时候需要

当产品需要记住任何跨会话的东西时：账号、订单、历史记录、用量统计。纯展示型产品可以推迟。

选择时看哪些指标

这些是评估这类服务时通用的判断维度，不针对任何具体厂商。

是否托管（备份、升级、故障恢复由谁负责）
区域位置与接口延迟
计费方式与空闲成本
数据导出与迁移路径
附带的鉴权、存储等能力是否需要

中国开发者特别需要考虑什么

数据库区域通常要和后端部署区域一致，否则每次查询都会叠加跨区域延迟。

这一层的成本结构

数据库成本分四块。存储按容量计，增长缓慢也容易预测。计算按实例档位或计算时长计，即使没有流量也在跑，这通常是账单的主要部分。网络出站按传输量计，跨区域读取和大量导出时容易被忽略。备份与日志保留按时间与容量计，留得越久越贵。托管服务常把前两项打包成档位价，闲置时照样收费。成本真正跳起来的往往不是数据量，而是连接数：短连接一多，计费维度就会从容量转向次数。

常见误区

把数据库和接口服务放在不同区域。每次查询都多一次跨区往返，接口的 p95 延迟被直接拉高。做法是让两者落在同一区域，跨区只放图片、脚本这类静态资源。
生产库直接用管理员连接串，并且允许从公网访问。连接串一旦泄漏，攻击者可以读走也可以删掉整个库。做法是给应用单独建最小权限账号，只在必要时开放入口，并定期轮换密码。
没做备份就改表结构。迁移脚本写错字段类型，写入失败时才发现没有可回退的快照。做法是每次结构变更前手动触发一次备份，把变更语句和回退语句记在同一条记录里。

从零开始的上手顺序

先把要存的东西列成三组：用户与账号、业务对象（订单或任务）、事件与用量记录，并标出后面要按哪些字段查询，索引需求在这一步就定下来了。
在离后端服务最近的区域创建实例，创建时把时区和字符集定好。这两个设置后期改动涉及全量数据，代价很高。
建两个账号：应用使用的读写账号、迁移与管理用的管理账号。连接串只放环境变量，不写进仓库，也不贴进聊天记录。
打开自动备份，并手动做一次恢复演练，把恢复耗时记下来。没有验证过恢复的备份，在真出事的时候不能算数。

在不同业务模式中的作用

saas 账号、订阅状态与业务数据

ai-saas 用户数据、生成记录与用量计量

app 账号与数据同步

api 调用计量与配额

digital-product 订单与授权记录

ecommerce 商品、订单与库存

常见问题

我该用关系型数据库还是文档数据库？

看数据之间有没有关系。用户、订阅、订单之间要按条件联查和统计，关系库更省事，事务与字段约束还能替你挡住一批应用层的 bug。字段结构还在剧烈变化、且基本只按主键读取时，文档库写起来更快。多数出海产品的第一批数据属于前者。

托管数据库和自己在服务器上装，差在哪？

差在谁负责备份、小版本升级和故障恢复。自装的月成本更低，但磁盘写满、慢查询、主从切换这些事都要你自己处理，而它们往往发生在你最不希望被打断的时候。单人开发者起步用托管，等有明确的成本或合规理由再自建。

免费档的数据库能直接上线用吗？

验证阶段可以，但要先确认三件事：空闲后是否暂停、暂停后首次访问的延迟有多大；存储与连接数的上限；备份保留多少天。这三项符合预期再上线，否则先把项目升到带备份的档位。具体限制以官方文档为准。

数据量不大，为什么数据库账单还在涨？

通常是两个原因：计算实例一直在运行，以及对外读取产生的出站流量。数据只有几百兆，也会持续产生实例费用。去用量明细里看计算时长和出站流量这两项，把已经不用的预览环境实例关掉，账单通常会立刻降下来。

数据库与后端