体系_sql语句解析执行步骤

service process在接到客户端传送过来的SQL语句时，不会直接去数据库查询。service process进程把这个SQL语句的字符转化为ASCII等效数字码，接着这个ASCII码被传递给一个HASH函数，并返回一个hash值，然后服务器进程将到shared pool中的library cache（高速缓存）中去查找是否存在相同的hash值。如果存在，服务器进程将使用这条语句已高速缓存在SHARED POOL的library cache中的已分析过的版本来执行，省去后续的解析工作，这便是 软解析。若调整缓存中不存在，则需要进行后面的步骤，这便是 硬解析。硬解析通常是昂贵的操作，大约占整个SQL执行的70%左右的时间，会消耗cup资源，硬解析会生成执行树，执行计划，等等。

执行过3次软解析后，就成为 软软解析。

2） 语法合理性检查（ row cache）

当在高速缓存中找不到对应的SQL语句时，则服务器进程就会开始检查这条语句的合法性。这里主要是对SQL语句的语法进行检查，如果服务器进程认为语句不符合语法规则的时候，就会把这个错误信息反馈给客户端。

3）语言含义检查（row cache）

若SQL 语句符合语法上的定义的话，则服务器进程接下去会对语句中涉及的表、索引、视图等对象进行解析，并对照数据字典检查这些对象的名称以及相关结构，看看这些字段、表、视图等是否在数据库中。如果表名与列名不准确的话，则数据库会就会反馈错误信息给客户端。

所以，有时候我们写select语句的时候，若语法与表名或者列名同时写错的话，则系统是先提示说语法错误，等到语法完全正确后再提示说列名或表名错误。

4）获得对象解析锁（control structer）

当语法、语义都正确后，系统就会对我们需要查询的对象加锁。这主要是为了保障数据的一致性，防止我们在查询的过程中，其他用户对这个对象的结构发生改变。

5）数据访问权限的核对（row cache）

当语法、语义通过检查之后，客户端还不一定能够取得数据，服务器进程还会检查连接用户是否有这个数据访问的权限。若用户不具有数据访问权限的话，则客户端就不能够取得这些数据。要注意的是数据库服务器进程先检查语法与语义，然后才会检查访问权限。

6）确定最佳执行计划

当语法与语义都没有问题权限也匹配，服务器进程还是不会直接对数据库文件进行查询。服务器进程会根据一定的规则，对这条语句进行优化。

当服务器进程的优化器确定这条查询语句的最佳执行计划后， 就会将这条SQL语句与执行计划保存到数据高速缓存（library cache）。如此，等以后还有这个查询时，就会省略以上的语法、语义与权限检查的步骤，而直接执行SQL语句，提高SQL语句处理效率。

III 绑定变量赋值

如果SQL语句中使用了绑定变量，扫描绑定变量的声明，给绑定变量赋值，将变量值带入执行计划。若在解析的第一个步骤，SQL在高速缓冲中存在，则直接跳到该步骤。

IIII语句执行

对于SELECT 语句：

1）首先服务器进程要判断所需数据是否在 buffer cache存在，如果存在且可用，则直接获取该数据而不是从数据库文件中去查询数据，同时根据LRU 算法增加其访问计数；

2）若数据不在缓冲区中，则service process进程将从数据库文件中查询相关数据，并通过service process进程把这些数据放入到数据缓冲区中（buffer cache） ，方便后人。

对于DML 语句（insert 、delete 、update ）：

1）检查所需的数据库是否已经被读取到缓冲区缓存中。如果已经存在缓冲区缓存，则直接执行步骤3；

2）若所需的数据库并不在缓冲区缓存中，则service process把数据文件读取到缓冲区缓存中；

3）对想要修改的表取得的数据行锁定（Row Exclusive Lock），之后对所需要修改的数据行取得独占锁；

4）将数据产生的Redo记录到redo log buffer；

5）产生数据修改的undo数据；

6）修改buffer cache；

7）dbwr将修改buffer cache写入数据文件；

IV 提取数据

当语句执行完成之后，查询到的数据还是在服务器进程中，还没有被传送到客户端的用户进程。所以，在服务器端的进程中，有一个专门负责数据提取的一段代码。他的作用就是把查询到的数据结果返回给用户端进程，从而完成整个查询动作。