(SQL原理知识.docVIP

SQL处理机制 其中： Parser： 语法检查：检查SQL语句本身的语法是否正确； 语义检查：检查数据库对象、属性等是否正确； 优化器： 决定使用基于规则或基于成本的优化方式； 输出一个自认为的执行的最佳设计； Row Source Generator： 根据优化器的最佳设计输出SQL指令的执行计划； 以树形式表示，每一步均返回一组行数据； SQL execution engine 每一步由Row Source Generator产生的row source均由SQL执行引擎执行； 产生查询结果； 优化器工作步骤： 评估表达式和包含常量的条件语句； 转换SQL指令，如将子查询转换为等效的JOIN语句； 选择优化方式和目的； 选择访问路径； 选择表联接的顺序：多表联接中，选择哪两个表先做联接，再上哪个表与上一联接结果联接，等等； 选择联接方式。 执行计划： 执行计划是一组执行步骤的集合； 包括：access path；Join Order和Join Method； 先执行最里层（叶子），再执行父层；同级的先执行上一行； 如果父步骤只需子步骤返回一条记录就可以执行，那么一旦子步骤返回一条记录后，父步骤就执行；如果父步骤的父步骤也只要求一条记录，那么同理，也将立即执行。 这种父步骤包括： table accesses index accesses nested loop joins filters 如果父步骤要求子步骤所有记录返回后才能执行，那么必须子步骤执行完毕，返回所有记录后，父步骤才能执行。 sorts sort merge joins aggregate functions 执行计划有最快速度返回一行和最佳吞吐量两种方式。 一般，用户更关心何时应用程序能运行完毕，即批量数据完成。所以采用基于最佳吞吐量（best throughout）的方式优化； 在交互系统，如web等应用中，用户更想尽早看到返回的一行或几行记录，这时最快响应时间更重要，所以采用基于最快速度的优化方式。（典型的如卓越网返回图书目录） 优化模式： OPTIMIZE_MODE（对实例有效） OPTIMIZE_GOLE（对会话有效，可覆盖OPTIMIZE_MODE） choose系统自动选择基于成本还是基于规则。如果所访问的表至少有一个在数据字典中有统计信息，那么缺省按基于成本优化，没有统计信息的，oracle自己猜测进行（有可能造成很大错误）；若均没有统计信息，基于规则。 8i以后的版本均使用DBMS_STATS来统计，以前的版本使用ANALYSE。 first_rows最快的速度返回记录（旧的方式，为了向后兼容而保留），用于OLAP（联机事务处理）中用户要求尽快看到小的结果集。因为要快，所以通常要使用索引而不是全表扫描，或用嵌套循环联接。 first_rows_n(n可能为1、10、100、1000)Oracle9i的增强优化模式（新的方式）。用于返回一个小型的数据集。CBO将根据该值决定是否该使用某索引。若n很大，可能会采用hash join或全表扫描。 all_rows最小的资源占用，用于决策系统、数据仓库等非实时要求的应用中。更倾向于使用基于全索引扫描的全表扫描。 rule古老的优化模式，已有十来年无任何变化。不支持自1994年后所增的所有新功能，如位图索引、表分区、基于函数的索引等。Oracle不推荐使用。 如果要返回全部查询结果，不要使用最快速度模式。 访问表的方式 Oracle的I/O是对数据块的访问，而不是基于行（row）。 Full table scan 读取所有的数据块； 初始化参数DB_FILE_MULTIBLOCK_READ_COUNT决定了一次读取块的数量； 用于： 小表 ORACLE认为数据量大到使用索引没有意义时 无法使用索引时 访问大量数据块时优于index range scan，因为能够使用large I/O call； I/O调用的时间由两部分组成：setup time和data transfer time。典型的I/O调用中，前者占了大部分时间。比如对8K buffer的处理需10毫秒左右，其中的transfer time只有不到1毫秒。所以同样对128K数据的处理，一个128K的I/O调用只需不到20毫秒（一次setup time+16次transfer time）；但8K的I/o调用则需耗时160毫秒左右。 假设一个表的数据由10000个数据块组成，通过索引访问20%的数据块与全表扫描作对比： 参数DB_FILE_MULTIBLOCK_READ_COUNT = 16 参数DB_BLOCK_SIZE = 8 K Number of 8 K I/O calls required for index ac