数据库原理及开发应用：实验与课程设计指导 上节课刚讲了如何把数据存进去，想着今天直接讲如何从数据库中捞出来，顺便看看能不能把几块钱的苹果换成十块钱的苹果。

实际上这玩意儿叫 DML，数据库的核心就是跟数据打交道。 敲代码的时候最怕配错参数，比如把主键搞成重复的，要么连起来根本连不上。遇到这种情况别急，大局部数据库都会帮你报警，告诉你“连表黄了，出于编号重复了”。

不过有些老系统要么没开守护机制的场景，可能会静默黄了，那就要手动去后台查一遍，确认那两行数据是不是确实存有，再去删掉重复的那一条。 写查询语句的时候得注意啥？`SELECT` 务必跟 `WHERE` 搭配，你不能只 `SELECT` 一列，那样结局集就是单行；要么只 `WHERE` 一列，结局集就是单列。

比如我想查所有学生名字，实际上没必要把年龄、院系、专业都列出来，直接 `SELECT 姓名` 更高效。

还有，`LIKE` 关键词里要加通配符 `%`，不然效果乱套。

比如搜“张"，结局就是“张三”、“张伟”这种全名都出来了；搜“张"，又变成了“小张”、“王张”这种名字带张的。 再说说事务，这就是数据库的“账本”。

要是你一边扣钱一边贷款，钱肯定对不上。数据库里的 ACID 原则里，Commit 就是要把账本拍板，所有操作要么全成功要么全黄了。

比如转账，钱务必归入同一个账户，不能分家。

要是中间出现异常，回滚机制会自动把刚刚的所有交易撤销回去，确保数据一致性。 插入数据时，记得检查主键。主键是数据库的“身份证号”，每个身份证号得独一无二，不能两个都是 1000001。

要是手动插入时不小心写错了，比如把 ID 写成了 1000002，仿佛没啥反应，那实际生效的是 1000002。

要是真操作了，那 1000001 这条记录可能已经烂在数据库里了，根本查不到，到时候数据对不上，得用 `DELETE` 删掉那一条作废的。 聚合函数也是处理批量数据的利器。

比如求总数，直接 `SUM`；求平均，`AVG`；求最大值，`MAX`；求最小值，`MIN`。

要是想算平均值还剔除零值，那就得加个 `WHERE` 条件，要么在 SQL 里用 `COALESCE(0, x)` 来处理空值。

不过更高级点的做法是用窗口函数，比如 `ROW_NUMBER()`，它能给每一行数据起个唯一编号。

要是我要按销售额从高到低排序，算出前 10 名的得分，用 `ROW_NUMBER() OVER (ORDER BY 销售额 DESC) LIMIT 10` 就能省事搞定。 更新数据的时候，大量人认定改个名字就行，但实际上可能改错了。

比如把所有人的名字改成“李小明”，这在逻辑上挺荒谬。

这时候得用 `UPDATE` 语句，再配合 `WHERE` 条件过滤。

比如 `UPDATE 学生 SET 姓名='李小明' WHERE 班级 = '1 班'`，这样就能确保只改这一班的，不影响其他班。 删除操作是最悬的。`DELETE` 要是不加 `WHERE` 就全删了，结局看着是删了 100 条，实际上可能只存了 50 条，剩下的 50 条就彻底没了，最终查出全体 0 条。

这时候得手动查 `SELECT COUNT()` 看看剩下了多少，再拍板要不要删。

要是在关键业务中误删了数据，往往要补库，成本极高。 外键约束也是数据整个性的最终一道防线。

比如订单表里有“用户 ID"，这个 ID 务必对应某个用户的 ID。

要是业务逻辑准订单取消后用户 ID 变更，那外键就得改，要么建个索引表存临时 ID 再关联。数据库能帮你自动维护，但人工干预有时候更精准。 最终，写完脚本别急着跑。先看 `SELECT FROM 表名` 看看大约长啥样，有没有重复记录。再试几条复杂的查询，比如加个 `GROUP BY` 要么 `HAVING`。有些脚本，比如全表扫描，性能可能不够好，试试加个索引，要么改用 `JOIN` 把相关表连起来。 遇到报错也别慌，看报错信息里的关键字段，比如 `Table name` 或 `Column name`。有些扩展名要么版本兼容性难题，换一个库试试就行。 总而言之，数据库不只是写 SQL 的人的私货，它是现代系统的数据基石。

哪怕玩得再溜，底层原理还是绕不开的。理解它，能让你写出更健壮、更智慧的代码，避免后面重复造轮子。