Oracle 12C 之后，Oracle 之中提供的是一种手工的自动增长列控制，而这样的控制在 Oracle 之中使用序列（对象）完成。
序列的创建：
CREATE SEQUENCE 序列名称
[INCREMENT BY 步长] [START WITH 开始值]
[MAXVALUE 最大值 | NOMAXVALUE]
[MINVALUE 最小值 | NOMINVALUE]
[CYCLE | NOCYCLE]
[CACHE 缓存大小 | NOCACHE]
在此数据字典之中主要包含如下列的数据信息：
· SEQUENCE_NAME：表示的序列名称；
· MIN_VALUE：表示序列的最小值，默认的序列最小值是 1；
· MAX_VALUE：表示序列的最大值，默认序列是没有最大值，1028已经很大了。
· INCREMENT_BY：步长，每次增长的数据，默认的是 1；
· CYCLE：是否为循环序列，如果是 N 表示非循环，如果是 Y 表示循环；
· ORDER：表示序列是否排序；
· CACHE_SIZE：序列的缓存数据；
· LAST_NUMBER：序列最后一次的增长值（缓存中最大的值）。
当一个序列对象已经创建完成之后，可以采用如下的两个伪列来进行序列的控制：
· 取得序列下一个增长数据（每次调用序列值都增长指定的步长）：序列.nextval；
· 取得序列的当前数据（每次调用序列都不增长）：序列.currval；
· 在使用 currval 之前一定要首先使用 nextval，否则会出现“ORA-08002: 序列 MYSEQ.CURRVAL 尚未在此会话中定义”。
可是该如何实现行的自动编号呢？
DROP TABLE mytab PURGE ;
CREATE TABLE mytab(
mid NUMBER ,
title VARCHAR2(50) ,
CONSTRAINT pk_mid PRIMARY KEY(mid)
) ;
INSERT INTO mytab(mid,title) VALUES (myseq.nextval,'JAVA') ;
循环序列：
1、3、5、7、9 五个数据之间循环显示
1.序列的最大值是 9；
2.序列的最小值是 1；
3.步长应该为2；
DROP SEQUENCE myseq ;
CREATE SEQUENCE myseq
INCREMENT BY 2
START WITH 1
MAXVALUE 9 MINVALUE 1
CYCLE NOCACHE;
Oracle 12c新特性
CREATE TABLE test1 (
id int GENERATED ALWAYS AS IDENTITY
);
自增列会自动加上 not null 约束。
新增时不能向自增列插入值。
视图
视图就是包装了一条复杂的 SQL 语句。
创建视图：
CREATE [OR REPLACE] VIEW 视图名称 AS 子查询
[WITH CHECK OPTIONI] [WITH READ ONLY] ;
注意：从 Oracle 10g R2 版本之后出现了一个创建视图的权限问题，在这之前，scott 用户本身是具备有创建视图权限的，但是之后就没有了，那么下面首先执行如下的语句，来实现权限的分配：GRANT CREATE VIEW TO scott ;
查看所有视图对象。
SELECT * FROM user_views ;
当使用“CREATE OR REPLACE”创建视图的时候表示的是如果视图不存在则创建一个新的视图，如果视图存在则直接使用新的子查询，替换掉旧的子查询。
实际工作之中，一定要本着一个原则：“视图只能够用于查询，而不要用于任何更新”。
1、 避免视图创建条件更新：WITH CHECK OPTION
2、 设置只读视图：WITH READ ONLY
索引
Oracle 的索引相当复杂，有几十种索引。索引的主要功能是进行数据查询优化的，提升数据库操作性能的。
为了更好的观察出性能问题，那么下面首先针对于一些查询做一个分析。
范例：查询所有工资高于 3000 的雇员工资
SELECT * FROM emp WHERE sal>3000 ;
但是现在这个代码严格来讲性能是很差的，如果要想观察出性能（提示信息）问题，那么需要打开查询分析器。
CONN sys/change_on_install AS SYSDBA ;
SET AUTOTRACE ON ;
SELECT * FROM myemp WHERE sal>3000 ;
此时为了观察出问题只能够在 sys 用户下观察查询的情况，可以发现此时的查询采用的是“TABLE ACCESS FULL”
（全表扫描，逐行扫描）。那么这样的查询有可能出现这样一个问题。
假设现在 emp 表之中存在有 50W 条记录，而在第 20W 条记录之后就不会再有满足条件的数据了（sal>3000），但是如果是全表扫描，意味着，要继续查询后面的 30W 行记录，而且都是逐行扫描（逐行判断），那么性能一定不能高。
此时，如果要想解决此问题，那么唯一的途径就是数据排序，按照工资排序，但是这个时候的排序不是简单的由高到低的排序。那么现在唯一的方式是按照“树”的形式保存排序数据。
现在假设数据表之中所包含的数据顺序如下：“1500、1250、2850、3000、2450、2975、1100、950、800、1600、5000”。
数据检索的时候一定是查询工资数据，而后由工资数据找到对应的数据记录
那么此时如果存在了这样树的结构，在进行数据查询的时候就不再需要进行全表扫描的操作了，只需要查询部分数据即可，而这样的操作就可以称为索引