Oracleインデックスの詳細（インデックス）

1コンセプト

1. 索引具有两个功能：
	(1) 强制实施 "主键约束" 和 "唯一性约束"
	(2) 提高性能
	
2. 提示：
	(1) 对于使用 where 子句的 select、update、delete 或 merge 语句而言，
	    索引可以起到辅助作用
	(2) 但对于 insert 而言，索引会降低处理速度。
	    原因：每次在表中插入一行时，必须在表的每个索引中插入一个新键。

2インデックスタイプ

2.1Bツリーインデックス

1. B-Tree 索引（B 代表 "平衡（balanced）"） 是一种树结构 -- 不是 "二叉树" 哦
2. 树的 '根节点' 指向 '第二级别' 的多个节点，'第二级别' 的节点又指向 '第三级别' 的多个节点，以此类推。
3. B-Tree 索引是 Oracle 默认的索引类型

---

Bツリーインデックスの該当するシナリオ：

1. 列的基数很大（不同值的个数很多）
2. 一般认为，如果查询要检索 "低于" 2%~4% 的行，'B-Tree 索引' 合适，
	        如果查询要检测 "高于" 2%~4% 的行，则 '全表扫描' 更快

原理図：データブロックを読み取るプロセスのデモンストレーション
ケーススタディ：値を見つけるプロセス82

1. ルートノードを読み取り、82が0〜120の間にあると判断し、左側のブランチを取得します
2. 左側のブランチノードを読み取り、82が80〜120の間にあると判断し、右側のブランチに移動します
3. 右側のリートノードを読み取り、ノード内のデータ82と対応するROWIDを見つけます
4. rowidを使用して、物理テーブルのレコードデータベースブロックを読み取ります（countであるか、rowidのみを選択している場合は、今回は読み取る必要はありません）。

上記の場合：
1。インデックス配置プロセス全体で、データブロックは3回だけ読み取られます。三次I/OROWIDに配置した後のみ。
2.拡張プロセス全体を通じて、B-Tree自体は常にバランスを維持でき、Leafノードの深さは常に一定に保たれます。（したがって“平衡树”）

2.2ビットマップインデックス（ビットマップ）

該当するシーン：

1. 列的基数很小（不同值的个数少）
2. 列用于布尔代数运算（and、or、not）

原理図：

名前	性別	IDカード（ID_Card）	婚姻状況（婚姻）
n1	男性	421…	未婚
n2	女性	422…	既婚
n3	女性	421…	未婚
n4	男性	422…	離婚
n5	女性	422…	未婚
。。。。	。。。。	。。。。	。。。。

ケーススタディ：次のクエリが利用可能です

SELECT * FROM table t WHERE t.Gender = "女" AND t.Marital = "未婚";

---

フルテーブルスキャンFULLおよびBツリーインデックスの使用状況の分析：

1. 不适用索引
	(1) 不使用索引时，数据库只能一行行扫描所有记录，然后判断该记录是否满足查询条件
	(2) 一般情况下，当取出来的数据超过表 2%~4% 时，比较合适

2. B-Tree 索引
	(1) 对于 "性别（Gender）"，可取值的范围只有 '男','女'，并且男和女可能各站该表的 '50%' 的数据，
	    这时添加 'B-Tree 索引' 还是需要取出一半的数据， 因此完全没有必要。
	(2) 相反，如果某个字段的取值 "范围很广，几乎没有重复"，比如 "身份证号"，使用 'B-Tree 索引' 比较合适
	(3) 事实上，当取出来的数据超过表 2%~4% 时，即使添加了 'B-Tree 索引', 
	    Oracle 也不一定会使用 'B-Tree 索引'，很可能 Oracle 解析器认为 '全表扫描' 更加好

位图索引原理：

• 場合性別（ジェンダー）が列に確立位图索引するために、性別（ジェンダー）の各列の列、rowid（rowid可以理解为每行的物理位置）二つのベクトル、ビットマップ・インデックスを形成し、
• 男性：10010、女性：01101
• その中で、1：は男性を意味し、0：は女性を意味します。

乱暴な	1	2	3	4	5	…
男性	1	0	0	1	0	…
女性	0	1	1	0	1	…

同じことが当てはまります：婚姻状況（婚姻）のビットマップインデックスは次のとおりです

乱暴な	1	2	3	4	5	…
既婚	0	1	0	0	0	…
未婚	1	0	1	0	1	…
離婚	0	0	0	1	0	…

位图检索过程： （そして操作、すべて1が1を取得します）

乱暴な	1	2	3	4	5	…
女性	0	1	1	0	1	…
そして						…
未婚	1	0	1	0	1	…
結果	0	0	1	0	1	…

3文法

データの準備:(ヒント：主キーには一意の制約インデックスが付属しています：重複する値は許可されていません）

CREATE TABLE odsdata.student_info (
   student_no VARCHAR2(10),
   NAME       VARCHAR2(30),
   sex        VARCHAR2(2),
   age        NUMBER(3)
);

ALTER TABLE odsdata.student_info ADD CONSTRAINT fk_student_info_student_no PRIMARY KEY(student_no);

クエリ制約情報：

SELECT t.*
  FROM all_constraints t -- dba_constraints
 WHERE t.owner = 'ODSDATA'
   AND t.table_name = 'STUDENT_INFO';

3.1インデックスの作成

文法：

create [unique | bitmap] index [schema.] 索引名
on [schema.] 表名 (列名1, .., 列名N);

-- 创建一般索引（B-Tree 索引）
CREATE INDEX odsdata.idx_student_info_name ON odsdata.student_info (name);

-- 创建位图索引
CREATE BITMAP INDEX odsdata.bidx_student_info_sex ON odsdata.student_info (sex);

3.2インデックスの削除

drop index [schema.] 索引名;

DROP INDEX odsdata.idx_student_info_name;

3.3インデックスの変更

-- 修改索引名称 idx_student_info_name -> idx_student_info_new_name
ALTER INDEX odsdata.idx_student_info_name RENAME TO odsdata.idx_student_info_new_name;

-- 修改索引为无效
ALTER INDEX odsdata.idx_student_info_name UNUSABLE;

-- 重建索引
ALTER INDEX odsdata.idx_student_info_name REBUILD [ONLINE];

3.4クエリインデックス

SELECT t.*
  FROM dba_indexes t -- all_indexes, user_indexes
 WHERE t.owner = 'ODSDATA'
   AND t.table_name = 'STUDENT_INFO';

4拡張

高さなど、インデックス内の情報をクエリするにはどうすればよいですか？

> ANALYZE INDEX odsdata.idx_student_info_name VALIDATE STRUCTURE;
>
> SELECT t.* FROM index_stats t;