企业官网建设流程全解析

一、 SQL 语言四大分类 (Data Language Classification)

银行笔试常以“下列哪个命令属于 DDL/DCL？”的形式进行概念考查。必须熟练掌握下表的归类：

二、 数据库高级特性：视图与索引

1. 视图 (View) — 虚拟表

• 定义：视图是一张虚拟表，其自身并不在磁盘上存储真实数据。它仅在系统字典中保存一段SELECT语句的定义，数据在运行时动态生成。

• 核心作用（银行应用场景）：

  • 安全性（字段隔离）：隐藏敏感数据。例如，前台柜员只能访问包含“客户姓名、尾号、余额”的视图，而屏蔽包含“密码哈希、身份证号”的原表字段。

  • 简化查询：将涉及十几张表、上百行关联条件的复杂JOIN语句封装为视图，后续开发只需SELECT * FROM view_name。

2. 索引 (Index) — 数据目录

• 定义：索引是一种排好序的高效获取数据的数据结构（在 InnoDB 中主要是B+ 树）。

• 代价：空间换时间。

  • 优势：大幅提升数据检索（SELECT）和排序（ORDER BY）的性能。

  • 劣势：降低了写（INSERT / UPDATE / DELETE）的效率，因为每次数据变动都需要动态调整 B+ 树结构；同时会占用额外的磁盘空间。

三、 多表连接查询 (SQL JOINS)

多表联查是银行笔试中 SQL 编写题和结果集判断题的必考点。

1. 内连接 (INNER JOIN)

• 机制：只返回两张表中完全满足连接条件的交集记录。

• 特点：如果左表的某条记录在右表中找不到匹配项（或反之），该记录直接被过滤。

2. 左外连接 (LEFT JOIN / LEFT OUTER JOIN)

• 机制：以左表为基准，完整返回左表的所有记录。

• 特点：如果右表没有匹配的记录，则结果集中属于右表的字段全部填充为NULL。

• 银行常考场景：查询“开户后从未办理过网银业务的客户列表”（WHERE 右表.id IS NULL）。

3. 右外连接 (RIGHT JOIN)

• 机制：与左外连接对称，以右表为基准，完整返回右表所有记录，左表未匹配处补NULL。

4. 全外连接 (FULL JOIN)

• 机制：返回左右两表的所有记录。匹配成功的合并同行，匹配失败的单侧补NULL。

• 注：MySQL 原生不支持FULL JOIN，笔试中若需实现，通常采用LEFT JOIN ... UNION ... RIGHT JOIN的组合拳。

四、 SQL 性能优化：索引失效的“六大毒瘤”

在海量金融交易场景下，SQL 优化直接决定系统生死。笔试最爱考“下列哪个操作会导致全表扫描（索引失效）”。

⚠️金科玉律：只要对索引列进行了“加工”或“破坏了其物理顺序”，索引即告失效！

1. 违背最左前缀法则

• 场景：建立了复合索引(a, b, c)。

• 失效：查询条件中跳过了前缀。如WHERE b = 1或WHERE c = 2（索引完全失效）；WHERE a = 1 AND c = 2（仅a走索引，c不走）。

2. 在索引列上进行运算或调用函数

• ❌错误（失效）：WHERE YEAR(create_time) = 2026;或WHERE age - 1 = 29;

• +正确（有效）：WHERE create_time >= '2026-01-01' AND create_time <= '2026-12-31';

3. 隐式类型转换（类型不匹配）

• 场景：银行卡号card_no字段在设计时为字符串类型（VARCHAR）。

• ❌错误（失效）：WHERE card_no = 62220212345678;（传入了数值型，数据库底层会自动调用函数对列进行转换）

• +正确（有效）：WHERE card_no = '62220212345678';

4. 模糊查询中通配符%开头

• ❌错误（失效）：WHERE name LIKE '%明';或WHERE name LIKE '%明%';（无法利用 B+ 树的有序性，必走全表扫描）

• +正确（有效）：WHERE name LIKE '张%';（属于范围查询，索引有效）

5. 在 WHERE 子句中使用OR连接未索引列

• 场景：age有索引，但phone没有索引。

• ❌错误（失效）：WHERE age = 18 OR phone = '13800000000';（由于phone必须全表扫描，引擎会直接放弃age的索引，整体变更为全表扫描）

6. 使用不等于判断 (!=或<>)

• ❌错误（一般失效）：WHERE status != 'CLOSED';（不等于操作符会让优化器大概率认为扫描全表的代价比走索引更低，从而放弃索引）