选型前必须回答的三个业务问题
很多团队一上来就对比性能参数，却忽略了最根本的业务适配性。在接触任何国产数据库之前，先回答：数据模型是关系型为主还是文档/时序型？事务一致性要求是强一致还是最终一致？读写比例和峰值QPS预估是多少？这三个答案直接决定你该看分布式架构还是集中式架构，是选MySQL兼容派还是PostgreSQL兼容派。
实战教训：某金融客户强依赖存储过程，却选了分布式数据库，结果存储过程不支持，重写业务逻辑耗时3个月。
架构审查：分布式不等于无限扩展
国产分布式数据库普遍采用Shared-Nothing架构，但要注意：
- 分布式事务（如两阶段提交）在高并发下性能衰减明显，需评估业务是否真有跨节点事务。
- 全局自增主键、唯一索引在分布式下实现成本高，部分产品会退化为串行化，影响写入吞吐。
- 分区键设计一旦不合理，数据倾斜会导致单节点成为瓶颈，需提前做数据分布模拟。
生态成熟度：别让运维成为无人区
数据库不是装完就结束，后续的备份恢复、监控告警、数据迁移、异构同步工具链至关重要。检查清单：
- 官方是否提供完善的备份恢复工具，支持增量备份和PITR（时间点恢复）？
- 是否有兼容Prometheus的监控插件，还是需要自研采集器？
- 数据迁移工具是否支持从Oracle/MySQL在线平滑迁移，还是只能离线导入？
- 社区活跃度如何？遇到问题能否在24小时内搜到解决方案？
性能压测的三大陷阱
压测结果好看不代表生产可用。常见陷阱：
- 只用单表读写压测，忽略多表JOIN和复杂查询下的优化器表现。
- 忽略并发锁竞争，高并发下行锁升级为表锁导致吞吐骤降。
- 不测故障切换场景，主备切换后性能是否劣化、数据是否丢失未经验证。
避坑落地建议
最后给三条实操建议：第一，要求厂商提供POC（概念验证）环境，至少跑两周真实业务负载；第二，在合同中明确性能不达标的退出机制，避免被绑定；第三，组建内部技术小组，提前培养1-2名熟悉该数据库的DBA，不要完全依赖原厂。选型是技术决策，更是风险管理。