《数据库性能优化》-PPT课件
合集下载
《数据库优化》幻灯片
实验案例2：个人查询未缴费账单
学员练习： 使用SQL语句查询用户的未缴费信息 使用数据库引擎优化参谋优化数据库 建立索引，从而优化查询速度 使用SQL语句查询用户的滞纳金
未缴费信息
35分钟完成
用户滞纳金
实验案例3：备份与恢复Tariff数据库
需求描述 电信公司的数据库Tariff对数据的稳定性有非常高 的要求 对数据库执行完整+事务日志备份 用户缴费后，数据丧失需要能够完全恢复 定期让数据库自动完成完整、差异、事务日志备 份(可选任务)
账单情况户 对 上 月 话 费 进行缴费
已缴费数据导出到 历史数据
2.用户在26日后缴费，需要缴 滞纳金，滞纳金每天按欠费
电准备信查看每月收入、欠费用户情1%况收取等
接
受
缴
费
实验案例1：批量批价8月账单
需求描述 电信公司在月底准备进展用户的缴费工作，需要 对通话记录call表中所有用户通话记录进展批价, 批价日期为2021-09-05 建立性能监视器监视tempdb文件大小和Tariff数 据库日志文件大小，分析监视后的结果并给出改 进建议
需求描述 本次实验依赖于前一实验结果，即8月份所有用户 的批价已经完成 查询号码为的用户未缴费信息(账单日期，账单金 额) 帐单表accountbill表中的列isPaid=0为未缴费 优化查询速度，给出优化改进建议 查询未缴费账单滞纳金(可选任务)
实验案例2：个人查询未缴费账单
实现思路： 利用SQL语句查询的用户未缴费信息 查看优化前的SQL执行方案和客户端统计信息 使用数据库引擎优化参谋优化数据库 再次查看SQL执行方案和客户端统计信息 使用SQL语句查询用户的滞纳金 滞纳金：缴费日期每超过账单所在月26号一天， 收取账单金额的1%
Oracle性能优化PPT课件
STATSPACK统计信息的表空间以及临时表空间
-
7
AWR报告
• Oracle 10g 版本 推出的新特性 • Automatic Workload Repository • 负责收集、处理并维护性能统计信息 • 检查和分析性能问题 • 对比StackPack报告：实时+自动
-
8
AWR报告
• 生成标准统计报表
举例三:优化后
select b.insuredname, b.insuredidno from llclaimpedor a, lccont b where a.contno = b.contno
and a.caseno = '9055000006018488'
-
31
举例四:优化前
SELECT r.* FROM LOPRTManager r, LCCont t WHERE r.StateFlag in ('1') and (patchflag is null or patchflag <> '1') AND r.PrtType = '0' and t.ContNo = r.OtherNo
• Bitmap 位图索引
– 多应用于数据仓库 – 统计类需求适用 – Update代价较高
-
13
索引创建原则
• 提高查询语句的效率，减慢了DML语句的速度 • 在全表扫描和索引之间权衡
– 如果全表扫描可以接受，那么慢一些的索引访问也可以接受
• 在哪些列建立索引
– Where字句中引用的列 – Join中引用的列 – 在子表的FK上建立索引，防止对父表操作时锁住子表
-
29
-
7
AWR报告
• Oracle 10g 版本 推出的新特性 • Automatic Workload Repository • 负责收集、处理并维护性能统计信息 • 检查和分析性能问题 • 对比StackPack报告：实时+自动
-
8
AWR报告
• 生成标准统计报表
举例三:优化后
select b.insuredname, b.insuredidno from llclaimpedor a, lccont b where a.contno = b.contno
and a.caseno = '9055000006018488'
-
31
举例四:优化前
SELECT r.* FROM LOPRTManager r, LCCont t WHERE r.StateFlag in ('1') and (patchflag is null or patchflag <> '1') AND r.PrtType = '0' and t.ContNo = r.OtherNo
• Bitmap 位图索引
– 多应用于数据仓库 – 统计类需求适用 – Update代价较高
-
13
索引创建原则
• 提高查询语句的效率，减慢了DML语句的速度 • 在全表扫描和索引之间权衡
– 如果全表扫描可以接受，那么慢一些的索引访问也可以接受
• 在哪些列建立索引
– Where字句中引用的列 – Join中引用的列 – 在子表的FK上建立索引，防止对父表操作时锁住子表
-
29
数据库优化及性能.
块
• 逻辑存储结构----块(block) • 块是最小的数据管理单位,也是执行输入输出
操作时的最小单位.相对应地,操作系统执行输入输 出操作的最小单位是操作系统块. • 块的大小是操作系统块大小的整数倍.以 Windows 2000为例,操作系统块的大小是4kb,所 以块的大小可以是4kb,8kb,16kb等 • 如果块的大小是4kb,EMP表每行的数据占100 个字节.如果某个查询语句只返回1行数据,那么,在 将数据读入到数据高速缓存时,读取的数据量是 4kb而不是100个字节
减少访问数据库的次数
• • 方法1 SELECT A.EMP_NAME , A.SALARY , A.GRADE, B.EMP_NAME , B.SALARY , B.GRADE FROM EMP A,EMP B WHERE A.EMP_NO = 342 • AND B.EMP_NO = 291; 方法2 SELECT EMP_NAME , SALARY , GRADE FROM EMP WHERE EMP_NO = 342; SELECT EMP_NAME , SALARY , GRADE FROM EMP WHERE EMP_NO = 291;
段
• 逻辑存储结构----段(segment) • 段用于存储表空间中某一种特定的具有独立存 储结构的对象的所有数据,它由一个或多个区组成. • 段的几种类型: • ● 表段(数据段) • ● 索引段 • ● 临时段 • ● 回退段
区
• 逻辑存储结构----区(extent) • 区是由物理上连续存放的块构成的.区是 Oracle存储分配的最小单位,由一个或多个块组成 区,由一个或多个区组成段.当在数据库中创建带有 实际存储结构的方案对象(如表,索引,簇)时,Oracle 将为该方案对象分配若干个区,以便组成一个对应 的段来为该方案对象提供初始的存储空间.当段中 已分配的区都写满后,Oracle就为该段分配一个新 的区,以便容纳更多的数据.
mysql性能优化精品PPT课件
MySQL优化
目录索引
MySQL优化方式 MySQL技巧分享 MySQL函数
MySQL优化方式
MySQL优化方式
系统优化：硬件、架构 服务优化 应用优化
系统优化
使用好的硬件，更快的硬盘、大内存、多核CPU，专业的存 储服务器（NAS、SAN）
设计合理架构，如果 MySQL 访问频繁，考虑 Master/Slave 读写分离；数据库分表、数据库切片（分布式），也考虑使 用相应缓存服务帮助 MySQL 缓解访问压力
选项
max_connections query_cache_size sort_buffer_size
record_buffer table_cache
缺省值
100 0 (不打开）M 16M
16M 512
说明
MySQL服务器同时处理的数据库连接的最大数量
查询缓存区的最大长度，按照当前需求，一倍一倍 增加，本选项比较重要
每个线程的排序缓存大小，一般按照内存可以设置 为2M以上，推荐是16M，该选项对排序order by， group by起作用
每个进行一个顺序扫描的线程为其扫描的每张表分 配这个大小的一个缓冲区，可以设置为2M以上
为所有线程打开表的数量。增加该值能增加mysqld 要求的文件描述符的数量。MySQL对每个唯一打开 的表需要2个文件描述符。
8M
128M 0 256M
innodb_log_buffer_size
128K
8M
说明
InnoDB使用一个缓冲池来保存索引和原始数据, 这 里你设置越大,你在存取表里面数据时所需要的磁盘 I/O越少，一般是内存的一半，不超过2G，否则系 统会崩溃，这个参数非常重要
InnoDB用来保存 metadata 信息, 如果内存是4G， 最好本值超过200M
目录索引
MySQL优化方式 MySQL技巧分享 MySQL函数
MySQL优化方式
MySQL优化方式
系统优化：硬件、架构 服务优化 应用优化
系统优化
使用好的硬件，更快的硬盘、大内存、多核CPU，专业的存 储服务器（NAS、SAN）
设计合理架构，如果 MySQL 访问频繁，考虑 Master/Slave 读写分离；数据库分表、数据库切片（分布式），也考虑使 用相应缓存服务帮助 MySQL 缓解访问压力
选项
max_connections query_cache_size sort_buffer_size
record_buffer table_cache
缺省值
100 0 (不打开）M 16M
16M 512
说明
MySQL服务器同时处理的数据库连接的最大数量
查询缓存区的最大长度，按照当前需求，一倍一倍 增加，本选项比较重要
每个线程的排序缓存大小，一般按照内存可以设置 为2M以上，推荐是16M，该选项对排序order by， group by起作用
每个进行一个顺序扫描的线程为其扫描的每张表分 配这个大小的一个缓冲区，可以设置为2M以上
为所有线程打开表的数量。增加该值能增加mysqld 要求的文件描述符的数量。MySQL对每个唯一打开 的表需要2个文件描述符。
8M
128M 0 256M
innodb_log_buffer_size
128K
8M
说明
InnoDB使用一个缓冲池来保存索引和原始数据, 这 里你设置越大,你在存取表里面数据时所需要的磁盘 I/O越少，一般是内存的一半，不超过2G，否则系 统会崩溃，这个参数非常重要
InnoDB用来保存 metadata 信息, 如果内存是4G， 最好本值超过200M
Mysql数据库性能优化培训
通用SQL优化（举例）
通用SQL优化（举例）
通用SQL优化（举例）
通用SQL优化（进一步讨论）
• 使用MySQL时，为了得到合理的执行计划， 需要使用hint。这使得本该对应用程序屏蔽 的执行计划暴露给了执行计划。
• 当数据分布变化时，需要更改SQL语句。 这是一个硬伤。
• 其它先进的数据库如何解决这个问题（data distribution is skewed）
• 验证连接（用户是否有登陆权限） • 解析Query语句 • 权限匹配 • 哈希后检查Query Cache • 生成执行计划 • 执行上一步的计划，得到结果集 • 返回结果集给客户
基本查询举例
• 全表扫描
性能决定于表的大小，类似的扫描性能决定于取 回数据的多少
| table_name | table_rows | avg_row_length | data_length | index_length |
1 row in set (46.29 sec)
基本查询举例
• 全表扫描
+--------------+-------------+--------------+ | table_name | data_length | index_length | +--------------+-------------+--------------+ | comment_star | 531921 | 39936 | +--------------+-------------+--------------+ 1 row in set (0.01 sec) mySQL> select avg(upcount) from comment_star; +--------------+ | avg(upcount) | +--------------+ | 0.0000 | +--------------+ 1 row in set (0.03 sec)
2024年度Oracle的性能优化培训课件
监听器和网络配置
合理配置监听器参数和网络参 数，以优化客户端与数据库服 务器之间的通信性能和稳定性
。
18
05
CATALOGUE
Oracle SQL语句优化
2024/2/2
19
SQL语句编写规范
使用标准的SQL语法
遵循Oracle SQL的编写规范， 确保语句的准确性和可读性。
避免使用SELECT *
规范化与反规范化设计
01
通过数据库表的规范化，消除数据冗余；在必要时，通过反规
范化提高查询性能。
分区表设计
02
根据业务需求，将大表拆分为多个小表，提高查询和维护性能
。
视图与物化视图
03
利用视图简化复杂查询，物化视图缓存查询结果，提高查询速
度。
12
物理结构优化策略
2024/2/2
存储参数调整
根据数据访问特点，调整数据块大小、表空间管理方式等存储参 数。
2024/2/2
3
性能优化目标与意义
2024/2/2
目标
提高系统响应速度、吞吐量，降 低资源消耗，确保系统稳定、高 效运行。
意义
对于企业级应用，性能优化能够 显著提升用户体验，降低运营成 本，增强系统可扩展性和可维护 性。
4
性能优化常见场景
索引优化
合理创建、调整索引，提高数 据检索效率。
内存优化
调整内存参数配置，提高系统 缓存命中率，减少磁盘I/O。
SQL查询优化
针对慢查询、低效查询进行优 化，提高查询速度。
2024/2/2
存储优化
优化数据存储结构、表空间管 理，提高I/O性能。
并发与锁优化
优化事务处理、锁机制，提高 系统并发处理能力。
合理配置监听器参数和网络参 数，以优化客户端与数据库服 务器之间的通信性能和稳定性
。
18
05
CATALOGUE
Oracle SQL语句优化
2024/2/2
19
SQL语句编写规范
使用标准的SQL语法
遵循Oracle SQL的编写规范， 确保语句的准确性和可读性。
避免使用SELECT *
规范化与反规范化设计
01
通过数据库表的规范化，消除数据冗余；在必要时，通过反规
范化提高查询性能。
分区表设计
02
根据业务需求，将大表拆分为多个小表，提高查询和维护性能
。
视图与物化视图
03
利用视图简化复杂查询，物化视图缓存查询结果，提高查询速
度。
12
物理结构优化策略
2024/2/2
存储参数调整
根据数据访问特点，调整数据块大小、表空间管理方式等存储参 数。
2024/2/2
3
性能优化目标与意义
2024/2/2
目标
提高系统响应速度、吞吐量，降 低资源消耗，确保系统稳定、高 效运行。
意义
对于企业级应用，性能优化能够 显著提升用户体验，降低运营成 本，增强系统可扩展性和可维护 性。
4
性能优化常见场景
索引优化
合理创建、调整索引，提高数 据检索效率。
内存优化
调整内存参数配置，提高系统 缓存命中率，减少磁盘I/O。
SQL查询优化
针对慢查询、低效查询进行优 化，提高查询速度。
2024/2/2
存储优化
优化数据存储结构、表空间管 理，提高I/O性能。
并发与锁优化
优化事务处理、锁机制，提高 系统并发处理能力。
第09章Oracle的性能优化
9.2 SQL语句的优化
9.2.1 SQL语句的优化规则 9.2.2 SQL语句优化的具体方法
9.2.1 SQL语句的优化规则
（1）去掉不必要的大表、全表扫描。不必要的大表、全表 扫描会造成不必要的输入输出，而且还会拖垮整个数据库；
（2）检查优化索引的使用 这对于提高查询速度来说非常重 要；
（3）检查子查询，考虑SQL子查询是否可以用简单连接的 方式进行重新书写；
系统的服务器，可以使用sar –u命令查看CPU的使用率；NT 操作系统的服务器，可以使用NT的性能管理器来查看CPU 的使用率。
出现CPU资源不足的情况是很多的：SQL语句的重解析、 低效率的SQL语句、锁冲突都会引起CPU资源不足。
2．查看SQL语句的解析情况 （1）数据库管理员可以执行下述语句来查看SQL语句的解析 情况：
9.3 Oracle运行环境的优化
9.3.1 内存结构的调整 9.3.2 物理I/O的调整 9.3.3 CPU的优化调整 9.3.4 网络配置的优化 9.3.5 Oracle碎片整理 9.3.6 Oracle系统参数的调整
9.3.1 内存结构的调整
内存参数的调整主要是指Oracle数据库的系统全局区 （SGA）的调整。SGA主要由三部分构成：共享池、数 据缓冲区、日志缓冲区。
2．数据缓冲区 数据库管理员可以通过下述语句，来查看数据库数据缓冲区
的使用情况。
SELECT name， FROM v$sysstat WHERE name IN （'db block gets','consistent gets','physical reads'）;
根据查询出来的结果可以计算出数据缓冲区的使用命中率：
Oracle性能调整与优化71页PPT
Oracle数据库性能 调整和优化
Oracle技术专题讲座
SUPPORT SERVICES
内容提要
1.oracle 性能调整概述 2.磁盘I/O的调整 3.oracle 内存分配与调整 4.SQL优化概述 5.Statspack概述
SUPPORT SERVICES
1.oracle 性能调整概述
SUPPORT SERVICES
２.5 管理回滚段
回滚段：用来保存数据变化前映像而提供一致读和保障 事务完整性的一段磁盘存储区域． 旧数据
回滚段
新数
表
据
UPDATE
SUPPORT SERVICES
２.5 管理回滚段
回滚段作用
回退事务
事务恢复
回滚段
读一致性
控制文件
数据文件
重做日志
SUPPORT SERVICES
SUPPORT SERVICES
2.4 使用本地管理表空间(LMT)自动段空间管理 （ASSM）
create tablespace demo datafile '/ora01/oem/demo01.dbf ' size 5m EXTENT MANAGEMENT LOCAL -- Turn on LMT SEGMENT SPACE MANAGEMENT AUTO -- Turn on ASSM;
OWNER ALEX
TABLE_NAME DEPT
PARTITION_COUNT 3
SUPPORT SERVICES
2.4 使用分区表避免磁盘争用
Select segment_name, partition_name, segment_type, tablespace_name
Oracle技术专题讲座
SUPPORT SERVICES
内容提要
1.oracle 性能调整概述 2.磁盘I/O的调整 3.oracle 内存分配与调整 4.SQL优化概述 5.Statspack概述
SUPPORT SERVICES
1.oracle 性能调整概述
SUPPORT SERVICES
２.5 管理回滚段
回滚段：用来保存数据变化前映像而提供一致读和保障 事务完整性的一段磁盘存储区域． 旧数据
回滚段
新数
表
据
UPDATE
SUPPORT SERVICES
２.5 管理回滚段
回滚段作用
回退事务
事务恢复
回滚段
读一致性
控制文件
数据文件
重做日志
SUPPORT SERVICES
SUPPORT SERVICES
2.4 使用本地管理表空间(LMT)自动段空间管理 （ASSM）
create tablespace demo datafile '/ora01/oem/demo01.dbf ' size 5m EXTENT MANAGEMENT LOCAL -- Turn on LMT SEGMENT SPACE MANAGEMENT AUTO -- Turn on ASSM;
OWNER ALEX
TABLE_NAME DEPT
PARTITION_COUNT 3
SUPPORT SERVICES
2.4 使用分区表避免磁盘争用
Select segment_name, partition_name, segment_type, tablespace_name
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库性能优化
B2B-DBA-陈立-2019年Q3
主题
基本元素 访问堆表 访问B树索引 案例分析 执行计划
基本元素-总览
一本字典---------------一个表 字典中的一页----------一个数据块 一个字的解释----------一笔记录 页码跟行号------------ROWID
基本元素-堆表
物理上由若干数据块组成
物理上的分界线：High Water Mark
每笔数据的唯一地址：ROWID
逻辑上由若干数据行组成
基本元素-数据块
保存数据的最小容器 读取数据的最小单位（8k或16k，固定大小）
基本元素-ROWID
访问一笔记录的最快方式 ROWID只是一个坑，不是一个萝卜，用它来 访问数据虽然快，但是不安全。因为随着 DELETE/INSERT操作，坑里埋的萝卜会变。 坑还是原来的坑，萝卜已经不是原来的萝卜了。
访问堆表-STOP机制
查询到指定的记录数之后就停止扫描
无需借助索引，也不必访问整张表的所有数据块
在字典中找出5个笔画数为20的字
访问B树索引-典型结构
访问B树索引-特点
自索引的索引 平衡树-----每个叶节点到根节点的距离相等 叶节点之间存在有序链表结构 对 =, >, <, >=, <=, like ‘a%’ 等操作效率 极高 对 <>, like ‘%a%’, like ‘%a’ 操作效率差
实际问题-7
问：这个SQL如何优化？
SELECT * FROM (SELECT t.*, rownum AS rn FROM (SELECT * FROM ._article WHERE domain_id = :1 AND draft = 0 ORDER BY domain_id, draft, gmt_create DESC) t WHERE rownum <= :2) WHERE a.rn >= :3
实际问题-1
问：在索引字段上施加函数，为什么性能差 to_char(gmt_create,’ mmdd’) =‘0101’
答：因为无法使用索引 正确的写法： gmt_create between to_date('20090101','yyyymmdd') and to_date('20090102','yyyymmdd') 用索引范围扫描
答：用了索引快速全扫描 或者 其他低效的扫描 方式。 正确的做法：创建以group_id为首列的索引，使 用索引范围扫描。
实际问题-4
问：计数为什么有时候count(id)比count(*) 慢？
答：count(id)等价于 count(*) where id is not null，如果没有(id)索 引，那么会用全表扫描，而count(*)会自动选择 最优的索引用索引快速全扫描。 正确的写法：计数统一使用count(*)。
实际问题-7
答：在索引内完成过滤/排序/分页，取得一页 的ROWID，用它们再去跟原表做join。
SELECT t.* FROM (SELECT rid, rownum AS rn FROM (SELECT ROWID AS rid FROM ._article WHERE domain_id = :1 AND draft = 0 ORDER BY domain_id, draft, gmt_create DESC) WHERE rownum <= :2) a, ._article t WHERE a.rn >= :3 AND a.rid = t.ROWID
访问B树索引-索引唯一扫描
访问B树索引-索引范围扫描Βιβλιοθήκη 访问B树索引-索引快速全扫描
Select count(*) from table1
访问B树索引-代价
索引唯一扫描：o(1)------索引的层次数 索引范围扫描：o(n)------所需要返回的叶块 索引快速全扫描：o(N)----所有叶块
实际问题-6
问：索引(member_id, subject)这两句性能 有差别吗？
(A): select subject from offer where member_id=#member_id#; (B): select subject, gmt_create from offer where member_id=#member_id#; 答：两句都用了索引范围扫描，(B)还需要根据 索引中查到的ROWID访问表里的记录，当对应 的记录数较多时，比(A)的性能差很多。
实际问题-2
问：在索引字段上用全模糊，为什么性能差 member_id like ‘%alibaba%’
答：因为无法使用索引。 正确的做法：B树索引无法解决这种需求。考虑 用其他技术手段代替，比如搜索引擎。
实际问题-3
问：索引是 (member_id, group_id), 为什 么这个性能差 where group_id=89721
实际问题-5
判断member_id在offer表中是否存在记录， 哪个写法性能好？
(A): select count(*) from offer where member_id=#member_id#; (B): select count(*) from offer where member_id=#member_id# and rownum<=1; 两种写法都用了索引范围扫描，(B)在这个基础 上还用到了STOP机制，查到第一笔记录之后就 立刻停止了扫描，所以性能更好。
执行计划-提出问题
执行计划-设计思路
算法一：
遍历新华字典，对其中的每个字都去语文课本里 找对应的字，每个字的查找都是将整本课本遍历 一遍。直到将课本中该课的生字全部找到。
访问堆表-全表扫描
全表扫描
用多快读的方式访问高水位线以下的所有数据块 哪怕这些数据块里现在都没有数据 哪怕最终只得到少量的记录
就像在一本没有索引的字典里找出所有单人旁 的字，你必须将整本字典从头到尾查阅一遍。
访问堆表-ROWID访问
访问指定ROWID的记录
最快的访问方式
查看字典中第X页第Y行的字
B2B-DBA-陈立-2019年Q3
主题
基本元素 访问堆表 访问B树索引 案例分析 执行计划
基本元素-总览
一本字典---------------一个表 字典中的一页----------一个数据块 一个字的解释----------一笔记录 页码跟行号------------ROWID
基本元素-堆表
物理上由若干数据块组成
物理上的分界线：High Water Mark
每笔数据的唯一地址：ROWID
逻辑上由若干数据行组成
基本元素-数据块
保存数据的最小容器 读取数据的最小单位（8k或16k，固定大小）
基本元素-ROWID
访问一笔记录的最快方式 ROWID只是一个坑，不是一个萝卜，用它来 访问数据虽然快，但是不安全。因为随着 DELETE/INSERT操作，坑里埋的萝卜会变。 坑还是原来的坑，萝卜已经不是原来的萝卜了。
访问堆表-STOP机制
查询到指定的记录数之后就停止扫描
无需借助索引，也不必访问整张表的所有数据块
在字典中找出5个笔画数为20的字
访问B树索引-典型结构
访问B树索引-特点
自索引的索引 平衡树-----每个叶节点到根节点的距离相等 叶节点之间存在有序链表结构 对 =, >, <, >=, <=, like ‘a%’ 等操作效率 极高 对 <>, like ‘%a%’, like ‘%a’ 操作效率差
实际问题-7
问：这个SQL如何优化？
SELECT * FROM (SELECT t.*, rownum AS rn FROM (SELECT * FROM ._article WHERE domain_id = :1 AND draft = 0 ORDER BY domain_id, draft, gmt_create DESC) t WHERE rownum <= :2) WHERE a.rn >= :3
实际问题-1
问：在索引字段上施加函数，为什么性能差 to_char(gmt_create,’ mmdd’) =‘0101’
答：因为无法使用索引 正确的写法： gmt_create between to_date('20090101','yyyymmdd') and to_date('20090102','yyyymmdd') 用索引范围扫描
答：用了索引快速全扫描 或者 其他低效的扫描 方式。 正确的做法：创建以group_id为首列的索引，使 用索引范围扫描。
实际问题-4
问：计数为什么有时候count(id)比count(*) 慢？
答：count(id)等价于 count(*) where id is not null，如果没有(id)索 引，那么会用全表扫描，而count(*)会自动选择 最优的索引用索引快速全扫描。 正确的写法：计数统一使用count(*)。
实际问题-7
答：在索引内完成过滤/排序/分页，取得一页 的ROWID，用它们再去跟原表做join。
SELECT t.* FROM (SELECT rid, rownum AS rn FROM (SELECT ROWID AS rid FROM ._article WHERE domain_id = :1 AND draft = 0 ORDER BY domain_id, draft, gmt_create DESC) WHERE rownum <= :2) a, ._article t WHERE a.rn >= :3 AND a.rid = t.ROWID
访问B树索引-索引唯一扫描
访问B树索引-索引范围扫描Βιβλιοθήκη 访问B树索引-索引快速全扫描
Select count(*) from table1
访问B树索引-代价
索引唯一扫描：o(1)------索引的层次数 索引范围扫描：o(n)------所需要返回的叶块 索引快速全扫描：o(N)----所有叶块
实际问题-6
问：索引(member_id, subject)这两句性能 有差别吗？
(A): select subject from offer where member_id=#member_id#; (B): select subject, gmt_create from offer where member_id=#member_id#; 答：两句都用了索引范围扫描，(B)还需要根据 索引中查到的ROWID访问表里的记录，当对应 的记录数较多时，比(A)的性能差很多。
实际问题-2
问：在索引字段上用全模糊，为什么性能差 member_id like ‘%alibaba%’
答：因为无法使用索引。 正确的做法：B树索引无法解决这种需求。考虑 用其他技术手段代替，比如搜索引擎。
实际问题-3
问：索引是 (member_id, group_id), 为什 么这个性能差 where group_id=89721
实际问题-5
判断member_id在offer表中是否存在记录， 哪个写法性能好？
(A): select count(*) from offer where member_id=#member_id#; (B): select count(*) from offer where member_id=#member_id# and rownum<=1; 两种写法都用了索引范围扫描，(B)在这个基础 上还用到了STOP机制，查到第一笔记录之后就 立刻停止了扫描，所以性能更好。
执行计划-提出问题
执行计划-设计思路
算法一：
遍历新华字典，对其中的每个字都去语文课本里 找对应的字，每个字的查找都是将整本课本遍历 一遍。直到将课本中该课的生字全部找到。
访问堆表-全表扫描
全表扫描
用多快读的方式访问高水位线以下的所有数据块 哪怕这些数据块里现在都没有数据 哪怕最终只得到少量的记录
就像在一本没有索引的字典里找出所有单人旁 的字，你必须将整本字典从头到尾查阅一遍。
访问堆表-ROWID访问
访问指定ROWID的记录
最快的访问方式
查看字典中第X页第Y行的字