网络数据库实训报告

实训第三天，网络我把MySQL的数据root密码忘了。准确地说，库实是训报我在Navicat里手滑点了一下“修改密码”，然后没记住新密码。网络那一刻，数据整个实训机房的库实机器都连不上本地数据库，我只能重装MySQL服务。训报这件事让我意识到一个很实在的网络问题：平时在课本上看到的“数据库安全策略”，真到了自己手上，数据最先出问题的库实往往是最基础的环节。

从建库建表开始

这次实训用的训报是MySQL 8.0，配合Navicat做可视化管理。网络第一个任务是数据根据给定的ER图建一个简易电商数据库。ER图上有用户表、库实商品表、订单表、订单详情表，四个实体之间有两对多的关系。我一开始觉得这还不简单，照着画就行。结果建到订单详情表的时候卡住了——主键到底用自增ID还是用（订单ID，商品ID）的复合主键？

我选了复合主键。理由很直接：一个订单里同一个商品不应该出现两次，复合主键天然能约束这一点。后来老师检查时说这个选择没问题，但提醒我如果以后要加“同一商品分批次发货”的功能，复合主键就得改。这种细节在课本上通常不会展开讲，只有自己建过表才知道。

查询练习里踩的坑

建完表就该插数据了。我往用户表里塞了200条随机记录，用Python脚本生成的。本来想插1000条，但Navicat执行批量插入的时候卡了将近两分钟，我就放弃了。200条够用，反正只是练查询。

第一个查询任务是“找出下单金额最高的前10个用户”。我写了个JOIN加GROUP BY，跑出来结果看着挺正常。但老师让我核对一下——有个用户只下了一单，金额刚好排在第10位，可实际上他那一单是退货状态。我的查询没过滤订单状态。加上WHERE status != 'refunded'之后，第10名换人了。

这个错误不复杂，但很典型。写查询的时候容易只盯着“能不能跑出结果”，忽略了业务逻辑里的过滤条件。后来我养成了一个习惯：每写完一个查询，先看WHERE子句里有没有漏掉状态字段。

索引和性能的直观感受

实训里有一个环节是给订单表的user_id字段加索引，然后对比加索引前后的查询耗时。数据量只有200条的时候，加不加索引几乎没区别，查询时间都是0.001秒左右。老师让我们把数据量扩到5万条再试。

我用脚本生成了5万条订单记录，插入花了大概40秒。然后跑同一个查询：SELECT * FROM orders WHERE user_id = 12345。没加索引的时候，耗时0.32秒；加了索引之后，0.002秒。差距很明显。不过我也注意到，加索引之后插入新订单的速度变慢了——从平均每条0.8毫秒变成了1.1毫秒。索引不是免费的，这个代价在课本上通常只有一句话，但实际跑一下数据就很有体感。

备份与恢复

实训最后一天做备份恢复练习。用mysqldump导出整个数据库，然后删掉一张表，再从备份文件里恢复。导出命令本身不复杂，但我第一次恢复的时候报错了，原因是备份文件里的建表语句带了DROP TABLE IF EXISTS，而我的目标库里有一张同名但结构不同的表。恢复之后数据对不上，查了半天才发现是这个问题。

后来我改成先手动删表再恢复，就正常了。这件事让我理解了一个道理：备份文件不是万能的，恢复之前得先确认目标环境的状态。生产环境里做恢复操作，可能还得考虑锁表、主从同步这些更麻烦的事。实训里只是单机MySQL，已经够我折腾的了。

一些零散的想法

两周实训下来，最大的收获不是学会了写多复杂的SQL，而是对“数据库操作是有后果的”这件事有了具体感知。删一条记录、加一个索引、改一个字段类型，这些操作在Navicat里就是点几下鼠标，但背后影响的是数据完整性、查询性能和恢复难度。

另外，我发现自己写SQL的时候越来越依赖可视化工具了。Navicat的查询构建器确实方便，但有一次它生成的SQL嵌套了三层子查询，我看了半天才理清楚逻辑。后来我还是老老实实手写。工具是辅助，SQL本身得自己能写明白。

实训结束了，那个忘记密码的事最后还是靠重装解决的。现在我把密码记在了密码管理器里，再也没丢过。

(责任编辑：百科)