第20天-《DBA实战手记》阅读打卡

IO高负载导致数据库故障

1、表现形式：

• 大量全表扫描（如未使用索引的SELECT * FROM TABLE）导致磁盘随机IO激增，磁盘响应时间变长，甚至引发数据库宕机。

• 频繁大事务写入（如批量插入未分批）导致日志文件（redo/undo）IO瓶颈，数据库写入性能骤降。

2、底层原理：

• 数据库IO瓶颈通常来自 “随机 IO”（如全表扫描），其效率远低于 “顺序 IO”（如索引范围查询）。当随机IO占比超过70%时，磁盘吞吐量可能下降50%以上。

• 缓冲区缓存（Buffer Cache）失效：高IO SQL会频繁读取磁盘数据，导致缓存被频繁替换，后续查询再次触发磁盘IO，形成恶性循环。

慢查询与资源耗尽

1、典型场景：

• 复杂JOIN查询未优化索引，执行计划选择低效嵌套循环，消耗大量 CPU和内存。

• 未分页的大结果集查询（如SELECT * FROM TABLE），导致网络带宽和内存溢出，数据库进程被操作系统kill。

2、连锁反应：

    慢查询堆积会导致数据库连接池被占满，新请求无法建立连接，业务系统报错 “无法连接数据库”。

锁竞争与并发阻塞

• 长事务操作（如未提交的 UPDATE）持有行锁或表锁，阻塞其他事务，形成死锁。

• 非必要的排他锁（X锁）使用，如全表更新未加条件，导致表级锁阻塞所有读写操作。

几乎所有的DBA从使用和维护数据库的经验中得出的结论是：影响数据库稳定的主要问题来自SQL。造成数据库故障的通常是那些IO吞吐量大的SQL。书中列出了一些SQL开发规范，几乎都是避免大IO吞吐量所定制的SQL规范，对生产实践很有帮助。

（1）对查询进行优化，尽量避免全表扫描，SQL应该包含符合客观情况且有意义的where条件。

• 说明：全表扫描会逐行读取整个表的数据，导致大量 IO 操作。通过添加合理的 WHERE 条件，可以利用索引快速定位所需数据。

• 示例：SELECT * FROM users;

（2）尽量避免在where子句中仅仅使用!=、<>或or操作符，应尽量避免在where子句中对字段进行null值判断及使用or来连接条件。

• !=、<>会导致索引失效，强制全表扫描。

• OR连接多个条件时，若其中一个字段无索引，会导致整个查询放弃索引。

• IS NULL/IS NOT NULL无法使用索引（除非是NULL索引优化场景）。

（3）谨慎使用not in。

        说明：NOT IN会遍历子查询结果，若子查询结果集大，性能极差。

（4）绝对禁止通配符第一位是%。

        说明：LIKE '%xxx'无法使用索引，需全表扫描。

（5）禁止使用select * from table for update。

        说明：FOR UPDATE会锁定全表，阻塞其他事务。需明确锁定的行。

（6）禁止在where子句中的"="左边进行函数、算术运算或其他表达式运算。

        说明：对索引字段进行运算会导致索引失效。

（7）避免复杂语句，循环嵌套不应超过3层，关联表不要超过3张，避免不必要和无意义的排序。

• 复杂嵌套会导致执行计划失控，关联表过多会增加笛卡尔积风险。

• 排序操作（如ORDER BY）会触发临时表和文件排序，消耗CPU和 IO。

（8）禁止使用null和空格等不确定含义的字符作为业务判断逻辑。

     说明：NULL在逻辑运算中会导致不可预期结果（如NULL AND TRUE = NULL）。

（9）where条件一定要包含索引的第一列。

        说明：复合索引遵循 “最左前缀匹配” 原则，若 WHERE 条件不包含索引首列，则无法使用索引。

（10）对于大表的查询，一定要带分页。

        说明：避免一次性返回大量数据，导致内存溢出和网络拥塞。

（11）对于大表不允许不带where条件。

（12）update必须带有条件，并且条件字段是带有索引的列。

        说明：无 WHERE 条件会更新全量数据，无索引条件会导致全表扫描锁定。

（13）多表关联禁止产生笛卡尔积。

        说明：缺少 JOIN条件会导致两个表数据两两组合，结果集呈指数级膨胀。

（14）查询范围需要有上下限，不能只有一侧。

     说明：单边范围（如WHERE id > 1000）可能导致扫描大量数据。

    示例：低效：SELECT * FROM products WHERE price > 100;优化：SELECT * FROM products WHERE price BETWEEN 100 AND 1000;

（15）谨慎控制in或or的个数。

        说明：IN或OR条件过多会导致索引失效或查询计划异常。

（16）or涉及的字段必须都有索引。

        说明：若OR条件中有字段无索引，整个查询会放弃索引。

价值

• 稳定性提升：减少IO瓶颈、锁竞争，降低数据库宕机风险。

• 性能优化：规范化SQL可使查询响应时间提升10-100倍，如全表扫描优化为索引查询后，IO消耗从10000次降至10次。

• 成本节约：避免因SQL低效导致的硬件扩容成本（如 SSD磁盘采购），同时降低运维排查时间成本。

核心原则

SQL规范化不仅是技术要求，更需融入研发流程，通过 “设计 - 审核 - 监控 - 优化” 闭环，实现数据库的持续稳定运行。

星辰大海，永不止步

《DBA实战手记》的书页在指尖悄然翻至末章，然求知的烛火并未随打卡印记的终结而熄灭！

步履不停，便是对知识最深情的回响！