Mysql高级（索引，视图）

企业开发 2022-04-28 11:27:12 阅读次数: 0

Mysql高级（索引，视图）

索引

定义

索引（index）是帮助MySQL高效获取数据的数据结构（有序）。在数据之外，数据库系统还维护者满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

在这里插入图片描述
左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找快速获取到相应数据。

一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储在磁盘上。索引是数据库中用来提高性能的最常用的工具。

为数据库的某个字段创建索引，相当于是为这个字段的内容创建了一个目录，通过这个目录可以快速实现数据的定位，也就是通过索引能够快速找到某条数据所在磁盘的位置

索引优势劣势

优势

1） 类似于书籍的目录索引，提高数据检索的效率，降低数据库的IO成本。

2） 通过索引列对数据进行排序，降低数据排序的成本，降低CPU的消耗。

劣势

1） 实际上索引也是一张表，该表中保存了主键与索引字段，并指向实体类的记录，所以索引列也是要占用空间的。

2） 虽然索引大大提高了查询效率，同时却也降低更新表的速度，如对表进行INSERT、UPDATE、DELETE。因为更新表时，MySQL 不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息。

索引存放位置

  • InnoDB存储引擎的表：将索引和数据放在同一个文件里面: *.idb
  • MyISAM存储引擎的表: 索引和数据分开两个文件夹来存储：
    • 索引: *.MYI
    • 数据 MYD

索引结构

索引是在MySQL的存储引擎层中实现的，而不是在服务器层实现的。所以每种存储引擎的索引都不一定完全相同，也不是所有的存储引擎都支持所有的索引类型的。MySQL目前提供了以下4种索引：

  • BTREE 索引 ： 最常见的索引类型，大部分索引都支持 B 树索引。
  • HASH 索引：只有Memory引擎支持 ， 使用场景简单 。
  • R-tree 索引（空间索引）：空间索引是MyISAM引擎的一个特殊索引类型，主要用于地理空间数据类型，通常使用较少，不做特别介绍。
  • Full-text （全文索引） ：全文索引也是MyISAM的一个特殊索引类型，主要用于全文索引，InnoDB从Mysql5.6版本开始支持全文索引。
MyISAM、InnoDB、Memory三种存储引擎对各种索引类型的支持
索引 InnoDB引擎 MyISAM引擎 Memory引擎
BTREE索引 支持 支持 支持
HASH 索引 不支持 不支持 支持
R-tree 索引 不支持 支持 不支持
Full-text 5.6版本之后支持 支持 不支持

我们平常所说的索引，如果没有特别指明，都是指B+树（多路搜索树，并不一定是二叉的）结构组织的索引。其中聚集索引、复合索引、前缀索引、唯一索引默认都是使用 B+tree 索引，统称为 索引

BTREE 结构

Tree又叫多路平衡搜索树，一颗m叉的BTree特性如下：

  • 树中每个节点最多包含m个孩子。
  • 除根节点与叶子节点外，每个节点至少有[ceil(m/2)]个孩子。
  • 若根节点不是叶子节点，则至少有两个孩子。
  • 所有的叶子节点都在同一层。
  • 每个非叶子节点由n个key与n+1个指针组成，其中[ceil(m/2)-1] <= n <= m-1

以5叉BTree为例，key的数量：公式推导[ceil(m/2)-1] <= n <= m-1。所以 2 <= n <=4 。当n>4时，中间节点分裂到父节点，两边节点分裂。

插入 C N G A H E K Q M F W L T Z D P R X Y S 数据为例。

演变过程如下：

插入前4个字母 C N G A

在这里插入图片描述

插入H，n>4，中间元素G字母向上分裂到新的节点

在这里插入图片描述

插入E，K，Q不需要分裂

在这里插入图片描述

插入M，中间元素M字母向上分裂到父节点G

在这里插入图片描述

插入F，W，L，T不需要分裂

在这里插入图片描述

插入Z，中间元素T向上分裂到父节点中

在这里插入图片描述

插入D，中间元素D向上分裂到父节点中。然后插入P，R，X，Y不需要分裂

在这里插入图片描述

最后插入S，NPQR节点n>5，中间节点Q向上分裂，但分裂后父节点DGMT的n>5，中间节点M向上分裂

在这里插入图片描述
到此，该BTREE树就已经构建完成了， BTREE树 和 二叉树 相比， 查询数据的效率更高， 因为对于相同的数据量来说，BTREE的层级结构比二叉树小，因此搜索速度快。

B+TREE 结构

B+Tree为BTree的变种，B+Tree与BTree的区别为：

1). n叉B+Tree最多含有n个key，而BTree最多含有n-1个key。

2). B+Tree的叶子节点保存所有的key信息，依key大小顺序排列。

3). 所有的非叶子节点都可以看作是key的索引部分。

在这里插入图片描述
由于B+Tree只有叶子节点保存key信息，查询任何key都要从root走到叶子。所以B+Tree的查询效率更加稳定。

MySQL中的B+Tree

MySql索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的B+Tree，提高区间访问的性能（有利于查找范围值）。

在这里插入图片描述

为什么InnoDB存储引擎选择使用B+tree索引结构?

  1. 相对于二叉树，层级更少，搜索效率高；
  2. 对于B-tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低；
  3. 相对Hash索引，B+tree支持范围匹配及排序操作；

索引分类

主键索引 ：主键自带的索引效果

普通索引 ：为普通列创建的索引，一个表可以有多个普通索引

唯一索引 ：索引列的值必须唯一，但允许有空值，性能比普通索引好

复合索引 ：即一个索引包含多个列，一次性为表中的多个字段一起创建索引，（建议不要超过5个列）

全文索引 ： 进行查询的时候，数据源可能来自于不同的字段或者不同的表，MyISAM支持全文索引，在实际中，会使用ElasticSearch

聚集索引&二级索引

在InnoDB存储引擎中，根据索引的存储形式，又可以分为以下两种：

分类 含义 特点
聚集索引(ClusteredIndex) 将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据 必须有,而且只有一个
二级索引(SecondaryIndex) 将数据与索引分开存储，索引结构的叶子节点关联的是对应的主键 可以存在多个

聚集索引选取规则

  • 如果存在主键，主键索引就是聚集索引。
  • 如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引。
  • 如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引

在这里插入图片描述
在这里插入图片描述
①. 由于是根据name字段进行查询，所以先根据name='Arm’到name字段的二级索引中进行匹配查找。但是在二级索引中只能查找到 Arm 对应的主键值 10。
②. 由于查询返回的数据是*，所以此时，还需要根据主键值10，到聚集索引中查找10对应的记录，最终找到10对应的行row。
③. 最终拿到这一行的数据，直接返回即可。

回表查询： 这种先到二级索引中查找数据，找到主键值，然后再到聚集索引中根据主键值，获取数据的方式，就称之为回表查询。

思考题

以下两条SQL语句，那个执行效率高? 为什么?
A. select * from user where id = 10 ;
B. select * from user where name = ‘Arm’ ;
备注: id为主键，name字段创建的有索引；

A 语句的执行性能要高于B 语句。
因为A语句直接走聚集索引，直接返回数据。 而B语句需要先查询name字段的二级索引，然后再查询聚集索引，也就是需要进行回表查询。

InnoDB主键索引的B+tree高度为多高呢?

假设:
一行数据大小为1k，一页中可以存储16行这样的数据。InnoDB的指针占用6个字节的空间，主键即使为bigint，占用字节数为8。

高度为2：

n * 8 + (n + 1) * 6 = 16*1024 , 算出n约为 1170
1171* 16 = 18736

也就是说，如果树的高度为2，则可以存储 18000 多条记录。
高度为3：

1171 * 1171 * 16 = 21939856

也就是说，如果树的高度为3，则可以存储 2200w 左右的记录。

索引语法

CREATE TABLE `city` (
  `city_id` int(11) NOT NULL AUTO_INCREMENT,
  `city_name` varchar(50) NOT NULL,
  `country_id` int(11) NOT NULL,
  PRIMARY KEY (`city_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `country` (
  `country_id` int(11) NOT NULL AUTO_INCREMENT,
  `country_name` varchar(100) NOT NULL,
  PRIMARY KEY (`country_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


insert into `city` (`city_id`, `city_name`, `country_id`) values(1,'西安',1);
insert into `city` (`city_id`, `city_name`, `country_id`) values(2,'NewYork',2);
insert into `city` (`city_id`, `city_name`, `country_id`) values(3,'北京',1);
insert into `city` (`city_id`, `city_name`, `country_id`) values(4,'上海',1);

insert into `country` (`country_id`, `country_name`) values(1,'China');
insert into `country` (`country_id`, `country_name`) values(2,'America');
insert into `country` (`country_id`, `country_name`) values(3,'Japan');
insert into `country` (`country_id`, `country_name`) values(4,'UK');

创建索引

语法 ：

# 普通索引
create index 索引名称 on 表名(列名);

# 唯一索引
create UNIQUE index 索引名称 on 表名(列名);

# 创建复合索引
create index 索引名称 on 表名(列1，列2，列3);

示例 ： 为city表中的city_name字段创建索引 ；

# 普通索引
create index idx_city_name on city(city_name);

# 唯一索引
create UNIQUE index idx_city_name on city(city_name)

# 复合索引
create index idx_city_name on city(city_name,country_id);

查看索引

语法：

show index  from  table_name;

示例：查看city表中的索引信息；

show INDEX from city

在这里插入图片描述

删除索引

语法 ：

DROP  INDEX  index_name  ON  tbl_name;

示例 ： 想要删除city表上的索引idx_city_name，可以操作如下：

drop index idx_city_name on city

ALTER命令

1). alter  table  tb_name  add  primary  key(column_list); 

	该语句添加一个主键，这意味着索引值必须是唯一的，且不能为NULL
	
2). alter  table  tb_name  add  unique index_name(column_list);
	
	这条语句创建索引的值必须是唯一的（除了NULL外，NULL可能会出现多次）
	
3). alter  table  tb_name  add  index index_name(column_list);

	添加普通索引， 索引值可以出现多次。
	
4). alter  table  tb_name  add  fulltext  index_name(column_list);
	
	该语句指定了索引为FULLTEXT， 用于全文索引

最左前缀法则

如果索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始，
并且不跳过索引中的列。如果跳跃某一列，索引将会部分失效(后面的字段索引失效)。

以 tb_user 表为例，我们先来查看一下之前 tb_user 表所创建的索引。

在这里插入图片描述
在 tb_user 表中，有一个联合索引，这个联合索引涉及到三个字段，顺序分别为：profession，age，status。

对于最左前缀法则指的是，查询时，最左变的列，也就是profession必须存在，否则索引全部失效。而且中间不能跳过某一列，否则该列后面的字段索引将失效。

explain select * from tb_user where profession = '软件工程' and age = 31 and status= '0';

在这里插入图片描述

explain select * from tb_user where profession = '软件工程' and age = 31;

在这里插入图片描述

explain select * from tb_user where profession = '软件工程';

在这里插入图片描述
以上的这三组测试中，我们发现只要联合索引最左边的字段 profession存在，索引就会生效，只不过索引的长度不同。 而且由以上三组测试，我们也可以推测出profession字段索引长度为47、age字段索引长度为2、status字段索引长度为5。

explain select * from tb_user where age = 31 and status = '0';

在这里插入图片描述

explain select * from tb_user where status = '0';

在这里插入图片描述
而通过上面的这两组测试，我们也可以看到索引并未生效，原因是因为不满足最左前缀法则，联合索引
最左边的列profession不存在。

explain select * from tb_user where profession = '软件工程' and status = '0';

在这里插入图片描述
上述的SQL查询时，存在profession字段，最左边的列是存在的，索引满足最左前缀法则的基本条件。但是查询时，跳过了age这个列，所以后面的列索引是不会使用的，也就是索引部分生效，所以索引的长度就是47。

 explain select * from tb_user where age = 31 and status = '0' and profession = '软件工程'；

在这里插入图片描述
可以看到，是完全满足最左前缀法则的，索引长度54，联合索引是生效的。

注意 ： 最左前缀法则中指的最左边的列，是指在查询时，联合索引的最左边的字段(即是第一个字段)必须存在，与我们编写SQL时，条件编写的先后顺序无关。

索引失效

范围查询

联合索引中，出现范围查询(>,<)，范围查询右侧的列索引失效。

explain select * from tb_user where profession = '软件工程' and age > 30 and status= '0';

在这里插入图片描述
当范围查询使用> 或 < 时，走联合索引了，但是索引的长度为49，就说明范围查询右边的status字段是没有走索引的

explain select * from tb_user where profession = '软件工程' and age >= 30 and status = '0';

在这里插入图片描述
当范围查询使用>= 或 <= 时，走联合索引了，但是索引的长度为54，就说明所有的字段都是走索引的。

所以，在业务允许的情况下，尽可能的使用类似于 >= 或 <= 这类的范围查询，而避免使用 > 或 <

索引列运算

不要在索引列上进行运算操作， 索引将失效

当根据phone字段进行等值匹配查询时, 索引生效。

explain select * from tb_user where phone = '17799990015';

在这里插入图片描述
当根据phone字段进行函数运算操作之后，索引失效。

explain select * from tb_user where substring(phone,10,2) = '15';

在这里插入图片描述

字符串不加引号

字符串类型字段使用时，不加引号，索引将失效。
接下来，我们通过两组示例，来看看对于字符串类型的字段，加单引号与不加单引号的区别：

explain select * from tb_user where profession = '软件工程' and age = 31 and status= '0';
explain select * from tb_user where profession = '软件工程' and age = 31 and status= 0;

在这里插入图片描述

explain select * from tb_user where phone = '17799990015';
explain select * from tb_user where phone = 17799990015;

在这里插入图片描述

如果字符串不加单引号，对于查询结果，没什么影响，但是数据库存在隐式类型转换，索引将失效。

模糊查询

如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。

explain select * from tb_user where profession like '软件%';
explain select * from tb_user where profession like '%工程';
explain select * from tb_user where profession like '%工%';

在这里插入图片描述
在like模糊查询中，在关键字后面加%，索引可以生效。而如果在关键字前面加了%，索引将会失效。

or连接条件

用or分割开的条件， 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会
被用到。

explain select * from tb_user where id = 10 or age = 23;
explain select * from tb_user where phone = '17799990017' or age = 23;

在这里插入图片描述
由于age没有索引，所以即使id、phone有索引，索引也会失效。所以需要针对于age也要建立索引。然后，我们可以对age字段建立索引。

create index idx_user_age on tb_user(age);

建立了索引之后，我们再次执行上述的SQL语句，看看前后执行计划的变化。
在这里插入图片描述

当or连接的条件，左右两侧字段都有索引时，索引才会生效

数据分布影响

如果MySQL评估使用索引比全表更慢，则不使用索引。

select * from tb_user where phone >= '17799990005';
select * from tb_user where phone >= '17799990015';

在这里插入图片描述

相同的SQL语句，只是传入的字段值不同，最终的执行计划也完全不一样，这是为什么呢？

就是因为MySQL在查询时，会评估使用索引的效率与走全表扫描的效率，如果走全表扫描更快，则放弃
索引，走全表扫描。 因为索引是用来索引少量数据的，如果通过索引查询返回大批量的数据，则还不
如走全表扫描来的快，此时索引就会失效。

explain select * from tb_user where profession is null;
explain select * from tb_user where profession is not null;

在这里插入图片描述
接下来，我们做一个操作将profession字段值全部更新为null。
在这里插入图片描述
再次执行上述的两条SQL，查看SQL语句的执行计划。
在这里插入图片描述
最终我们看到，一模一样的SQL语句，先后执行了两次，结果查询计划是不一样的，为什么会出现这种
现象，这是和数据库的数据分布有关系。查询时MySQL会评估，走索引快，还是全表扫描快，如果全表
扫描更快，则放弃索引走全表扫描。 因此，is null 、is not null是否走索引，得具体情况具体分析，并不是固定的。

SQL提示

explain select * from tb_user where profession = '软件工程';

在这里插入图片描述查询走了联合索引。
执行SQL，创建profession的单列索引：

create index idx_user_pro ontb_user(profession);

在这里插入图片描述
创建单列索引后，再次执行SQL语句，查看执行计划，看看到底走哪个索引。
在这里插入图片描述
测试结果，我们可以看到，possible_keys中 idx_user_pro_age_sta,idx_user_pro 这两个索引都可能用到，最终MySQL选择了idx_user_pro_age_sta索引。这是MySQL自动选择的结果。

SQL提示，是优化数据库的一个重要手段，简单来说，就是在SQL语句中加入一些人为的提示来达到优
化操作的目的。

use index

建议MySQL使用哪一个索引完成此次查询（仅仅是建议，mysql内部还会再次进行评估）

explain select * from tb_user use index(idx_user_pro) where profession = '软件工程';

在这里插入图片描述

ignore index

忽略指定的索引。

explain select * from tb_user ignore index(idx_user_pro) where profession = '软件工程';

在这里插入图片描述

force index

强制使用索引

explain select * from tb_user force index(idx_user_pro) where profession = '软件工程';

在这里插入图片描述

覆盖索引

覆盖索引是指 查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到

explain select id, profession from tb_user where profession = '软件工程' and age =31 and status = '0' ;

explain select id,profession,age, status from tb_user where profession = '软件工程' and age = 31 and status = '0' ;

explain select id,profession,age, status, name from tb_user where profession = '软件工程' and age = 31 and status = '0' ;

explain select * from tb_user where profession = '软件工程' and age = 31 and status= '0';

在这里插入图片描述
从上述的执行计划我们可以看到，这四条SQL语句的执行计划前面所有的指标都是一样的，看不出来差
异。但是此时，我们主要关注的是后面的Extra，前面两天SQL的结果为 Using where; UsingIndex ; 而后面两条SQL的结果为: Using index condition 。

Extra 含义
Using where; UsingIndex 查找使用了索引，但是需要的数据都在索引列中能找到，所以不需要回表查询数据
Using indexcondition 查找使用了索引，但是需要回表查询数据

因为，在tb_user表中有一个联合索引 idx_user_pro_age_sta，该索引关联了三个字段profession、age、status，而这个索引也是一个二级索引，所以叶子节点下面挂的是这一行的主键id。 所以当我们查询返回的数据在 id、profession、age、status 之中，则直接走二级索引直接返回数据了。 如果超出这个范围，就需要拿到主键id，再去扫描聚集索引，再获取额外的数据了，这个过程就是回表。 而我们如果一直使用select * 查询返回所有字段值，很容易就会造成回表查询（除非是根据主键查询，此时只会扫描聚集索引）。
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

思考题：

一张表, 有四个字段(id, username, password, status), 由于数据量大, 需要对以下SQL语句进行优化, 该如何进行才是最优方案:
select id,username,password from tb_user where username =‘itcast’;

答案: 针对于 username, password建立联合索引, sql为: create indexidx_user_name_pass on tb_user(username,password);这样可以避免上述的SQL语句，在查询的过程中，出现回表查询。

前缀索引

当字段类型为字符串（varchar，text，longtext等）时，有时候需要索引很长的字符串，这会让索引变得很大，查询时，浪费大量的磁盘IO， 影响查询效率。此时可以只将字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率。

语法

create index idx_xxxx on table_name(column(n)) ;

为tb_user表的email字段，建立长度为5的前缀索引。

create index idx_email_5 on tb_user(email(5));

在这里插入图片描述

前缀长度

可以根据索引的选择性来决定，而选择性是指不重复的索引值（基数）和数据表的记录总数的比值，
索引选择性越高则查询效率越高， 唯一索引的选择性是1，这是最好的索引选择性，性能也是最好的。

select count(distinct email) / count(*) from tb_user ;
select count(distinct substring(email,1,5)) / count(*) from tb_user ;

前缀索引的查询流程

在这里插入图片描述

单列索引与联合索引

单列索引：即一个索引只包含单个列。
联合索引：即一个索引包含了多个列。
在这里插入图片描述
在查询出来的索引中，既有单列索引，又有联合索引

接下来，我们来执行一条SQL语句，看看其执行计划：

在这里插入图片描述
通过上述执行计划我们可以看出来，在and连接的两个字段 phone、name上都是有单列索引的，但是最终mysql只会选择一个索引，也就是说，只能走一个字段的索引，此时是会回表查询的。

紧接着，我们再来创建一个phone和name字段的联合索引来查询一下执行计划

create unique index idx_user_phone_name on tb_user(phone,name);

此时，查询时，就走了联合索引，而在联合索引中包含 phone、name的信息，在叶子节点下挂的是对应的主键id，所以查询是无需回表查询的。

在业务场景中，如果存在多个查询条件，考虑针对于查询字段建立索引时，建议建立联合索引，而非单列索引。

在这里插入图片描述

索引设计原则

  1. 针对于数据量较大，且查询比较频繁的表建立索引。
  2. 针对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引。
  3. 尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。
  4. 如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引。
  5. 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率。
  6. 要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率。
  7. 如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时，它可以更好地确定哪个索引最有效地用于查询。

视图

视图（View）是一种虚拟存在的表。视图中的数据并不在数据库中实际存在，行和列数据来自定义视图的查询中使用的表，并且是在使用视图时动态生成的。
通俗的讲，视图只保存了查询的SQL逻辑，不保存查询结果。所以我们在创建视图的时候，主要的工作就落在创建这条SQL查询语句上。

视图作用

视图不仅可以简化用户对数据的理解，也可以简化他们的操作。那些被经常使用的查询可以被定义为视图，从而使得用户不必为以后的操作每次指定全部的条件。

数据库可以授权，但不能授权到数据库特定行和特定的列上。通过视图用户只能查询和修改他们所能见到的数据

视图可帮助用户屏蔽真实表结构变化带来的影响。

语法

创建

CREATE [OR REPLACE] VIEW 视图名称[(列名列表)] AS SELECT语句 [ WITH [
CASCADED | LOCAL ] CHECK OPTION ]

-- 创建视图
create or replace view stu_v_1 as select id,name from student where id <= 10;

查询

查看创建视图语句：SHOW CREATE VIEW 视图名称;

查看视图数据：SELECT * FROM 视图名称 ...... ;

-- 查询视图
show create view stu_v_1;

select * from stu_v_1;
select * from stu_v_1 where id < 3;

修改

方式一：CREATE [OR REPLACE] VIEW 视图名称[(列名列表)] AS SELECT语句 [ 
WITH[ CASCADED | LOCAL ] CHECK OPTION ]

方式二：ALTER VIEW 视图名称[(列名列表)] AS SELECT语句 [ WITH [ CASCADED 
|LOCAL ] CHECK OPTION ]

-- 修改视图
create or replace view stu_v_1 as select id,name,no from student where id <= 10;

alter view stu_v_1 as select id,name from student where id <= 10;

删除

DROP VIEW [IF EXISTS] 视图名称 [,视图名称] ...

-- 删除视图
drop view if exists stu_v_1;

视图应该如何创建、查询、修改、删除，那么我们能不能通过视图来插入、更新数据呢

create or replace view stu_v_1 as select id,name from student 
where id <= 10 ;

select * from stu_v_1;

insert into stu_v_1 values(6,'Tom');
insert into stu_v_1 values(17,'Tom22');

执行上述的SQL，我们会发现，id为6和17的数据都是可以成功插入的。 但是我们执行查询，查询出来的数据，却没有id为17的记录。
因为我们在创建视图的时候，指定的条件为 id<=10, id为17的数据，是不符合条件的，所以没有查询出来，但是这条数据确实是已经成功的插入到了基表中。

检查选项

当使用WITH CHECK OPTION子句创建视图时，MySQL会通过视图检查正在更改的每个行，例如插入，更新，删除，以使其符合视图的定义。 MySQL允许基于另一个视图创建视图，它还会检查依赖视图中的规则以保持一致性。为了确定检查的范围，mysql提供了两个选项： CASCADED 和 LOCAL
，默认值为 CASCADED 。

CASCADED级联

在这里插入图片描述

LOCAL本地在这里插入图片描述

在这里插入图片描述

视图的更新

要使视图可更新，视图中的行与基础表中的行之间必须存在一对一的关系。如果视图包含以下任何一项，则该视图不可更新：

  • 聚合函数或窗口函数（SUM()、 MIN()、 MAX()、 COUNT()等）
  • DISTINCT
  • GROUP BY
  • HAVING
  • UNION 或者 UNION ALL

示例演示

create view stu_v_count as select count(*) from student;

上述的视图中，就只有一个单行单列的数据，如果我们对这个视图进行更新或插入的，将会报错。

insert into stu_v_count values(10);

案例

  1. 为了保证数据库表的安全性，开发人员在操作tb_user表时，只能看到的用户的基本字段，屏蔽手机号和邮箱两个字段。
create view tb_user_view as select 
id,name,profession,age,gender,status,createtime
from tb_user;

select * from tb_user_view;
  1. 查询每个学生所选修的课程（三张表联查），这个功能在很多的业务中都有使用到，为了简化操作，定义一个视图。
create view tb_stu_course_view as select s.name student_name , 
s.no student_no ,c.name course_name from student s,
 student_course sc , course c 
where s.id =sc.studentid and sc.courseid = c.id;

select * from tb_stu_course_view;

猜你喜欢

转载自blog.csdn.net/qq_44866153/article/details/121093552
今日推荐
开放签电子签章：停止新增，优化体验，前进更进（五一假期前工作）
开源日报 | 中学生开源前端动画引擎；全球首个Llama3 8B中文版开源模型；联想电脑恐出局；Linus讽刺AI炒作
“百模大战”必有一战 | 2024中国“百模大战”竞争格局分析
最强开源大模型 Llama 3 上架 Gitee AI
虽然老乡鸡开源的不是代码，但背后的原因却让人很暖心
富文本编辑器 Quill 2.0 重磅发布，特性、可靠性与开发者体验大幅提升
周排行
SVN同步出现问题
解决 nginx 出现 413 Request Entity Too Large 的问题
第一节 区块链服务BaaS的总体架构以及基本模块设计的一种方案
ITeye 2013年度盘点——社区赠书书单
IDEA / git 和github 的新手使用教程 史上最简单的 IntelliJ IDEA 教程 史上最简单的 GitHub 教程
测试工程方法：测试用例设计综合策略
Spark优化(三)：对多次使用的RDD进行持久化
使用STM32 ST-LINK Utility 设置读保护后不能运行
exgcd 解同余方程ax=b(%n)
Android使用脚本进行多渠道打包
每日归档
更多
2024-04-22(39)
2024-04-21(0)
2024-04-20(6)
2024-04-19(5)
2024-04-18(0)
2024-04-17(5)
2024-04-16(70)
2024-04-15(42)
2024-04-14(0)
2024-04-13(119)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022