一、目录
- 学习背景：为什么学视图与索引？
- 知识点 1：SQL 视图 —— 从 “复杂查询” 到 “一键复用”
- 知识点 2：SQL 索引 —— 让查询 “飞” 起来的优化工具
- 我的优秀项目：多场景视图 + 索引的联动实践
- 踩坑实录：从 “报错” 到 “精通” 的问题解决
- 学习总结：视图与索引的核心原则
- 互动投票：你最想优先掌握哪个技能？
- 提交成果物
二、学习背景：为什么学视图与索引？
在企业数据库中，视图是 “数据封装的利器”（避免重复写几百行关联查询），索引是 “性能优化的刚需”（当表有 10 万 + 数据时，无索引的查询可能卡半小时）。这两个技能是数据库操作从 “会用” 到 “用好” 的关键，也是面试高频考点。
三、知识点 1：SQL 视图 —— 从 “复杂查询” 到 “一键复用”
视图是虚拟表，基于 SQL 查询结果创建，本质是 “存储好的查询语句”，核心价值是简化操作、统一逻辑、权限控制。
（1）视图的 3 类核心场景
| 场景 | 作用 | 我的实践案例 |
|---|---|---|
| 多表关联查询 | 封装多表 JOIN 的复杂逻辑 | 武汉行政部员工视图（关联 5 张表） |
| 数据筛选 | 固化筛选条件，避免重复写 WHERE | 高薪员工视图（筛选薪资 > 15000） |
| 统计分析 | 封装分组、聚合逻辑 | 职位人数统计视图（按职位统计人数） |
2）深度实践：武汉行政部员工视图（多表关联）
知识点 1：SQL 视图的创建与使用
学习过程：视图是虚拟表，基于 SQL 查询结果创建，可简化复杂查询、封装逻辑。
（1）创建视图的语法
CREATE VIEW 视图名 AS SELECT 列1, 列2... FROM 表名 [JOIN 关联表 ON 关联条件] [WHERE 筛选条件];（2）实操案例：创建 “武汉行政部员工视图”
步骤：① 确定数据源：关联DMHR.EMPLOYEE（员工表）、DMHR.JOB（职位表）、DMHR.DEPARTMENT（部门表）、DMHR.LOCATION（地理位置表）、DMHR.CITY（城市表）；② 写创建语句：
CREATE VIEW DMHR.V_WUHAN_ADMIN_EMPLOYEES AS SELECT E.EMPLOYEE_ID, -- 员工ID E.EMPLOYEE_NAME, -- 员工姓名 E.EMAIL, -- 邮箱 D.DEPARTMENT_NAME, -- 部门名称 J.JOB_TITLE, -- 职位 C.CITY_NAME -- 城市 FROM DMHR.EMPLOYEE E JOIN DMHR.JOB J ON J.JOB_ID = E.JOB_ID JOIN DMHR.DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID JOIN DMHR.LOCATION L ON L.LOCATION_ID = D.LOCATION_ID JOIN DMHR.CITY C ON L.CITY_ID = C.CITY_ID WHERE D.DEPARTMENT_NAME = '行政部' AND C.CITY_NAME = '武汉';③ 查询视图（查看结果）
SELECT EMPLOYEE_ID AS 员工编号, EMPLOYEE_NAME AS 姓名, EMAIL AS 电子邮箱, DEPARTMENT_NAME AS 所属部门, JOB_TITLE AS 职务, CITY_NAME AS 办公城市 FROM DMHR.V_WUHAN_ADMIN_EMPLOYEES;图片：
![]()
3）实操案例：创建 “高薪员工视图”
步骤：① 确定数据源：仅DMHR.EMPLOYEE（员工表）；② 写创建语句（筛选薪资 > 15000 的员工）：
CREATE VIEW DMHR.V_HIGH_SALARY_EMPLOYEES AS SELECT EMPLOYEE_ID, EMPLOYEE_NAME, EMAIL, JOB_ID, SALARY FROM DMHR.EMPLOYEE WHERE SALARY > 15000;③ 查询视图：
SELECT EMPLOYEE_ID AS 员工编号, EMPLOYEE_NAME AS 员工姓名, EMAIL AS 电子邮箱, JOB_ID AS 职位ID, SALARY AS 薪资 FROM DMHR.V_HIGH_SALARY_EMPLOYEES;（4）实操案例：创建 “职位人数统计视图”
步骤：① 关联表：DMHR.EMPLOYEE（员工表）与DMHR.JOB（职位表）；② 写创建语句（按职位分组统计人数）：
CREATE VIEW DMHR.V_JOB_EMPLOYEE_COUNT AS SELECT J.JOB_TITLE, -- 职位名称 COUNT(E.EMPLOYEE_ID) AS EMPLOYEE_COUNT -- 人数 FROM DMHR.EMPLOYEE E JOIN DMHR.JOB J ON E.JOB_ID = J.JOB_ID GROUP BY J.JOB_TITLE ORDER BY J.JOB_TITLE;③ 查询视图：
SELECT JOB_TITLE AS 职位名称, EMPLOYEE_COUNT AS 人员数量 FROM DMHR.V_JOB_EMPLOYEE_COUNT;三、知识点 2：SQL 索引的创建与优化
学习过程：索引是数据库优化工具，能加速查询（类似书籍目录），但会增加写入 / 更新的开销。
索引的 2 类常用类型
| 索引类型 | 适用场景 | 我的实践案例 |
|---|---|---|
| B 树索引 | 普通等值 / 范围查询（如 WHERE 列 = 值、列 > 值） | 员工表 DEPARTMENT_ID 的 B 树索引 |
| 位图索引 | 列值重复度高的场景（如性别、部门 ID） | 员工表 DEPARTMENT_ID 的位图索引 |
（1）创建索引的语法
CREATE [UNIQUE] INDEX 索引名 ON 表名(列1, 列2...);（2）实操案例：为员工表的DEPARTMENT_ID创建索引
步骤：① 确定优化场景：频繁按DEPARTMENT_ID查询员工，需加速；② 写创建语句：
CREATE BITMAP INDEX DMHR.IDX_EMPDEPT ON DMHR.EMPLOYEE(DEPARTMENT_ID);③ 验证效果：查询部门 ID=104 的员工，索引会加速检索：
SELECT EMPLOYEE_ID, EMPLOYEE_NAME, PHONE_NUM, EMAIL FROM DMHR.EMPLOYEE WHERE DEPARTMENT_ID = 104;（3）索引的 “避坑指南”
- ❌ 不要给 “频繁更新的列” 建索引（比如员工的 “当前状态”，每次更新都会重建索引，开销大）；
- ❌ 不要给 “数据量小的表” 建索引（表只有 10 行，全表扫描比查索引更快）；
- ✅ 优先给 “查询条件中的列” 建索引（比如 WHERE、JOIN ON 后的列）。
四、我的优秀练习项目
项目：统计各职位的员工人数并排序我独立完成了 “职位人数统计视图” 的创建，核心代码（含分组、排序）：
CREATE VIEW DMHR.V_JOB_EMPLOYEE_COUNT AS SELECT J.JOB_TITLE, COUNT(E.EMPLOYEE_ID) AS EMPLOYEE_COUNT FROM DMHR.EMPLOYEE E JOIN DMHR.JOB J ON E.JOB_ID = J.JOB_ID GROUP BY J.JOB_TITLE ORDER BY J.JOB_TITLE;通过视图封装后，仅需简单查询就能得到清晰的统计结果，简化了重复操作。
五、学习问题与解决
| 遇到的问题 | 报错信息 | 解决过程 | 经验总结 |
|---|---|---|---|
| 创建视图时权限不足 | ORA-01031: insufficient privileges | 联系 DBA 申请CREATE VIEW权限，同时学习视图的权限控制（可以给其他用户 “查询视图” 的权限，而不暴露原表） | 数据库操作前先确认权限，视图是 “权限隔离” 的好工具 |
| 多表关联出现笛卡尔积 | 结果行数是原表行数的乘积 | 检查 JOIN 条件：原来漏写了DMHR.LOCATION和DMHR.CITY的关联条件，补充ON L.CITY_ID = C.CITY_ID后解决 | 多表关联时，每个表都要有对应的 JOIN 条件，避免 “无关联的表放在 FROM 后” |
| 索引创建后查询没加速 | EXPLAIN显示还是全表扫描 | 发现查询条件写的是DEPT_ID（别名写错了，实际列是DEPARTMENT_ID），修正列名后命中索引 | 索引列要和查询条件的列完全一致，别名不影响索引匹配 |
六、总结
- 视图的核心价值：封装复杂查询、简化复用、统一数据逻辑；
- 索引的核心价值：加速查询，但需权衡写入性能（避免过度创建）；
- 实践技巧：创建视图前先测试基础
SELECT语句，确保结果正确；创建索引后用EXPLAIN验证生效情况。
七、学习投票
你觉得哪个知识点更实用？（投票）
