我第一次给小项目接上云数据库

上学期我和同学做了一个很小的课程项目：一个可以记录读书清单的网页。书名、作者、读到第几页、想写的一句话感想，这些数据一开始都存在一个 JSON 文件里。文件小的时候一切都好，改起来也直观。可是数据一多，问题就全来了：两个人同时改，保存时互相覆盖；想找“上周读完的书”，只能把整个文件翻一遍；有一次重新部署，我把旧文件覆盖了，十几条记录说没就没。那一刻我才明白，文件能存东西，但它不是为“经常改、经常查”而生的。

于是我开始学数据库。说实话，一开始我对数据库的印象就是一堆黑乎乎的命令和看不懂的报错。但真正上手之后才发现，它的核心理念其实很像表格，只不过更讲规矩。

一张表，你可以理解成一张更严格的 Excel 表。每一列叫一个字段，比如书名、作者、进度；每一行叫一条记录，就是一本书的信息。每一行还要有一个不会重复的编号，叫主键，就像每个人的学号，用来唯一区分这一条记录。想查得快，还可以给经常用来搜索的字段加索引，作用有点像书的目录，不用从头翻到尾。

搞懂这个比喻之后，剩下的选择就简单多了：数据到底放在哪里？

我一开始想过，直接在自己的云服务器上装一个 MySQL，自己管。但很快我就打了退堂鼓：装完还要管备份、管升级、管端口和权限，万一哪天服务器出问题，数据怎么办？我只是想做一个课程小项目，不想先变成半个运维。所以我最后选了华为云的云数据库 RDS，选的是我最熟悉的 MySQL。云数据库的意思其实很简单：数据库还是那个数据库，只不过安装、备份、监控这些脏活累活由云厂商帮你做了，你只管往里面存数据、查数据。

在控制台上建实例的过程，比我想象中顺。选离我的云服务器比较近的区域，最好和服务器在同一个虚拟私有云里，这样它们之间走内网通信，又快又不用把数据库暴露到公网上。规格我选了最小的一档，因为课程项目的数据量真的不大，没必要一上来就选大的。账单方式我选了按需计费，用多少算多少，测试完不用的实例记得及时处理，别让它在后台默默花钱。

建好之后，有几件事我是一开始就逼自己做对的。第一，字符集选 utf8mb4。别看名字长，它就是能正常存中文和表情符号的那种，选错了，以后中文变问号、表情存不进去，改起来特别麻烦。第二，账号别图省事全用 root。root 是管理员账号，权限太大，万一代码里的账号信息泄露，整个库都危险。我给项目单独建了一个普通账号，只给它读写这一张表的权限。第三，密码不要写进代码里，放到环境变量里。代码以后可能要给同学看、要传到仓库里，密码跟着代码走，等于把家门钥匙贴在了门上。

连上数据库之后，我先在测试表里练了几条最基本的语句：插入一条记录、按条件查出来、改一个字段、删一条不要的数据。别小看这四步，我的小项目九成的数据操作就是它们的组合。等测试表练熟了，我才把真正的读书清单导进去，然后改了网页的代码：以前读 JSON 文件的地方，改成去数据库里查；以前直接改文件的地方，改成往数据库里写。改完第一次跑通，页面上出现从数据库里查出来的书名时，那种感觉比功能本身跑通还要踏实，因为数据终于有了一个正经的家。

当然，我也踩过坑，而且都是新手特别容易踩的那种。印象最深的一次，是我写了一条更新语句，忘了加条件，结果差点把所有书的进度都改成同一个数字。幸好我是在测试表里试的。从那以后我养成了一个习惯：凡是改数据、删数据的语句，先在测试数据上跑一遍，确认只影响到想改的那几行，再动真数据。而且云数据库自带的自动备份也让我安心不少，就算手滑了，也还有得补救。

还有一个坑是安全组。数据库默认不能随便从外网访问，这是好事，不是麻烦。我一开始还纳闷为什么连不上，后来才明白：要先在安全组里放行自己云服务器的内网地址，而不是图方便把端口对所有人打开。数据库里装的是实实在在的数据，方便和安全之间，安全要排在前面。

换成云数据库之后，我的小项目其实没有变复杂，反而变简单了。以前最怕的两件事，现在都不怕了：一是重新部署不会再把数据弄丢，因为代码和数据分开了，代码随便换，数据还在库里；二是查数据不用再把整个文件读出来，翻页、按时间排序、按关键词搜索，都是一条语句的事。同学想加一个“只看已读完的书”的筛选，我也不用再重写一堆文件处理逻辑了。