1. ALTIBASE 管理培
训 优化篇

2. CONTENTS
1. Tuning 概要
2. ALTIBASE 架构
3. 诊断方法
4. Explain Plan
5. Query Tuning

3. Tuning 概要
1. 数据库发展方向
2. 影响数据库性能的几个问题
3. 提高性能的要素
4. ALTIBASE Performance Tuning

4. 数据库的发展方向
 1970 年代之前 : 以文件形式管理数据
 1970 年代 : 开始出现数据库管理系统
 1980 年代 : 关系型数据库的商用化
 1990 年代 : 国内开始引进并使用数据库
 2000 年代 : 内存数据库的商用化
 现在 : 同时满足大容量和高性能处理的融合数据库

5. 影响数据库性能的几个问题
 产出物为主的开发
 有限的项目费用和开发工期
 开发人员对数据库知识的不足
 不适当的硬件和数据库的评估
 对项目以及技术的自信心

6. 提高性能的要素
 适合于关系型数据库的系统设计
 通过资深系统分析架构师的引导降低项目风险
 确保熟悉 SQL 的应用开发人员

7. ALTIBASE Performance Tuning
Tuning Steps
5. 数据库参数优
1. 系统设计优化 化
4. 操作系统优化
2. 应用程序优化
3. SQL 优化

8. ALTIBASE Performance Tuning
Tuning 要素
 执行计划
 表结构和数据量 ( 索引、数据类型 )
 应用的逻辑 ( 访问表的顺序和次数 )
 系统资源的有效使用 (CPU 和 Memory)

9. ALTIBASE 架构
1. ALTIBASE 结构
2. SELECT 处理过程
3. DML 处理过程
4. COMMIT 处理过程
5. 逻辑存储结构

10. ALTIBASE 结构
Application
E /SQL CLI ODBC JDBC
IPC Unix Dom ain Socket TCP/IP
Integrated Query Processor
Parser Optimizer Executor
Integrated Storage Manager
Transaction Recovery Buffer Index
Manager Manager Manager Manager
Physical Memory
Memory Tablespace Log Buffer Disk Buffer
Stable Storage
Checkpoint Image Stable Log Disk Tablespace

11. SELECT 处理过程
SQL Text
 syntax check
Parsing  generate Parsing Tree
 semantic check
Validation  access META
 calculate cost / normalize
Optimization  generate Execution Plan Tree
 execute Execution Plan tree
Execution  access table
Storage Manager
Table Log Lock Index Transc. Memory GC

12. DML 处理过程
ALTIBASE 支持 MVCC MVCC(Multi-Version Concurrency Control) 并发控制。
变更操作时，生成新版本记录再获得锁，所以读 / 写操作之间不发生冲突，并保证复杂事务环境下的高性能。
Exclusive Mode
生成新版本
Exclusive Mode
曹操 34 刘备 34
曹操 34
select
DML
select DML
TX 3
Transaction 1 Transaction 2 Transaction 3
TX 1 TX 2 SVCC 方式
Garbage Collection
一旦更新事务被提交，多个记录版本中只有最后生成的版本信息有效，而且旧版本被垃圾收集器删除，回收的槽
被插入 / 更新操作再利用，以提高内存的使用率。

13. DML 处理过程
OLD 曹操 NEW 曹操 刘备 OLD
NEW 刘备
Data Page Data Page Undo Area
Out-Place ( 变更 RID) In-Place ( 维持 RID)
Memory Tables Disk Tables
 内存表是在数据页中对新版本的记录以另一个 RID 存储的  磁盘表采用对于变更的记录字段以 Undo log 记录存储于
Out-place 结构以确保高性能 Undo 表空间
为了有效使用数据页，当新版本记录大小大于 property 指定 用变更后的数据覆盖源数据的 In-place 结构。
(LOCK_ESCALATION_MEMORY_SIZE) 的大小时自动转换为
In-place Update 。

14. COMMIT 处理过程
Logging : 为了恢复已提交的事务，处理事务时记录日志
Checkpoint: 日志文件个数达到一定个数或周期达到设定的时间时把更新的内存数据页写到磁盘以缩短恢复
时间
1
Log Buffer
in Memory
3 DB in
TX Memory
2 5 Archive Log
2 Log
Checkpoint Sync File
Commit
4
2
Data File
Log
Online Log File
Arch
WAL(Write Ahead Logging)
数据页储存数据并返回事务结果前以文件形式记录 (logging) 事务的内容
非正常时内存上的数据即使发生了流失，也可通过文件系统上的日志文件可以恢复数据

15. ALTIBASE ODBC 应用优化
下面是 ALTIBASE 建议使用的应用程序组织方式
建立连接 SQL执行
SQLAllocHandle(ENV) SQLExecute
SQLSetEnvAttr
SQLAllocHandle(DBC)
SQLDriverConnect 获取（Fetch）数据
数据记录
SQLSetConnectAttr SQLFetch 循环操作
初始化资源
提交（或回滚）事务
初始化 SQLAllocHandle(STMT)
SQLEndTran 释放语句句柄
阶段 SQLSetStmtAttr
SQLDrop
SQL预处理
释放
SQLAllocStmt 释放连接 阶段
SQLPrepare
SQLFreeHandle(STMT)
SQLDescribeCol
SQLDisconnect
SQLBindCol
SQLFreeHandle(DBC)
SQLBindParameter
SQLFreeHandle(ENV)

16. 逻辑存储结构 (Database)
 Database 文件系统 Structure
DATABASE File System
TABLESPACE A TABLESPACE B TABLESPACE C
DATAFILE 1 DATAFILE 4 DATAFILE 7
1 4 7
DATAFILE 2 DATAFILE 5 DATAFILE 8
2 5 8
DATAFILE 3 DATAFILE 6 DATAFILE 9

17. 逻辑存储结构 (TableSpace)
 表空间 Structure * 表空间分类
– 内存表空间 (SYS_TBS_MEMORY)
• 数据字典 , 内存表
– 数据表空间
Tablespace
• 系统表空间 (SYS_TBS_DATA)
• 用户表空间
Free Page – Undo 表空间 (SYS_TBS_UNDO)
• 为了多版本并发控制，存储变更
前的映像
Used Page
– 临时表空间
• 系统临时表空间
(SYS_TBS_TEMP)
Extent • 用户临时表空间
– 扩展名 .dbf
Table Index
Segment

18. INDEX
INDEX 使用注意事项
• 并不是所有的情况下，使用索引访问都能加快速度。
• 索引的可选择性非常重要。当索引的可选择性比较高（具有相
同值的行很少），而我们需要数据量又比较小的时候，索引才能
极大的提高数据访问的速度。当索引的可选择性比较差的时候，
而我们使用的数据量又比较大，此时，使用索引反而会使查询的
速度变慢。
• 针对索引的列，需要匹配索引列的类型，也不能在其上使用计
算、函数等操作，否则，会使索引失效。
• 索引的维护需要成本，会带来 DML 的效率降低。所以只有在
需要的时候才能去创建索引。

19. INDEX
INDEX 使用注意事项
• 当一个表上存在多个索引，只能使用这个表上的一个索引。
( 具体使用哪一个索引由 Altibase 优化器决定 )
SELECT Y.ENAME
FROM EMPLOYEE X
WHERE
X.ENO = 8890 AND X.ENAME = ‘MSKIM’
ENO 上存在索引 IDX_EMP1 , ENAME 上存在索引 IDX_EMP2 ，当我们访问表
EMPLOYEE 的时候，优化器只会选择 IDX_EMP1, IDX_EMP2 中的一个进行访问。

20. INDEX
How Index Works (Using unique index)
SELECT * FROM EMPLOYEE WHERE ENO = 1;
ENO 是表的 PRIMARY KEY,
PRIMARY KEY 是非空唯一索引。

21. INDEX
How Index Works (Using unique index)
Query
Processor
__SYS_IDX_ID_403 EMPLOYEE
(INDEX) (TABLE)
Sorted Not Sorted
-索引是有序存放的，表中的数据是无序存放的。
-索引查询的时候首先会访问 B 树索引的根节点，再根据根节点找到
索引的叶子节点（叶子节点中存放直接指向表数据行的指针）。
-根据叶子节点的指针，直接读到表的数据行。

22. INDEX
How Index Works (Using non unique index)
SELECT * FROM EMPLOYEE WHERE DNO = 1003;
Department – Employee 是
1 对多的关系，所以 Employee 表的
DNO 字段会存在重复的数据。

23. INDEX
How Index Works (Using non unique index)
Query
Processor EMP_IDX1 EMPLOYEE
(INDEX) (TABLE)
Sorted Not Sorted
-假如查找 DNO 为 1003 的行。根据索引的叶子节点，会得到两个
指向到 EMPLOYEE 表的指针。
-根据这两个指针，就可以读取到 EMPLOYEE 表的两行数据。

24. INDEX
How Index Works (Index scan fail)
SELECT * FROM EMPLOYEE WHERE UPPER(DNO) = ‘1’;
对 ENO 列使用函数 UPPER 。

25. INDEX
How Index Works (Index scan fail)
Query
Processor
EMPLOYEE
(TABLE)
EMP_IDX1
(INDEX)
Not Sorted
-UPPER(DNO) 将导致索引访问失效。查询将使用全表扫描
方式访问。
-Altibase 不提供基于函数的索引 FBI(Function Based
Index) ，所以在这种情况下，只能使用全表扫描。

26. INDEX
INDEX SCAN Fail 的几种情况
• 对索引的列进行计算或者使用了函数。
Ex) SELECT * FROM T1 WHERE C1 +1 > 0
SELECT * FROM T1 WHERE TO_CHAR(SOME_DATE) = ‘2007-01-01’
• 索引列的类型不匹配
Ex) SELECT * FROM T1 WHERE CHAR_COLUMN = 1
Cf) CHAR 是 VARCHAR 类型的列。
• Composite Index 中没有使用索引的引导列。
Ex) C1 + C2 是 Composite Index
SELECT * FROM T1 WHERE C2 = :value
Cf ) 把语句改成下面的方式，就可以使用 Composite Index
SELECT * FROM T1 WHERE C1 = :value1 and C2 = :value2
• Altibase Optimizer 判断全表扫描的成本比索引扫描的成本
更低的时候，将不使用索引。

27. INDEX
INDEX SCAN Fail 的几种情况 ( 续 )
• NOT IN 子查询中的索引将失效
Ex) SELECT * FROM EMPLOYEE WHERE DNO NOT IN
(SELECT DNO FROM DEPARTMENT WHERE DNO > 4);

28. INDEX
即使 INDEX SCAN ， Acess Count 依然很高
• 使用 Cardinality 不好的 Index 时发生
-> 确认使用哪个 Index
-> A+B+C 形式的组合 Index 时，如果以 A, C 为条件，则
Access Count 有可能高 . ( 因为只使用 A 条件 )

29. Join Optimization
The Cases of Join optimization
• JOIN CONDITION 中 FULL SCAN 或 Index Access Count 较
高时，需要考虑创建 Index 或变更 Index 顺序
• Index 使用效率不高或无法使用导致 FULL SCAN 时
• Altibase Optimizer 错误判断 JOIN Method 时
• 因过多表的 JOIN ，生成和验证执行计划的时间较长时
• 该 GROUPING – JOIN 的语句以 JOIN – GROUPING 顺序做
成时

30. Join Optimization
CASE1
在做表的 join 的时候，默认采用的是 NEST LOOP ，一般情况下，会把记录数少的结果集
作为驱动表。
-DEPARTMENT 的 DNO 列是 Primary Key ，
所以首先会根据索引扫描 DEPARTMENT 表。
- 再根据连接条件选择 EMPLOYEE 表的 DNO 列上的索引 EMP_IDX 索引扫描 EMPLOYEE 表。

31. Join Optimization
CASE2 (EMP_IDX INDEX 被删除 )
这个 CASE 描述的是非正常情况下，我们需要把全表扫描的结果集作为驱动表，
才能取得比较好的性能。
- EMPLOYEE 全表扫描，根据得到 DNO 再去 JOIN DEPARTMENT 表。
- 在 INDEX 被 DROP 的情况下，这是比较好的选择。如果这两个扫描的顺序反一下，
执行计划将变得比较糟糕，因为增加了 EMPLOYEE 表全表扫描的次数。

32. Join Optimization
Type mismatch in Join condition
• 建议 Join Condition 里使用的数据类型保持一致
• 内部进行型转换时，无法使用 INDEX
• 不得不使用的情况时确认 PLAN 并验证是否能使用 INDEX

33. Join Optimization
Specify your table only once if you possible.
• Inline View , SubQuery 虽然提供 SQL 的易用性和便利性，但有
一直访问同一张表的问题
• 尽量只写一次表名，减少同一张表的重复访问
• 优化成只访问一次表能获得结果集，如果不可行也要最少化访问

34. Join Optimization
Specify your table only once if you possible.
• 尽量减少表的访问次数。例如下面这种情况
SELECT * FROM T1
WHERE (T1. i1 = 1 AND T1.i2 IN (SELECT a2 FROM T2 WHERE T2.a1 = T1.i1))
OR (T1. i1 = 2 AND T1.i2 IN (SELECT a2 FROM T2 WHERE T2.a1 = T1.i1));‘
上面的语句应当改成：
SELECT * FROM T1
WHERE T1. i1 IN (1, 2)
AND T1.i2 IN (SELECT a2 FROM T2 WHERE T2.a1 = T1.i1));

35. Join Optimization
Reduce results before joining, if you possible.
• 尽可能的缩小结果集，然后再进行 join
例如 :
SELECT Y.DNO,
Y.DNAME,
X.TOTAL_SALARY
SELECT Y.DNO,
FROM
Y.DNAME,
(
SUM(SALARY) TOTAL_SALARY
SELECT DNO,
FROM EMPLOYEE X INNER JOIN
SUM(SALARY) TOTAL_SALARY
DEPARTMENT Y ON X.DNO = Y.DNO
FROM
GROUP BY
EMPLOYEE
Y.DNO, Y.DNAME
GROUP BY DNO
) X INNER JOIN DEPARTMENT Y
ON X.DNO = Y.DNO

36. Join Optimization
Outer Join Optimization
• Outer Join 时， Key Access Path 为基准表。
SELECT X.DNAME, Y.ENAME
FROM DEPARTMENT X LEFT OUTER JOIN
EMPLOYEE Y ON X.DNO = Y.DNO
WHERE
X.DNO = 1000 AND Y.ENO = 8890
上面的示例中， X 表会作为基准表， X.DNO = 1000 会走索引。
Y 表则根据连接条件 X.DNO = Y.DNO 进行关联，不会使用 Y 表上的 Y.ENO=8890 上的索引。

37. Join Optimization
Outer Join Optimization
• 基准表没有索引时？
SELECT X.DNAME, Y.ENAME SELECT X.DNAME, Y.ENAME
FROM DEPARTMENT X LEFT OUTER JOIN FROM DEPARTMENT X INNER JOIN
EMPLOYEE Y ON X.DNO = Y.DNO EMPLOYEE Y ON X.DNO = Y.DNO
WHERE WHERE
Y.ENO = 8890 Y.ENO = 8890
以上两个查询的结果是一致的。
对于 OUTER JOIN ， Y.ENO 即使为 PK ，也无法使用索引。
而对于 INNER JOIN ，则可以使用索引。
不必要的 OUTER JOIN 应当避免，可以使用 INNER JOIN 来代替。

38. Limit Optimization
Question
想在 EMPLOYEE 表中找到 SALARY 的前两名。
将 SALARY 排序取得前两名。
SELECT ENAME, SALARY
FROM EMPLOYEE
ORDER BY SALARY DESC
LIMIT 2
结果是对的，但是如果这个语句执行的频率非常高呢 ?

39. Limit Optimization
Question Result
- 对 EMPLOYEE 表进行全表扫描并排序，取得前两行。如果这张表有 1 亿行记录呢？
那这个代价将是非常昂贵的。

40. Limit Optimization
Solution
- 同样的结果，但执行效率非常高，并且受表的记录数大小影响很小。

41. Limit Optimization
Why ?
Query STOP
Processor
Idx_emp_salary EMPLOYEE
(INDEX) (TABLE)
- 通过索引访问表两次。
- SALARY 上的索引是 DESC 创建的 , 带了 where salary>0 ，所以可以使用索引访问。
- Limit 2 返回的记录即为 salary 最大的两条记录。
- 由于直接通过索引访问，表即便再大，对查询的效率影响也不大。

42. Limit Optimization
Limit Stop key 使用说明
• 一般的情况下，我们使用 limit 的目的是为了减少表的访问量。
• 下面的几种情况下 limit 将无法有效发挥作用：
1 、 GROUP BY 将使 limit
2 、无法使用索引的 order by 操作
3 、带很多的 where 条件

43. SUB-QUERY
The Cases of Subquery Optimization
• 因使用过多的 Subquery ，频繁访问同一张表时
• 因对 NOT IN 的理解不够，对于大的结果集使用 NOT IN 时
• Subquery 条件里没有 INDEX 字段时

44. SUB-QUERY
If you read your table twice or more …
• Subquery 是嵌入到另一个 SQL 语句中的 SELECT 语句，频繁读取
同一张表时影响性能
• 内查询的结果集被用作外查询的搜索值，所以内查询的结果集越大性
能下降越严重 ( 注意 !!)
• 如果 SubQuery 的结果集里只取一条记录，建议在 SubQuery
里使用 LIMIT 1
• 如果同一张表被查询两次以上，尽量把 SubQuery 转换为 JOIN
• 所有的 SubQuery 都可以转换为 Join 形态

45. SUB-QUERY
SubQuery -> Joining form
• 使用表连接取代子查询。一般情况下，表连接的效率高于子查询。
SELECT
X.ENAME,
(SELECT DNAME FROM DEPARTMENT WHERE DNO = X.DNO) DNAME,
(SELECT DTEL FROM DEPARTMENT WHERE DNO = X.DNO) DTEL ,
(SELECT DLOCATION FROM DEPARTMENT WHERE DNO = X.DNO) DLOCATION
FROM
EMPLOYEE X;
SELECT
X.ENAME,
Y.DNAME,
Y.DTEL ,
Y.DLOCATION
FROM
EMPLOYEE X INNER JOIN DEPARTMENT Y ON X.DNO = Y.DNO;

46. SUB-QUERY
Avoiding NOT IN Sub Query …
• NOT IN 无法使用索引。
• 使用 JOIN 取代 NOT IN 。
SELECT * FROM EMPLOYEE WHERE DNO NOT IN (
SELECT DNO FROM DEPARTMENT_DELETED);
SELECT X.*
FROM EMPLOYEE X LEFT OUTER JOIN
DEPARTMENT_DELETED Y
ON X.DNO = Y.DNO
WHERE Y.DNO IS NULL

47. Collecting Queries
V$STATEMENT
• 我们可以通过性能视图 v$statement 来查看 SQL 语句的执行情况。
例如我们可以通过下面的语句来找出执行时间比较长的语句
• 较长的 Query 时， SQL 语句显示不全
• 显示查询时执行的 SQL 语句
SELECT SESSION_ID,
EXECUTE_SUCCESS,
EXECUTE_TIME/1000 || ‘ms’ EXEC_MSEC,
FETCH_TIME/1000 || ‘ms’ FETCH_MSEC,
RPAD(SUBSTR(QUERY,1,80), 80, ‘ ‘) QRY
FROM V$STATEMENT
ORDER BY EXECUTE_TIME DESC, EXECUTE_SUCCESS DESC;

48. DML Optimization
INSERT / UPDATE /DELETE
• INSERT 执行慢可能的情况
-> Too Many Indices ?
-> 存在 Table Lock ( 可查询 V$LOCK 视图 )
-> I/O Contention ?
• UPDATE / DELETE 执行慢可能情况
-> 所有导致 SELECT 执行慢的情况
-> 所有导致 INSERT 执行慢的情况
-> 不必要的 Key 字段 Update

49. 谢谢
Contact Point
天津南大通用数据技术有限公司
天津总部 ：天津华苑产业园区海泰发展六道 6 号
邮 编： 300384
电 话： 022-58815881
传 真： 022-58815882
北京业务中心：北京海淀区金源时代商务中心 2 号楼 A 座 17D
邮 编： 100089
电 话： 010-88866866
传 真： 010-88864556
Web ： http://www.generaldata.com.cn