面试官问"选SQL还是NoSQL"：我答错后亏了3个月

87%的后端开发者在技术选型时踩过同样的坑——不是选错数据库，而是问错了问题。

Serxan Hamzayev在Medium分享了他的真实经历：第一次系统设计面试，面试官抛出"SQL还是NoSQL"，他当场僵住，试图猜测对方想要的答案。这个场景像极了相亲时被问"喜欢什么类型"——正确答案不存在，只有合不合适。

更惨的是他的第一个后端项目。跟风选了当时流行的数据库，没看业务需求，结果查询慢得像拨号上网，数据结构乱成 spaghetti code（意大利面条式代码）。

技术选型的悲剧往往从"找标准答案"开始。

Hamzayev现在用4个问题替代那个伪命题。这些问题来自真实的生产事故，不是教科书。

问题一：你的数据长什么样？

他现在的第一检查项不是性能，不是扩展性，是数据形态。

数据结构固定、字段稳定？SQL（关系型数据库）通常更顺手。数据经常变、大量可选字段？NoSQL（非关系型数据库）可能减少痛苦。 Hamzayev举过一个用户画像的例子：SQL风格需要预定义每一列，改结构要迁移；NoSQL文档型可以直接塞进新字段，老数据不用动。

但这里有个陷阱。很多人把"灵活"当优点，却忘了灵活意味着约束少，约束少意味着更容易写出脏数据。 Hamzayev没说的后半句是：NoSQL的灵活性是双刃剑，团队纪律差会变成数据沼泽。

问题二：你需要多强的数据关系？

多表关联是SQL的舒适区。JOIN（关联查询）写起来顺手，事务保证数据一致。

但如果你的数据关系像社交网络——用户关注用户，关注又分组，分组又有权限——关系型数据库的JOIN层级深了会性能爆炸。 Hamzayev建议：关系简单用SQL，关系复杂且查询路径多变，图数据库或文档型NoSQL可能更合适。

这里他埋了一个产品思维：别只看现在，看查询模式会不会变。今天查用户订单，明天可能要查"买了A又买B的用户"，关系型数据库的表结构改动成本陡增。

问题三：读写比例是多少？

读多写少和读写均衡是完全不同的战场。

Hamzayev的经验是：读密集型应用，SQL配合缓存层（如Redis）往往够用；写密集型或需要水平扩展，某些NoSQL（如Cassandra）的设计更友好。 但他强调了一个反直觉的点——别预设自己要"支撑百万并发"。

多数项目死在过早优化。他见过团队为"未来可能的数据量"选了分布式数据库，结果运维复杂度压垮了三个人小团队。 数据说话：先跑起来，监控真实的读写比例，再决定要不要换。

问题四：团队熟悉什么？

这是最被低估的因素，也是Hamzayev付过学费的。

再"正确"的技术，团队不会用就是债务。他第一个项目的教训：选了 trendy（时髦的）数据库，结果调试慢查询时社区资料少，踩坑全靠硬啃源码。 现在他的原则是：在"够用"和"熟悉"之间找交集，而不是追新。

这4个问题没有标准答案组合。Hamzayev的原话是："我根据答案调整选择，而不是先选边站队。"

他的文章在Medium需要会员才能看完全文，但核心逻辑已经清晰：数据库选型是需求翻译，不是信仰站队。 那个面试问题的真正陷阱，在于它暗示存在唯一正确答案——而工程决策从来没有。

Hamzayev的LinkedIn主页显示他专注后端技术分享，这篇文章的评论区有个细节：有读者问"那NewSQL呢"，他没回复。 这个沉默本身可能是答案——别在概念迷宫里打转，回到那4个问题。

你的下一个项目，准备先回答哪一个问题？