企业官网建设流程全解析

我最早学SQL的时候，最放松的就是这一章：ORDER BY 不就是排序，INSERT INTO 不就是插数据，UPDATE 改行，DELETE 删行。后来我在线上环境被这几个“简单语句”反复教育过，才发现它们每个都藏着一堆执行细节。比如 ORDER BY 明明时间字段加了索引还是慢；UPDATE 指定了条件却锁住了一大段索引范围；DELETE 删完后主从延迟持续了一个多小时。这篇文章就是围绕这四个语句，从执行原理到工程化写法做一次完整复盘。内容尽量照顾到不同基础的人，我会把原理、语法、坑和排查思路放到一起讲。

1. 为什么越基础的语句，越容易在线上翻车

1.1 三个层面的问题，会同时压在一句SQL上

对写业务代码的人来说，SQL语句“能跑出结果”通常就满足了。但在数据库里，一句简单的 UPDATE 或 DELETE 背后其实涉及三层因素：数据正确性、性能、一致性。

数据正确性很简单，就是别改错、别删错。但很多“错”并不是语句本身写错了，而是对表结构和索引状态理解不到位。比如 WHERE 条件字段上有函数，索引就会失效；比如 UPDATE 关联表时，JOIN 出一条记录对应目标表多行，执行结果可能和预期完全不同。

性能问题更隐蔽。ORDER BY 没走索引会触发排序；INSERT 批量插入时单条语句过大直接报错；UPDATE 或 DELETE 扫了大范围行，不仅事务要盯住很多行，产生的 binlog 和回滚记录也会拖垮整个集群。我曾经遇过一个团队把清理任务写成一条 DELETE 不带 LIMIT 在凌晨跑，结果主库 IO 被打满，业务侧所有写操作排队。

一致性则体现在事务边界和主从架构上。同样一条 DELETE，在百万行表上删除 50 万行，事务提交后从库可能还在慢慢回放 binlog；如果这时候再有查询打到从库，看到的旧数据就会造成业务误解。所以我一直觉得，基础语句并不基础，只是很多人还没踩到它们制造的事故。

1.2 我给自己定下的三条自检红线

踩过几次坑之后，我给团队定了几条硬性红线，也分享给看到这篇文章的你。

第一条：UPDATE 和 DELETE 在执行之前，必须先跑一遍 SELECT 确认影响范围。这里的 SELECT 不光是看几条数据，而是用 COUNT 检查行数，用 LIMIT 抽查具体内容。只有确认条件选的确实是想改的那些行，才允许执行写操作。

第二条：不带 WHERE 条件的 UPDATE 和 DELETE 禁止在生产环境直接执行。即便想清空表，也应该用 TRUNCATE 或先确认业务影响再操作。没有任何条件限制的 DML 一旦上去，就等于把整个表交给了运气。

第三条：大表写操作不能一条语句跑到底。影响行数超出阈值时，要拆成小批次，批与批之间留出间隔。具体的拆分方法后面会讲。

1.3 十分钟回顾一次典型事故

有一回，某模块的配置表被人执行了一条 UPDATE，没写 WHERE，把整张表的 status 字段全部覆盖成了另一个值。好在配置表行数不多，也没有外键关系牵扯，最终通过备份恢复了部分数据，但仍有最近一小段时间内的改动无法找回，影响了好几条线上配置。

复盘时发现，执行者原本是想更新某一行，但 SELECT 出来后复制了 WHERE 条件，粘贴时丢掉了条件。这个过程的可怕之处在于：语句合法、权限正常、执行成功，没有任何提示。数据库不会问你是不是真的想改全表。

从那次之后，我要求团队所有人在客户端工具里写 DML 前，先手动加一行WHERE 1=1 AND ...，从结构上强迫自己带上条件。看起来有点笨，但确实有效。

2. ORDER BY：排序结果不可靠的四个常见原因

2.1 索引排序与filesort，什么时候排序能“免费”

ORDER BY 要解决的核心问题不是“能不能排”，而是“排得快不快”。在 MySQL 里，排序有两种途径：一种是直接利用索引顺序读取数据，这被称为索引排序；另一种是读取数据后，在内存或磁盘上额外执行排序操作，也就是 filesort。

索引排序的成本很低，因为数据本身已经有序。比如有一张订单表，联合索引建立在(status, created_at)上，那么：

SELECT order_no, created_at FROM orders WHERE status = 1 ORDER BY status, created_at;

查询走完索引，结果天然有序，MySQL 不需要额外排序。但下面这条就不行：

SELECT order_no, created_at FROM orders WHERE status = 1 ORDER BY created_at, status;

ORDER BY 的字段顺序和联合索引的前缀顺序不一致，索引顺序无法直接复用，优化器只能把筛选出来的数据再排一次。数据量越大，额外排序的代价越明显。

判断一条 ORDER BY 是否走了索引，最直接的方法是EXPLAIN，看Extra字段有没有出现Using filesort。出现 filesort 不代表一定是灾难，但它意味着排序消耗在查询结果集上，一旦筛选后的行数很大，执行时间会直线上升。

2.2 排序规则、NULL值位置和“看起来没用的第二排序键”

排序结果“不对”，有时候不是数据库出错，而是排序规则和默认行为和我们想的不一样。

先看 NULL。MySQL 里默认 ASC 升序时，NULL 值排在最前面；DESC 降序时，NULL 值排在最后面。PostgreSQL 恰恰相反，升序时 NULL 排最后。如果一段代码从 MySQL 迁到 PostgreSQL，而业务依赖 NULL 在列表末尾，那排序结果直接翻转。跨数据库场景下，建议显式写出NULLS LAST或NULLS FIRST。

再看字符集和排序规则。MySQL 中utf8mb4_0900_ai_ci和utf8mb4_general_ci对大小写、重音字符的比较结果都有差异。在大小写不敏感的排序规则下，a和A被认为是相等的；如果页面想实现“大写排前面、小写排后面”的效果，就不能依赖默认排序规则，需要用 BINARY 强制或改变排序规则。

还有一个很容易被忽略的点：ORDER BY 的字段如果只有唯一性非常弱的列，比如只按created_at排，而同一秒内有多条记录，那数据库只要保证结果集内满足排序规则即可，相同时间戳的行之间的相对顺序是任意的。这个“任意”会造成分页时页面之间数据重复或错位。

解决办法很简单：在排序字段后追加一个全局唯一的字段，通常就是主键。

SELECT order_no, created_at FROM orders WHERE status = 1 ORDER BY created_at DESC, id DESC;

2.3 深分页：ORDER BY 加 LIMIT，为什么越翻越慢

只要是带排序的分页查询，都会遇到深分页问题。比如：

SELECT id, title FROM articles ORDER BY published_at DESC LIMIT 100000, 20;

数据库需要先把全表符合条件的记录按排序字段排好，然后跳过前面 100000 条，只返回第 100001 到 100020 条。问题是，跳过的 10 万条不是真的“跳过”，它们都必须参与排序，排序结果还要保存在临时结构里，这非常浪费。

优化方向是“让数据库少排点数据”。常见的做法是键集分页，也就是记住上一页的最后一条排序字段值，下一页直接从该值之后开始查：

SELECT id, title FROM articles WHERE published_at < '2026-03-01 12:00:00' ORDER BY published_at DESC LIMIT 20;

如果排序字段不唯一，还需要同时携带主键作为边界条件：

SELECT id, title FROM articles WHERE (published_at, id) < ('2026-03-01 12:00:00', 100) ORDER BY published_at DESC, id DESC LIMIT 20;

这种写法只适用于“上一页下一页”的交互模式，不支持点击第 100 页。但绝大多数业务里，用户根本不会那样翻页，换成键集分页后性能能提升好几个量级。

2.4 一个排序踩坑案例：同秒订单造成的列表错乱

有段时间我维护的订单列表页总是被反馈“排序不稳定”，同一批订单换个页面刷新，顺序就变了。最初怀疑程序里有并发问题，查了很久才发现是 ORDER BY 只写了created_at DESC。线下订单创建频率高，同一秒内下单量很大，数据库对相同排序值的结果并没有稳定顺序。

修复方案就是加id DESC作为第二排序键。这个例子让我彻底记住：业务排序不允许有二义性排序键，凡是可能重复的字段，后面必须接一个唯一字段。

3. INSERT INTO：写入正确性远不止“能存进去”

3.1 写列名还是省略列名，两种习惯的差距

INSERT 的基础写法有两种：

-- 显式列出列名，推荐 INSERT INTO orders (order_no, user_id, amount, created_at) VALUES ('A1001', 1001, 299.00, NOW()); -- 省略列名，依赖表结构顺序 INSERT INTO orders VALUES (NULL, 'A1001', 1001, 299.00, NOW());

省略列名的写法看起来短，但非常危险。表结构一旦调整字段顺序，这条 INSERT 就可能把数据写进错误的列；如果新增了一个非空字段但没有默认值，还会直接报错。显式列出列名，相当于给数据加了一层“字段名到值”的映射，可读性更好，也能减少结构变更带来的问题。

对于带默认值的列，如果希望它取默认值，可以直接使用 DEFAULT 关键字：

INSERT INTO orders (order_no, user_id, status, amount) VALUES ('A1001', 1001, DEFAULT, 299.00);

这里 DEFAULT 表示让数据库给 status 填上默认值，而不是写死一个具体值。好处是，后续默认值变更时，已经写入的数据会自动体现新语义吗？不会。但至少在初始化时，你没有把业务默认规则硬编码到 SQL 里。

3.2 批量插入、INSERT...SELECT 与 INSERT IGNORE

一次插入多行，比循环单行执行快得多。多行 VALUES 是最直接的批量方式：

INSERT INTO orders (order_no, user_id, amount) VALUES ('A1001', 1001, 299.00), ('A1002', 1002, 99.00), ('A1003', 1003, 150.00);

这种方式可以减少请求次数和日志同步开销，但绝不能贪大。单条 SQL 的大小要受到max_allowed_packet参数限制，默认通常是 64MB，但实际生产环境很少会设得这么大。批量插入时，如果某一行包含很大的 TEXT 或 BLOB 字段，很快就会超限。

INSERT ... SELECT 是另一种批量写入手段：

INSERT INTO order_backup (order_no, user_id, amount) SELECT order_no, user_id, amount FROM orders WHERE created_at < '2025-01-01';

执行这条语句前，应该先 EXPLAIN 后面的 SELECT，确认它不会导致全表扫描，或者确认全表扫描在可控范围内。因为 INSERT ... SELECT 会在源表上加锁，如果源表很大，锁范围也会很大，影响线上读写。

INSERT IGNORE 适合“有重复就忽略”的场景，但要注意：它忽略的不仅仅是唯一键冲突，还包括一些其他错误，比如数据超长被截断时，可能也会被忽略。过度依赖 INSERT IGNORE，可能掩盖真正需要修正的数据问题。

3.3 唯一键冲突时的幂等写入方案

实际业务里经常遇到重复导入的问题：同一个文件被传了两次，同一批消息被消费了两遍。如果表里有业务唯一键，INSERT 就会碰到冲突，这时有几种选择。

MySQL 里最常用的是 ON DUPLICATE KEY UPDATE：

INSERT INTO user_stat (user_id, order_count, updated_at) VALUES (1001, 1, NOW()) ON DUPLICATE KEY UPDATE order_count = order_count + 1, updated_at = NOW();

这条语句的语义是：能插入就插入，如果唯一键冲突，就执行后面的更新。这很适合做计数累加、幂等写入。

但要注意，它判断“重复”的依据是主键或唯一键。如果表里没有任何唯一约束，它不会产生预期的去重效果，相同业务数据会不断插入新行。另一个坑是：它执行时对命中的记录加锁，如果同一批数据被大量并发线程写入，锁竞争会非常明显。

在 PostgreSQL 里，功能等价的是 ON CONFLICT：

INSERT INTO user_stat (user_id, order_count, updated_at) VALUES (1001, 1, NOW()) ON CONFLICT (user_id) DO UPDATE SET order_count = order_count + 1, updated_at = NOW();

跨库迁移时，这两个写法不能直接搬过来。

3.4 写入性能与参数细节，别让大批量插入卡死主库

批量插入不是越大越好。我见过一个同步任务，每批 10000 条记录，每条记录里还有一个几十 KB 的文本字段，结果单条 INSERT 直接超过max_allowed_packet。调整参数固然可以解决，但那只是把压力往后推。更合理的做法是：根据平均行大小估算单批上限。一个经验公式是，单批 SQL 的数据量控制在 1MB 到 5MB 之间，再多就拆。

另一个容易被忽略的点是事务。批量写入时，最好把同一批操作放进一个事务里，避免每插入一行都提交一次，这样能大幅减少磁盘同步和日志刷盘次数。但事务也不能太大，如果一次性插入几十万行不提交，undo log 会膨胀，回滚段压力也很高。所以“大事务”和“频繁小事务”之间需要平衡。

如果同步的是历史数据，而且源表在写入期间没有业务改动，可以考虑在低峰期暂时关闭自动提交，分批插入并定期提交。如果目标表是线上核心表，这种方案风险很高，不建议照搬。

4. UPDATE：改错行是常态，问题出在没理解“行选择逻辑”

4.1 写前验证三步法，每次都能救你一次

UPDATE 语句的核心是“行选择逻辑”。绝大多数改错行的事故，不是因为 SQL 写错了，而是因为对 WHERE 条件会选中哪些行没有准确预判。

我建议每次执行 UPDATE 前，都走这三步。

第一步，用条件查出数量：

SELECT COUNT(*) FROM orders WHERE status = 1 AND shop_id = 1001;

这一步影响行数，确认条件不是“全表”。

第二步，抽查实际数据：

SELECT id, order_no, status, shop_id FROM orders WHERE status = 1 AND shop_id = 1001 LIMIT 20;

看一眼真实内容，确保条件选中的确实是想改的数据。

第三步，把相同的 WHERE 条件搬到 UPDATE 语句里：

UPDATE orders SET status = 2 WHERE status = 1 AND shop_id = 1001;

看起来很简单，但很多人会跳过第一步和第二步。等到 UPDATE 执行完，才发现把新店的数据也一起改了。三步加在一起也就十几秒时间，却能挡住大量低级错误。

4.2 连表更新的不同写法与最大陷阱

业务里经常需要根据另一张表的值来更新当前表。不同数据库的写法不一样。

MySQL 里最常见的是 UPDATE JOIN：

UPDATE orders o JOIN refunds r ON r.order_id = o.id SET o.refund_status = 2 WHERE r.status = 1;

PostgreSQL 里用的是 FROM 子句：

UPDATE orders o SET refund_status = 2 FROM refunds r WHERE r.order_id = o.id AND r.status = 1;

SQL Server 的 UPDATE 也支持 FROM JOIN，但语法细节略有不同。

连表更新最大的陷阱是：JOIN 的驱动表如果有多条记录匹配目标表同一行，目标行可能被更新多次，而最终结果取决于哪一条匹配记录后生效。看一个例子：退款表里同一订单存在多条退款记录，一条状态是“处理中”，另一条状态是“已完成”。如果 JOIN 条件没有加唯一约束，UPDATE 后订单的 refund_status 到底是 2 还是 3，完全取决于扫描顺序。

所以写连表更新前，必须先验证 JOIN 后目标表是否唯一。验证方式仍然是先 SELECT：

SELECT o.id, COUNT(*) FROM orders o JOIN refunds r ON r.order_id = o.id WHERE r.status = 1 GROUP BY o.id HAVING COUNT(*) > 1;

只要查出有重复，就必须调整 JOIN 条件，让每个目标行只对应一条来源记录。

4.3 索引、外键和锁：一条 UPDATE 的背后成本

一条 UPDATE 看着只是改几个字段，但在数据库内部，它要做的事远不止这些。

如果更新的字段上有索引，二级索引也要同步更新。更新主键或唯一键时，代价更高，因为唯一性约束需要检查，如果有外键引用，外键约束也要校验。数据量大时，这些开销会被成倍放大。

锁的范围也非常关键。WHERE 条件如果命中索引，InnoDB 通常可以对索引区间加锁，锁定的行数相对可控。但如果 WHERE 条件没有索引，为了找到需要更新的行，数据库可能扫描大量记录，并对扫描过程中遇到的记录加锁。这就是为什么一条 UPDATE 明明只改几十行，却能把整张表的读写都堵住。

在低版本 MySQL 里，如果 WHERE 条件不是索引列，UPDATE 可能造成间隙锁扩大，影响范围甚至远超预期。线上执行 UPDATE 前，用 EXPLAIN 看一下 possible_keys 和 key，确认条件走的是不是索引，非常重要。

4.4 别让一条 UPDATE 锁住全库：分批更新的工程化做法

大表更新不能指望一条 SQL 快速跑完。分批更新的思路是：每次只处理一小段主键范围或时间范围，每批次单独提交，然后再处理下一批。

假设要更新一张有几百万行订单表里的所有 status=1 的记录，可以这样分片：

-- 每次更新 5000 行左右的主键范围 UPDATE orders SET status = 2 WHERE id BETWEEN 1 AND 5000 AND status = 1;

然后在应用层写一个循环，逐段推进。也可以用时间范围作为分片条件。

更常见的伪代码逻辑是：

batch_size = 5000 while True: affected = execute( "UPDATE orders SET status = 2 " "WHERE status = 1 LIMIT 5000" ) if affected == 0: break commit() sleep(0.1) # 给主从延迟和锁释放留出时间

这里 LIMIT 5000 是 MySQL 的 UPDATE 语法特性，其他数据库不一定支持。但工程化的思路是一致的：让每一批操作占用的锁时间足够短，给其他业务语句留出穿插执行的机会。

分批的批大小没有标准答案，取决于表大小、字段宽度和数据库负载。我会在测试环境先跑一批，观察执行耗时和锁等待情况，再决定是否增大或减小批次。

5. DELETE：删完才发现没备份是最贵的学费

5.1 DELETE 与 TRUNCATE，两者不是一回事

清空一张表，很多人会直接写 DELETE FROM table，但这不是最快的方案，也不算最安全的方案。TRUNCATE 和 DELETE 的差异，值得每个人记清楚。

如果你的目标只是“把表里数据清空，保留表结构”，TRUNCATE 通常比 DELETE 快很多。但它代价也明显：不能回滚。就算事务还没提交，TRUNCATE 也不会像 DELETE 那样让你可以 ROLLBACK。所以在生产环境执行 TRUNCATE，必须比 DELETE 更谨慎。

还有一种情况是删掉表中绝大多数行、保留少量行。直接 DELETE 几百万行不仅慢，锁和时间都很长。更推荐的做法是“建新表、导数据、换表名”。先创建一个结构相同的新表，把要保留的数据 INSERT 进去，然后原子换表。虽然少了直接用 DELETE 的直观感，但对线上服务和运维来说要友好得多。

5.2 条件删除的写前验证与分批策略

DELETE 的 WHERE 条件，要求和 UPDATE 一样谨慎，甚至更谨慎，因为删掉的数据恢复成本极高。执行 DELETE 前，我很喜欢先看一眼这两条语句：

SELECT COUNT(*) FROM orders WHERE created_at < '2024-01-01'; SELECT COUNT(*) FROM orders WHERE created_at < '2024-01-01' LIMIT 100;

第一条用来确认影响范围，第二条用来抽查实际数据。

批量删除同样建议分批。MySQL 里可以写成：

DELETE FROM orders WHERE created_at < '2024-01-01' ORDER BY id LIMIT 1000;

配合循环执行。有人会担心 LIMIT 删除会不会漏删，这里的关键是：每批删除后，下一次执行仍然用同一条件，新一批会删除剩下的第一优先行。只要 WHERE 条件不因为前面的删除而改变语义，就不会漏。

分批删除时，我还会在每批之间停顿。一方面是让主从延迟回放跟上，另一方面是避免连续大删除把缓冲池换页压力全部打满。

5.3 别忽略外键级联删除

很多表之间通过外键建立了 ON DELETE CASCADE。删除父表数据后，子表数据会被数据库自动删除。这个机制本来是好事，但问题在于级联删除的规模和锁范围完全不可控。

我处理过一个案例：业务表里删除一条组织记录，结果级联删掉了上万条用户记录、几十万条明细记录。执行 DELETE 的那条语句本身很快，但级联产生的删除操作持续了很长时间，最后主从延迟飙升，业务查询整体变慢。

如果表结构已经存在级联关系，删除父表数据前，先手动统计一下关联数据量会更稳妥。一个粗略的方式是分别对从表执行 COUNT，确认涉及范围，再决定是否真的执行删除。如果数据量超出预期，就要考虑先删子表，再删父表，或者改用逻辑删除。

另外需要提醒的是，SET foreign_key_checks = 0可以临时禁用外键检查，但绝对不应该作为常规手段使用。禁用外键后，数据完整性可能被破坏，而启用外键时会重新校验，端口迁移时尤其容易遇到各种奇怪的失败。

5.4 误删之后的补救流程：备份、binlog 和临时库

假设真的发生了误删，能不能恢复，取决于两个东西：有没有备份，以及有没有开启 binlog。

如果只有备份，恢复方式是把备份还原到一个临时库，找到删除操作发生前的时间点，提取需要的数据，再补回线上。如果备份是每天凌晨做的，而误删发生在下午，那么备份只能恢复到凌晨的状态，中间所有变更都会丢失。

如果有 binlog，并且 binlog 保存时长覆盖了误删时间点，可以做时间点恢复。大致流程是：

1. 找到误删语句在 binlog 中的位置，这一步用 mysqlbinlog 工具解析。
2. 将误删语句之前、之后的所有 binlog 重放到一个临时实例，或者直接恢复到误删前一个时间点。
3. 从临时实例中导出误删的数据，再补写回生产库。

这个流程听起来简单，但执行时非常耗时，而且遇到 DDL 或大批量写入时，重放可能失败。所以最有效的办法仍然是事前预防：开 binlog、定期备份、删除前先 SELECT、分批删除、风险操作提前申请变更窗口。

6. 跨库迁移时要记住的语法差异

6.1 排序与分页差异

MySQL 最熟悉的分页写法是LIMIT offset, row_count或LIMIT row_count OFFSET offset。PostgreSQL 也支持 LIMIT/OFFSET，但更标准的写法是：

SELECT ... ORDER BY created_at DESC OFFSET 100 ROWS FETCH NEXT 20 ROWS ONLY;

SQL Server 用的是 OFFSET/FETCH。如果你的项目未来可能更换数据库，分页查询最好集中封装，避免到处散落着 LIMIT 语法。

NULL 值排序的差异前面提过。MySQL 升序时 NULL 在前，PostgreSQL 默认 NULL 在后。如果想在两种数据库都得到一致结果，必须显式写NULLS FIRST或NULLS LAST。

6.2 插入冲突处理差异

MySQL 用 ON DUPLICATE KEY UPDATE，PostgreSQL 用 ON CONFLICT。SQL Server 里没有直接对应的 INSERT 冲突处理，通常要用 MERGE 语句。

从 MySQL 迁到 PostgreSQL，最简单的兼容策略是保留 INSERT IGNORE 的语义，在 PostgreSQL 里写成：

INSERT INTO user_stat (user_id, order_count) VALUES (1001, 1) ON CONFLICT (user_id) DO NOTHING;

如果既要更新，就把 DO NOTHING 换成 DO UPDATE。还有一个细节：ON CONFLICT 后面必须明确冲突字段，MySQL 是自动检测任意唯一键冲突，两者行为不完全一致。

6.3 连表更新与删除别名的差异

连表更新语法差异很大：

• MySQL：UPDATE t1 JOIN t2 ... SET ...
• PostgreSQL：UPDATE t1 SET ... FROM t2 WHERE ...
• SQL Server：UPDATE t1 SET ... FROM t1 JOIN t2 ON ... WHERE ...

删除时也有别名差异。比如要删掉“存在退款记录但订单已关闭”的订单，MySQL 可以写：

DELETE o FROM orders o JOIN refunds r ON r.order_id = o.id WHERE o.status = 4;

PostgreSQL 里要写成：

DELETE FROM orders o USING refunds r WHERE r.order_id = o.id AND o.status = 4;

这些差异在单一数据库下根本不会暴露，但一旦代码需要支持多种数据库，就会变成迁移痛点。团队如果有跨库计划，应该从一开始就在 SQL 编写规范里限制某些写法，或者直接用 ORM 的能力做租户层隔离。

7. 平时怎么练这四类语句：我的习惯

最后分享几个我实际工作中坚持的习惯，希望对你有用。

第一，准备一个专用的沙箱环境，里面放一份和生产结构一致、但数据量较小的数据副本。所有 UPDATE、DELETE 新写法，先在沙箱验证影响行数和执行计划，再拿到生产执行。很多事故其实都是因为第一次写某条语句，直接在产线上试错。

第二，所有涉及 DML 的变更脚本纳入代码仓库管理。文件名带上日期和业务描述，通过代码评审后再执行。不要只在本地草稿里写，也不要直接在数据库客户端里复制来复制去。脚本留存下来，后续一旦出现数据问题，可以快速还原当时到底执行了什么。

第三，对慢查询日志保持敏感。ORDER BY 相关查询如果频繁出现在慢日志里，第一反应不应该是加缓存，而是先看执行计划，确认是否可以利用索引排序。很多深分页问题，加缓存根本解决不了，因为不同页面请求不同 offset，缓存命中率很低。

第四，写任何 UPDATE 或 DELETE，都先从 SELECT 开始。这句话我重复了很多次，因为它真的是我用一次次事故换来的习惯。哪怕今天只是改一行数据，也值得多花几秒钟确认影响范围。

这四个基础语句确实简单，但简单不等于可以轻视。它们承担了日常开发里几乎所有的数据读写变化，也最容易在不经意间造成难以挽回的损失。希望你把这些排查思路和预防习惯落到自己的项目里，别等线上出问题再回头看。