一、目录
- 学习背景:为什么学视图与索引?
- 知识点 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验证生效情况。
七、学习投票
你觉得哪个知识点更实用?(投票)