数据库选错了网站就可能跑不顺，类型不同影响设计和性能怎么忽视

（根据微信公众号“技术老男孩”文章《数据库选型失败，整个项目都可能推倒重来》的核心观点整理）

我们常常把数据库比作一个网站的“心脏”或者“地基”，这个比喻一点也不夸张，很多人，尤其是刚开始做项目的朋友，容易犯一个错误：觉得数据库都差不多，无非就是存东西和取东西，先随便选一个用着，等以后出了问题再说，这种想法其实非常危险，因为一旦选错了数据库，就像给一栋准备盖成摩天大楼的建筑打了一个只能承受平房重量的地基，等到楼盖到一半才发现问题，那时候想要更换地基，代价几乎是毁灭性的,很可能整个项目都要推倒重来。

为什么数据库的类型影响会这么大呢？这主要是因为不同类型的数据库，它们的设计思想、擅长处理的场景以及性能表现是天差地别的，如果你忽视了这些根本区别，强行用一种数据库去应对它不擅长的场景，那网站“跑不顺”就是必然的结果。

举个例子，我们最常听到的可能是关系型数据库和非关系型数据库的区别，关系型数据库，比如经典的MySQL、PostgreSQL，它们就像是一个高度组织化、纪律严明的图书馆，所有的数据都必须按照预先定义好的“表格”来存放，每一行数据都有固定的格式（字段），并且表格与表格之间可以通过“关系”（比如学号关联学生表和成绩表）紧密地连接在一起，这种结构的最大优点是保证数据的一致性和完整性，当你需要进行复杂的、涉及多个表格关联的查询时（查询每个班级的平均分并列出班主任姓名”），它会非常强大和准确，如果你的业务核心是需要大量复杂交易、需要严格保证数据准确无误的场景，比如银行转账、电商订单系统,关系型数据库通常是更稳妥的选择。

关系型数据库的这种“严谨”也带来了缺点，当你的数据量变得极其庞大，或者你需要处理的数据结构非常灵活、经常变化时，它就会显得力不从心，想象一下，如果图书馆每本新书的题材和章节都完全不同，管理员为了给每本新书设计一个新的归档规则，效率会非常低，这时候，非关系型数据库（NoSQL）的优势就体现出来了。

非关系型数据库有很多种，比如文档型数据库（如MongoDB）、键值对数据库（如Redis）、列存储数据库等，它们就像是一个个不同用途的储物仓库，文档型数据库可以存储像JSON那样结构灵活的数据，今天存一篇文章（包含标题、内容、作者），明天存一个用户信息（包含基本信息、兴趣爱好列表、动态变化的标签），它都能轻松应对，不需要像关系型数据库那样必须先修改表结构，这种灵活性非常适合内容管理系统、用户画像等场景，而键值对数据库，比如Redis，读写速度极快，常被用作缓存，把一些频繁读取但又不太变化的数据（如网站首页的热门文章列表、用户会话信息）放在内存里，极大地减轻主数据库的压力,提升网站访问速度。

如果你不小心选错了类型，后果会很直接，你用一个擅长处理复杂关系的MySQL去存储海量的、结构千变万化的用户行为日志，很快你就会发现写入速度跟不上，查询起来也异常缓慢，数据库服务器不堪重负，反过来，如果你用一个灵活的MongoDB去构建一个财务系统，需要大量精确的跨表事务操作，你可能会发现很难保证数据百分之百的准确和同步,这会引发严重的业务问题。

除了核心的类型选择，一些细节特性也同样不能忽视。（此处参考知乎专栏“架构师之路”的《数据库选型，不得不考虑的十大因素》）数据库对“读”和“写”操作的侧重不同，有些数据库在写入大量数据时表现卓越，适合做数据分析和日志记录；而有些数据库则优化了读取速度，适合读多写少的门户网站，再比如，数据库的扩展性，当你的用户量暴增，一台服务器撑不住时，数据库是否容易“横向扩展”（即通过增加更多普通服务器来分担压力）就至关重要，像MySQL的横向扩展就比较复杂,而很多NoSQL数据库天生就为集群分布而设计。

所以说，在网站或者应用开发的初期，花足够的时间去进行数据库选型，是至关重要的一步，这不仅仅是技术决策，更是业务决策，你需要仔细思考：我的业务数据有什么特点？是结构稳定还是灵活多变？主要的操作是读是写？对数据一致性要求有多高？未来预期的用户量和数据增长会有多快？只有把这些想清楚了，才能选择一个最适合的“地基”，让你的网站不仅能顺畅地跑起来，还能在未来业务壮大时，拥有平稳升级和扩展的能力，避免中途换库的灾难，忽视数据库类型的影响,无异于在项目启动之初就埋下了一颗定时炸弹。