[疯狂Java]SQL-DDL：索引、视图

1. 索引：

    1) 就相当于书的目录，目的就是为了加速查找想要的内容；

    2) 数据库的索引（index）也是用来加速表的查询，通常可以为表的一列或者多列的组合建立索引，这样查询索引列的时候可以大大提高效率（因为索引可以通过快速路径访问来加快数据的定位）；

！！但索引的缺点也是很明显的，就是当记录被添加、删除、修改时索引也需要跟着变化，而维护索引需要消耗额外的时间和存储空间；

    3) 可以建索引的只能是表的列（或者列的组合），因此索引必须从属于某个表；

！！虽然索引和表、约束等一样都是平行的数据库对象，也会被独立地存放在数据字典中，但是独立存放并不代表索引是独立存在的，和约束一样，索引必须从属于某张表；

！！所有在一个数据库对象中创建的索引都会被记录在information_schema数据库的STATISTCS表中；

    4) 创建索引：

         i. 自动创建：在创建主键、唯一键、外键时都会自动建立索引，因为标准SQL要求约束必须用索引来实现；

         ii. 手动创建：使用SQL语句的create index来创建；

    5) 手动创建：

         i. 语法格式：create index 自定义索引名 on 目标表(目标列或列组合); // 必须体现出索引从属于哪张表

         ii. 示例：

create index MyIndex on table_teacher(teacher_name, class_no); // 多列组合的索引

    6) 删除索引：和创建一样，一定要体现出索引从属于某张表

         i. 语法格式：drop index 索引名 on 从属的表;

         ii. 按照上面的示例删除应该就是：drop index MyIndex on table_teacher;

2. 视图：

    1) 视图是一种“特殊”的数据表，它并不真正的存放数据，它只是一个SQL查询得来的结果（由一段查询的结果得到的一张“表”），而这张“查询”得来的“表”并不是真正意义上的表，因为它只是内存中的一段临时数据，并不持久保存在磁盘中，因此视图并不存储数据，只是一种查询结果的“展示”；

    2) 因此视图的本质就是一个查询语句罢了，其定义格式（关键字是view）：create or replace view 自定义视图名 as 子查询;

！！create or replace的意思就是如果不存在就创建，如果已经存在了就那新的替换掉；

！例如：create or replace view MyView as select Number, Name from TableStudent; // 视图MyView就是select Number, Name from TableStudent查询得到的一张临时逻辑表

    3) 那为什么需要视图呢？直接调用那个里面的子查询不就能得到视图的结果吗？

         i. 如果要对那个子查询的结果继续查询呢？那不就要继续嵌套一层select查询了吗？

         ii. 如果有很多很多最终的查询都是基于那个子查询的结果继续查询呢？那岂不是要写很多遍那个子查询了吗？

         iii. 基于上述两点，再之，如果那个子查询非常非常的复杂，那谁又愿意重复多次写那个子查询呢？

         iv. 但是如果将这个子查询的结果当成一张普通的表来处理，然后再基于这张表继续查询那么一切问题不就简化很多了吗？

         v. 视图就是这个目的：方便查询！！简化查询！！

     4) 由于视图只是数据的逻辑显示，并不存储真正的数据，因此不能修改视图中的数据，即使修改也是会被拒绝的，以为标准SQL规定视图仅仅就是用来简化查看数据的，因此视图必定是只读的；

！！MySQL允许在创建视图时在末尾使用with check option子句来强制规定该视图不允许被修改，例如：create or replace view MyView as select * from t1 with check option;

    5) 既然都要用子句来强制限制视图不能修改，那就意味着其实还是能修改的咯？是的，是允许修改，只不过修改的只是视图产生在内存中的那个临时数据（就是那个临时产生的结果“表”），但不影响真实存放在磁盘中的原表的数据；

    6) 删除视图：视图只是临时性的逻辑显示，因此删除总是能成功的，而且绝不会产生任何附加影响，语法就是：drop view 目标视图名;

    7) 视图可以是很多表连接查询的组合，因此必定是和表平行的一种数据库对象；