我一边准备 Oracle OCP 082 认证考试，一边复习软件设计师考试中的“结构化开发方法”这部分内容时，发现一个很有意思的现象：按科目划分，一个是数据库认证里的 SQL 与性能调优，一个是软件工程里的系统分析与设计，两者看起来八竿子打不着。但真把知识点一个个翻出来对比时，它们的内核其实高度一致——都是在有限条件下，通过拆解结构来降低复杂度、减少无效开销。
数据库侧的核心工作是索引优化。你面对一张几百万行的订单表，查询条件怎么写、索引怎么建、执行计划怎么跑，是多少开发在日常项目里必须处理的真实问题。软件设计师侧的核心工作是结构化方法。需求分析阶段怎么画数据流图，设计阶段怎么划分模块、保证高内聚低耦合，这套方法论决定了系统后续是否容易理解和维护。
这篇文章我会用备考中实际遇到的题型和场景，把 OCP 082 里那些容易混淆的索引优化规则讲清楚，再把软件设计师 06 章节中的结构化开发方法按考点串一遍。文章不是要帮你背题，而是把背后的判断逻辑梳理明白。无论你是在准备这两个考试之一，还是只在做日常项目开发，里面的思路都可以直接拿去用。
1. 两个科目的定位和共同主线
1.1 先看 OCP 082 到底考什么
OCP 082 这个科目，很多资料会把它和 081 合并讲，实际上它的考察重点是数据库开发侧的 SQL 技能。从大纲内容和实际考试体感来看，需要重点掌握的几个模块大致是这样：
- 单表查询、多表连接查询的 SQL 写法，包括外连接、自连接、集合运算；
- DML 语句的使用，包括多表插入、合并更新等高级写法；
- 事务控制和数据一致性，重点看提交、回滚、锁等待这些行为；
- 表、索引、约束等对象的管理，尤其索引相关运维语句；
- 通过索引提升查询性能的优化思路，这部分在考试里占比不算小。
很多参加过考试的人会有个共同感受：SQL 语法题不难，难的是“给你一段执行计划，让你判断索引为什么没被用上”，或者“给出两条相似的 SQL，让你判断哪条更高效”。这类题目不会直接考你“什么是 B 树索引”，而是把索引规则隐藏在具体场景里。所以如果平时只看概念，没有真正在数据库里跑过实验，遇到这种场景题很容易翻车。
我在这篇文章里专门把“索引优化”拎出来讲，不是因为它新，而是因为它的考察方式特别贴近真实开发。考试题目里的订单表、客户表，和你项目里的表几乎没有区别，判断逻辑也一样。把索引优化复习透了，不只是过考试，工作里给慢查询做优化的底子也打好了。
1.2 软件设计师里的“结构化开发方法”是什么
软件设计师是软考中级的一个方向，上午科目覆盖软件工程基础知识，下午科目考案例分析。结构化开发方法在其中是非常固定的一块内容，通常在教材里排在“系统开发基础”或“软件工程”相关章节，大纲编号一般写成“06 结构化开发方法”。它的核心就一句话：用一套结构化的流程来管理软件开发全过程，包括结构化分析、结构化设计、结构化程序设计三个阶段。
结构化分析阶段，输出数据流图、数据字典、加工说明。结构化设计阶段，把分析结果映射成软件结构，核心是高内聚低耦合。结构化程序设计阶段，则强调顺序、选择、循环三种基本控制结构。这套方法论听起来老，但考试中每年都会以“基础题 + 案例题”的形式出现。上午题喜欢考概念归属，比如“数据流图由哪四要素组成”“哪种内聚程度最高”；下午题喜欢让你根据需求描述画数据流图，或者分析模块之间的耦合类型。
我第一次复习时也有点看轻它，觉得现在做项目都是微服务、领域驱动设计，谁还画数据流图。但后来发现，数据流图其实是一种极其高效的需求表达工具，它逼你先理清数据从哪里来、经过哪些加工、又流向哪里。这和调 SQL 之前先看执行计划一样，都是在做“结构层面”的定位。两个科目放在一起复习之后，我的理解速度明显加快了。
2. OCP 082 里索引优化需要建立的基本功
2.1 索引类型选择：B 树、位图、函数索引、反向键
先澄清一个基础概念。索引不是“给表加个搜索框”，而是一种独立的数据库对象，它记录了索引列的值和对应行的物理位置。Oracle 里最常见的索引是 B 树索引，也叫常规索引，适合大量不同的取值场景。它会在索引键上建立一颗平衡树，查找时从根节点一路往下，能很快精确定位到一个或一小段范围内的数据行。
位图索引和 B 树索引思路完全不同。它不是存键值和行地址，而是为每个取值用一个位图表示哪些行命中。比如“性别”列只有“男”“女”两种取值，位图就特别紧凑，统计查询时可以直接做位运算。但位图索引有一个很致命的弱点：在高并发 DML 的情况下，对列的修改会锁定大量的位图段，导致并发性能急剧下降。所以位图索引通常用于数据仓库、决策分析系统这类低写入高频查询的场景，而不是 OLTP 业务库。
基于函数的索引比较特殊。它创建的键不是列本身，而是对列进行函数运算后的结果。例如CREATE INDEX idx_emp_upname ON employees(UPPER(last_name))，查询条件写成WHERE UPPER(last_name) = 'SMITH'时才能命中这个索引。如果查询里写WHERE last_name = 'SMITH'，索引就用不上，因为它索引的键是函数结果，不是原始值。
还有反向键索引，主要用于解决单调递增列在 B 树中产生右侧热点的问题。它将键值反转存储，比如 12345 变成 54321，让插入分散到不同叶子块。这种索引适合用于序列生成的主键，但范围查询场景基本无法使用，因为相邻键被反转后不再物理相邻。
考试里遇到索引类型判断题，优先看业务场景：OLTP 选普通 B 树，数据仓库低基数统计选位图，什么情况下能避免从普通列获取数据就优先选择覆盖索引。我把四种索引的选择要点整理成了一张速查表，后文会放到常见问题部分。
2.2 执行计划：优化器判断的依据
建好索引不等于查询一定会走。Oracle 优化器在选择执行计划时，主要基于对象统计信息来做成本估算，统计信息包括表的行数、块的个数、列的可选值数量、数据分布直方图等。优化器会计算多种访问路径的成本，比如全表扫描的成本、走某个索引扫描再回表的成本，最终选择一个它认为成本最低的计划。这就是为什么有时候你明明建了索引，执行计划里显示的却是全表扫描。
看执行计划时，要重点关注几个字段：操作类型、对象名、成本、行数、谓词信息。比如：
| Id | Operation | Name | Rows | Bytes | Cost | | 0 | SELECT STATEMENT | | 10 | 250 | 3 | | 1 | TABLE ACCESS BY INDEX ROWID BATCHED | ORDERS | 10 | 250 | 3 | | 2 | INDEX RANGE SCAN | IDX_ORDERS_1 | 10 | | 2 |这个计划的意思是：先对 IDX_ORDERS_1 做索引范围扫描，找到匹配的 ROWID，再通过 ROWID 回表读取 orders 表的数据。Rows 字段是优化器估算的返回行数，Cost 是估算成本。对比另一个计划如果显示TABLE ACCESS FULL，那说明优化器认为全表扫描比走索引更便宜。
备考过程中，不用去背成本计算的内部公式，但要能读懂两层意思：第一，哪种操作是访问起点；第二，物化后有没有回表操作。能看懂这两层，大多数索引判断题已经能解决一半了。
2.3 索引扫描类型不要只记名字
常见索引扫描类型有六种：索引唯一扫描、索引范围扫描、索引跳跃扫描、索引全扫描、索引快速全扫描、索引全扫描后回表。考试和工作中最容易混淆的是“索引全扫描”和“索引快速全扫描”。
索引全扫描会按照索引本身的顺序读取所有叶子块，通常用于消除排序。由于读取顺序是按索引键排列的，它能做到有序输出。索引快速全扫描则不讲顺序，它可以一次性读取多个块，结果是无序的，但它对多块读有更高的吞吐量，适合统计查询。如果 SQL 需要ORDER BY，而执行计划里出现索引快速全扫描，那就可能还要额外做一次排序操作。
与之配套的一个操作是“回表”。通过索引定位到 ROWID 之后，再去表的数据块里取其他列的值，这个过程就是回表。回表次数多、单次又需要随机访问，性能往往不如直接全表扫描来的划算。所以实际工作中会出现一种优化技巧：把查询要用的列都放进索引里，让索引“覆盖”这次查询，完全省掉回表。后面讲覆盖索引时我会单独展开。
3. 第50题背后绕不开的索引优化规则
3.1 组合索引列序与最左前缀
组合索引不是简单地给多个列建索引，它的核心约束是最左前缀原则。比如执行：
CREATE INDEX idx_orders_combo ON orders(customer_code, status, order_date);这个索引实际上能支持这些查询条件组合：
WHERE customer_code = 'C10001'WHERE customer_code = 'C10001' AND status = 'PENDING'WHERE customer_code = 'C10001' AND status = 'PENDING' AND order_date >= ...
因为条件的起始列都包含索引的最左边一列 customer_code。反过来，如果查询只写：
WHERE status = 'PENDING' AND order_date >= ...优化器大概率不会使用这个组合索引，除非走索引跳跃扫描，但那需要前导列的可选值数量很少，属于特殊情况。
在安排组合索引列序时，有个经验法则：把等值查询条件列放在前面，把范围查询条件列放在后面。为什么要这么做？因为在 B 树索引里，键值按从左到右的顺序排序。等值条件能精确定位到一组范围很小的键，范围条件只能缩小到一个连续区间。如果把范围列放前面，等值列放后面，索引在遇到第一个范围条件之后，后面列就无法继续用于精确过滤了。
我踩过的一个典型例子：订单表上经常执行WHERE customer_code = '...' AND order_date BETWEEN ... AND ...，有人建了(order_date, customer_code)组合索引，结果执行计划走了全表扫描。把顺序调整成(customer_code, order_date)之后，索引范围扫描立刻生效，查询时间从几秒降到几十毫秒。考试里碰到“建立一个组合索引，要不要调整列顺序”这类题，优先考虑等值和范围的先后次序。
3.2 选择性：过滤因子比直觉更重要
很多开发对索引有一个错误直觉：查询条件里的列都应该建索引。实际上，索引是否高效，很大程度取决于选择性，也就是查询结果行数占表总行数的比例。为了让概念更直观，我拿实际生活打个比方：在一栋 3000 人的办公楼里找人，如果目标只有 30 人，你会先看楼层索引再逐个找；如果目标有 2500 人，直接在一楼大厅广播召集，比逐个房间敲门快得多。
数据库里的判断逻辑完全一样。当查询返回的行数占表总行数比例很高时，例如超过 10%~20%，优化器通常会认为全表扫描更便宜。因为走索引需要先读索引块，再按 ROWID 随机读数据块，每一个块都是一次随机 I/O。而全表扫描可以用多块读的方式，顺序读出所有数据。
关于过滤器的一个常见经典题目，我来模拟一下：
假设 orders 表有 100 万行，status 列只有 5 种取值，每个状态大约 20 万行。现在执行：
SELECT * FROM orders WHERE status = 'COMPLETED';如果只在 status 列上创建普通 B 树索引，优化器大概率仍然会选择全表扫描，因为要返回约 20 万行，用索引回表的代价太高了。考试里如果选项说“只要在 status 建了索引，这条查询一定会变快”，那基本可以直接判定这个说法有问题。
真正适合建索引的场景是：用户编号、订单编号、身份证号这类取值多、重复少的列。它们的选择性好，一个等值条件往往能把返回行数压到个位数或者几十行，这时索引的价值最大。选择性这个概念，是我复习时花最多时间理解的，它解释了一堆“为什么建了索引却没用”的怪现象。
3.3 不要在索引列上做运算或隐式类型转换
索引列只要被函数或运算包裹，优化器就很难、甚至无法使用该索引。最典型的两种写法：
第一种是函数包裹，例如：
SELECT * FROM employees WHERE UPPER(last_name) = 'SMITH';如果 last_name 上有一个普通 B 树索引，这个查询基本走不了索引，因为索引里存的是原始 last_name 的值，不是 UPPER 之后的值。除非你建一个基于 UPPER(last_name) 的函数索引。
第二种是列的隐式类型转换。比如表中 phone_no 列是 VARCHAR2 类型，你写：
SELECT * FROM employees WHERE phone_no = 13800138000;Oracle 会尝试把 phone_no 转换成数字来做比较，转换效果等于在列上套了一个函数，索引优势同样丢失。正确写法是：
SELECT * FROM employees WHERE phone_no = '13800138000';还有一种常见运算：
SELECT * FROM orders WHERE amount + 1000 > 3000;这种写法同样把 amount 列包进了表达式，索引失效。建议改写成：
SELECT * FROM orders WHERE amount > 2000;这个改写不仅逻辑等价，而且更符合“让索引列独立出现在条件一端”的原则。考试题目如果给出两条等价的 SQL，一条在列上做了运算，另一条没有，答案几乎都指向后者。
3.4 通配符查询和覆盖索引的边界
使用 LIKE 通配符时，有一个很实用的判断标准：前导通配符会切断索引范围扫描。比如WHERE name LIKE '张%'可以走索引范围扫描，因为“张”作为前缀限定了一个范围。但WHERE name LIKE '%张%'就无法走索引，因为任何位置的“张”都可能出现，无法形成可枚举的连续键值范围。
有一种例外是跳过扫描，但那是针对组合索引前导列缺失的情况，和 LIKE 本身无关。实际开发中如果必须做全文模糊匹配，更合适的工具是全文索引或搜索引擎，而不是普通 B 树索引。
覆盖索引是另一个高频考点。它的逻辑很简单：如果一条 SQL 所需的所有列都包含在某个索引中，那么查询只需要扫描索引，不需要再回到表里去取数据。比如：
SELECT customer_code, status FROM orders WHERE status = 'PENDING';如果有一个组合索引(status, customer_code)，这条语句只需要从索引叶子块读取数据即可，不需要回表。执行计划里会出现INDEX FAST FULL SCAN或INDEX RANGE SCAN，但步骤中没有“TABLE ACCESS BY INDEX ROWID”。
覆盖索引对统计类查询特别有效。考试中看到“查询列表是索引列的子集”这种描述，第一反应就应该联想到覆盖索引和减少回表。
4. 模拟第50题：从审题到执行计划走一遍
4.1 题目背景与常见选项
为了把上面的规则串起来，我根据备考中遇到的相似题型构造了一道模拟题。它的思路和真实考卷里的“索引优化判断”题非常接近。
假设 orders 表结构如下：
CREATE TABLE orders ( order_id NUMBER PRIMARY KEY, customer_code VARCHAR2(20), order_date DATE, status VARCHAR2(10), total_amount NUMBER(10,2) );表里数据量约 200 万行，customer_code 大约有 10 万个不同值，单客户平均 20 条订单。status 只有 5 种取值。total_amount 是订单金额。
题目问：下面关于索引优化的说法，哪一项最合理？
A. customer_code 的选择性足够高，在它上面创建 B 树索引后，所有带customer_code = '...'条件的查询都会明显变快。
B. status 列只有 5 种取值，为了提升SELECT COUNT(*) FROM orders WHERE status = 'COMPLETED'的性能，应该在 status 列上创建位图索引，并且用于订单系统的在线交易场景。
C. 如果建立了组合索引(order_date, customer_code)，执行WHERE order_date BETWEEN ... AND ... AND customer_code = '...'时，该组合索引一定不会生效，只能进行全表扫描。
D. 对 total_amount 列创建普通 B 树索引后，如果WHERE total_amount BETWEEN 1000 AND 5000的返回行数约占全表 80%，那么这条查询大概率不会使用该索引。
4.2 四个选项逐一拆解
选项 A 的陷阱在“所有”这两个字上。customer_code 的选择性确实较好，但并不能保证所有等值查询都走索引并且变快。如果某个客户的订单数量非常多，比如该客户有几十万条订单，那么WHERE customer_code = '热门客户'返回的行数占比很高，优化器很可能认为全表扫描更优。另外，如果查询的列很少，但分布不均匀，统计信息和直方图也会产生影响。一个“一定”就暴露了它的绝对化错误。
选项 B 是在考位图索引的适用场景。前面说过，位图索引适合低基数数据、查询模式固定且很少并发修改的场景。订单系统是典型的 OLTP 系统，插入和状态更新都很频繁，用位图索引会导致严重的锁竞争问题。正确做法要么用普通 B 树索引配合物化统计，要么根据业务特点考虑定期聚合并写入汇总表。B 选项把位图索引强行搬到在线交易场景，逻辑上是矛盾的。
选项 C 涉及组合索引顺序。如果查询里既有order_date的范围条件，又有customer_code的等值条件，而组合索引是(order_date, customer_code)，那么遇到order_date BETWEEN ...这个范围条件后，后面的 customer_code 确实无法继续精确过滤。但它不意味着“一定不会生效”。Oracle 可以选择索引跳跃扫描，或者优化器可能认为范围过滤后仍然有一定选择性，走索引范围扫描也有价值。C 的“一定”同样是过度结论。
选项 D 是正确的。当查询返回行数占全表比例达到 80% 时，选择性极低，走索引后需要大量回表随机读，成本远高于顺序的多块读全表扫描。优化器在这种场景下通常倾向于全表扫描。这个选项其实就是在考选择性对优化器决策的核心影响。
4.3 从模拟题引出真正需要掌握的改写方式
再来一个实际中很常见的优化场景。假设业务方频繁执行这条 SQL：
SELECT order_id, customer_code, status FROM orders WHERE customer_code = 'C10001' AND order_date >= DATE '2024-06-01';在没有任何索引时，只能对 200 万行全表扫描。我们要做的是创建合适的组合索引。根据前面的等值优先原则，customer_code 是等值条件，放在第一列；order_date 是范围条件，放在第二列；status 虽然不在 WHERE 中，但它出现在 SELECT 列表里，可以作为第三列加入索引，形成覆盖效果。
CREATE INDEX idx_orders_cod_date ON orders(customer_code, order_date, status);创建后执行计划应当变成：
SELECT STATEMENT TABLE ACCESS BY INDEX ROWID BATCHED ORDERS INDEX RANGE SCAN IDX_ORDERS_COD_DATE因为order_id列不在索引里，所以还需要回表取 order_id。如果只查询的列是 customer_code、order_date、status，回表可以直接省掉。这就是覆盖索引带来的收益。
这种从题目延伸到改写的过程，是复习时最值得做的事。考试选项往往不会直接告诉你“该建哪个索引”，而是问你“下面哪种方案更合理”。一旦你掌握了选择性、组合列序、覆盖索引这几个判断工具，选项对不对就一目了然。
5. 软件设计师结构化开发方法的核心考点
5.1 结构化分析：三件套工具不能混淆
结构化分析阶段的核心产物是数据流图、数据字典和加工说明。这三者功能不同，但考试中经常放在一起考。
数据流图回答的是“数据如何流动和加工”。它由外部的实体、加工、数据存储、数据流四种要素组成。实体是系统外部的人和系统，加工是对数据的处理动作，数据存储是静态存放数据的仓库，数据流是数据在环节之间的移动。很多新手画 DFD 时容易把“控制流”也画进来，比如“订单超过 1000 元触发审批”，这不是数据流，而是控制条件。DFD 里只表达数据成分，不表达控制逻辑。
数据字典则是对 DFD 中所有元素的定义。它对数据流、数据项、数据存储、加工做精确定义。比如“订单金额”的数据项定义可能是“订单的总金额，包含商品金额和优惠金额”。数据字典能消除歧义，是需求阶段各方沟通的基准。
加工说明也叫小说明，描述每个加工的具体处理逻辑。常用工具有结构化英语、判定表、判定树。结构化英语要求只使用顺序、选择、循环三种结构，避免使用自然语言中的歧义表达。判定表适合条件多、组合也多的场景，判定树则适合条件层级清晰的场景。
5.2 数据流图分层和平衡规则
数据流图不是一张图，而是按层展开的一组图。顶层是上下文图，也叫 0 层图或顶层图，它把整个系统看成一个加工，只画出系统与外部实体之间的数据流。再往下分解，把顶层加工拆成若干子加工，形成 0 层数据流图。如果某个子加工仍然复杂，可以继续分解，形成 1 层、2 层图。
有一个核心规则叫父图与子图平衡：子图在加工输入输出上的数据流，必须和父图中对应加工的数据流保持一致。比如父图中某个加工有一条输入数据流、一条输出数据流，子图里也必须有同样名称和方向的数据流，不能缺失，也不能无故增加外部实体或数据存储，除非它是内部存储且不与外部实体交互。
考试中经常出现这样的错误选项：“子图可以增加父图中不存在的数据流”“子图中的加工输入可以来自外部实体而不在父图中体现”。这些说法全部违反了平衡规则。理解 DFD 分层，本质上是在建立一种“逐步细化”的思维。这和数据库里从整体执行计划逐步拆到具体扫描步骤是异曲同工的思路。
5.3 内聚与耦合：模块设计的一把尺子
结构化设计的核心任务是把分析结果映射为软件结构，也就是模块划分。衡量模块质量的两个重要指标就是内聚和耦合。
内聚描述的是一个模块内部各成分之间联系的紧密程度。从低到高一般分为：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、信息内聚、功能内聚。最高的是功能内聚，指模块内所有元素共同完成一个功能，比如“计算订单总额”。考试喜欢让考生判断某个模块属于哪类内聚，或者选出哪个内聚程度最高。
耦合描述的是模块之间相互依赖的程度。从低到高分为：数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。数据耦合最弱，模块之间只传递简单数据；内容耦合最强，一个模块直接访问另一个模块的内部数据或代码，应该尽量避免。
我在理解这两组概念时，用了一个开发中的类比。团队协作时，每个人只做一件明确的子任务，并且只通过约定好的接口和他人传递必要参数，这是高内聚低耦合。如果两个人共享一个全局配置区，还互相操作对方的内部变量，一旦改了一个人的代码，另一个人就崩了，这就是高耦合。考试复习时，内聚从低到高的排序、耦合从低到高的排序，值得单独背一遍，因为这是高频送分题，但也是最容易被记混的考点。
5.4 变换分析：从 DFD 到软件结构
结构化设计中的变换分析，是把数据流图映射成软件结构的一种经典方法。它假设一个系统可以分成三段：输入流、变换中心、输出流。输入流负责把物理输入逐步转换成逻辑输入；变换中心对逻辑输入做核心加工；输出流再把逻辑输出逐步转换成物理输出。
变换分析的步骤通常是：先画出 DFD，找到整个系统中的主加工，也就是变换中心；把主加工上游的输入流和下游的输出流划出来；然后以变换中心为顶层模块，为输入流、输出流分别设计上层调用模块。这样得到的软件结构是清晰的层次结构。
另一种常见方法是事务分析。它适用于那种“接收一项事务，根据事务类型分派到不同处理模块”的场景，比如订单系统里，根据订单类型走不同处理流程。事务分析要先识别事务中心，也就是接收事务并根据类型分发的那个加工，然后为每个事务类型设计一个处理模块，最后再细化每个处理模块。
上午题经常问“以下哪个模块是变换中心”“事务分析的适用场景是什么”。下午题则更像是给一段需求描述，要求画 DFD，再要求根据 DFD 进行设计。掌握了变换分析和事务分析的区别，做这类案例题的答题节奏会快很多。
6. 备考中常见的错误与排查方法
6.1 索引优化题里高频出现的判断误区
我在刷 OCP 082 相关题目时，整理了几个反复出现的判断误区，都在解题时很容易踩进去。
第一个误区是“只要建索引就比全表扫描快”。这个判断忽略了索引回表的离散 I/O 成本。当返回行数占比高时，优化器倾向全表扫描，正确的判断工具是选择性。
第二个误区是“位图索引一定比 B 树索引好”。位图索引在低基数和高并发 DML 场景下反而会拖垮性能。考试里只要出现“OLTP”“高频插入更新”等词，位图索引基本可以排除。
第三个误区是“组合索引列顺序无所谓”。这完全错误。等值列要放在前面，范围列放在后面，顺序直接影响索引是否能被有效利用。
第四个误区是“在 WHERE 条件里对索引列计算不影响索引使用”。实际恰恰相反，函数包裹列会导致索引失效。
第五个误区是“索引越多越好”。索引会占用存储空间，也会增加 DML 维护成本。一张表上大量索引，插入、更新、删除的代价都会变高，这正是优化器做成本评估时的重要参考。
6.2 结构化方法题里防不胜防的概念陷阱
结构化方法相关的题目，常见的失分点也有几个。
DFD 方面，容易把“控制流”误当“数据流”，画了不该画的箭头。一个简单的判断方法：数据流必须携带数据名，比如“订单信息”，控制流只是触发信号，比如“开始/停止”。数据流图里不画控制流。
数据字典方面，容易遗漏数据项的精确定义，导致加工描述不完整。考试中如果让补全数据字典，要检查“名称、别名、类型、取值范围、含义”这几项是否都有定义。
内聚和耦合最容易记混淆。要记住一个关键记忆点：内聚看模块内部的紧密程度，耦合看模块之间的相互依赖。内部越紧越好，外部依赖越松越好。做题时先看问的是“模块内部”还是“模块之间”，再决定是选内聚还是耦合。
结构化程序设计方面，经常把“三种基本结构之外的结构也算结构化”，这个说法也是错的。顺序、选择、循环是三种基本控制结构，其他形式如无条件转移 goto 是被排斥的。
6.3 两科考点速查对照表
| 场景 | 判断要点 | 正确思路 |
|---|---|---|
| 建索引后查询变快 | 返回行数/表总行数 | 高选择性用索引，低选择性考虑全表扫描 |
| OLTP 低基数统计 | 位图索引适用性 | 位图索引适合低并发 DML 场景，OLTP 慎用 |
| 组合索引列序 | 等值 vs 范围条件 | 等值列放前，范围列放后 |
| WHERE 函数包裹列 | 列是否被加工 | 改写为列独立，或用函数索引 |
| 通配符 LIKE | 前导是否通配 | 前缀匹配可走索引，中间匹配难走索引 |
| DFD 父子图 | 子图数据流是否守恒 | 父子平衡，不得缺失和新增 |
| 模块设计 | 模块内部/模块之间 | 高内聚、低耦合优先 |
| 变换分析 | 加工的核心位置 | 先找中心加工，再分输入输出流 |
这张表是我临考前经常翻的东西。它不是万能，但能把最容易混的判断点压缩成一眼能看穿的记忆点。考前拿来过一遍，思路会清晰不少。
7. 实践中留下的体会和最后想说的话
说了这么多理论和题型的拆解，最后聊点实在的体会。
我在准备索引优化的那段时间，并没有只靠刷题，而是搭了一个本地数据库环境，手动创建了一张 100 万行级别的测试表，把各类场景一条一条跑过。比如建一个组合索引，分别用不同的列序做查询，观察执行计划的成本字段和实际耗时。比如把 B 树索引改成位图索引，再模拟并发插入和更新，看看锁等待的情况。在这种亲手做过实验之后，再回来看题目中的选项，会发现那些说法背后的依据其实是能从执行计划里直接“看”出来的，而不需要死记结论。
结构化开发方法的复习，我也采用了同样的方法。不是只背内聚和耦合的定义，而是把自己正在参与的一个小系统拿出来，从头画一遍数据流图，再照着结构化设计的原则划分模块。画第一版时肯定不完整，但对照平衡规则和模块设计原则后，第二版就能发现自己在需求理解上的漏洞。这个过程对准备软件设计师的下午题帮助特别大，因为案例分析题大多需要你从零梳理需求再画图，平常画得多了，考场上就不会慌。
两个考试放在一起复习，看起来时间被占用得更多，实际上反而提高了效率。索引优化的核心是“在约束下找最优结构”，结构化开发的核心是“通过分层和模块化降低复杂度”。每天交叉着看，遇到一个知识点时会下意识地从另一个学科的角度去验证，这种对比记忆比单独背书牢固不少。
最后再分享一个小技巧：无论 OCP 082 还是软件设计师，备考都不要只记正确答案词。把每个错误选项背后偏离了哪一条原理写出来，都记到笔记里。等考前集中过一遍，你会发现自己面对任何一组新选项都能快速识别套路。这个过程有点慢，但后劲儿特别足。
