OracleBtree、位图、全文索引三大索引性能比较及优缺点汇总分析
引言：大家都知道“效率”是数据库中非常重要的一个指标，如何提高效率大家可能都会想起索引，但索引又这么多种，什么场合应该使用什么索引呢？哪种索引可以提高我们的效率，哪种索引可以让我们的效率大大降低（有时还不如全表扫描性能好）下面要讲的“索引”如何成为我们的利器而不是灾难！多说一点，由于不同索引的存储结构不同，所以应用在不同组织结构的数据上，本篇文章重点就是：理解不同的技术都适合在什么地方应用！
B-Tree索引
场合：非常适合数据重复度低的字段例如身份证号码手机号码 QQ号等字段，常用于主键唯一约束，一般在在线交易的项目中用到的多些。
原理：一个键值对应一行（rowid）格式：【索引头|键值|rowid】
优点：当没有索引的时候，oracle只能全表扫描where qq=40354446 这个条件那么这样是灰常灰常耗时的，当数据量很大的时候简直会让人崩溃，那么有个B-tree索引我们就像翻书目录一样，直接定位rowid 立刻就找到了我们想要的数据，实质减少了I/O操作就提高速度，它有一个显著特点查询性能与表中数据量无关，例如查2万行的数据用了3 consistent get,当查询1200万行的数据时才用了4 consistent gets。
当我们的字段中使用了主键or唯一约束时，不用想直接可以用B-tree索引
缺点：不适合键值重复率较高的字段上使用，例如第一章1-500page 第二章501-1000page
实验：
alter system flush shared_pool; 清空共享池
alter system flush buffer_cache; 清空数据库缓冲区，都是为了实验需要
创建leo_t1 leo_t2 表
leo_t1 表的object_id列的数据是没有重复值的，我们抽取了10行数据就可以看出来了。
LS@LEO> create table leo_t1 as select object_id,object_name from dba_objects;
LS@LEO> select count(*) from leo_t1;
COUNT(*)
----------
9872
LS@LEO> select * from leo_t1 where rownum <= 10;
OBJECT_ID OBJECT_NAME
---------- -----------
20 ICOL$
44 I_USER1
28 CON$
15 UNDO$
29 C_COBJ#
3 I_OBJ#
25 PROXY_ROLE_DATA$
39 I_IND1
51 I_CDEF2
26 I_PROXY_ROLE_DATA$_1
leo_t2 表的object_id列我们是做了取余操作，值就只有0,1两种，因此重复率较高，如此设置为了说明重复率对B树索引的影响
LS@LEO> create table leo_t2 as select mod(object_id,2) object_ID ,object_name from dba_objects;
LS@LEO> select count(*) from leo_t2;
COUNT(*)
----------
9873
LS@LEO> select * from leo_t2 where rownum <= 10;
OBJECT_ID OBJECT_NAME
---------- -----------
0 ICOL$
0 I_USER1
0 CON$
1 UNDO$
1 C_COBJ#
1 I_OBJ#
1 PROXY_ROLE_DATA$
1 I_IND1
1 I_CDEF2
0 I_PROXY_ROLE_DATA$_1
LS@LEO> create index leo_t1_index on leo_t1(object_id); 创建B-tree索引，说明默认创建的都是B-tree索引
Index created.
LS@LEO> create index leo_t2_index on leo_t2(object_ID); 创建B-tree索引
Index created.
让我们看一下leo_t1与leo_t2的重复情况
LS@LEO> select count(distinct(object_id)) from leo_t1; 让我们看一下leo_t1与leo_t2的重
复情况，leo_t1没有重复值，leo_t2有很多
COUNT(DISTINCT(OBJECT_ID))
--------------------------
9872
LS@LEO> select count(distinct(object_ID)) from leo_t2;
COUNT(DISTINCT(OBJECT_ID))
--------------------------
2
收集2个表统计信息
LS@LEO> execute dbms_stats.gather_table_stats(ownname=>'LS',tabname=>'LEO_T1',method_opt=>'for all indexed columns size 2',cascade=>TRUE);
LS@LEO> execute dbms_stats.gather_table_stats(ownname=>'LS',tabname=>'LEO_T2',method_opt=>'for all indexed columns size 2',cascade=>TRUE);
参数详解：
method_opt=>'for all indexed columns size 2' size_clause=integer 整型，范围1~254 ，使用柱状图[ histogram analyze ]分析列数据的分布情况
cascade=>TRUE 收集表的统计信息的同时收集B-tree索引的统计信息
显示执行计划和统计信息+设置autotrace简介
序号命令解释
1 SET AUTOTRACE OFF 此为默认值，即关闭Autotrace
2 SET AUTOTRACE ON EXPLAIN 只显示执行计划
3 SET AUTOTRACE ON STATISTICS 只显示执行的统计信息
4 SET AUTOTRACE ON 包含2,3两项内容
5 SET AUTOTRACE TRACEONLY 与ON相似，但不显示语句的执行结果
结果键值少的情况
set autotrace trace exp stat; （SET AUTOTRACE OFF 关闭执行计划和统计信息）
LS@LEO> select * from leo_t1 where object_id=1;
no rows selected
Execution Plan 执行计划
----------------------------------------------------------
Plan hash value: 3712193284
--------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 21 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| LEO_T1 | 1 | 21 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN索引扫描 | LEO_T1_INDEX | 1 | | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------- Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OBJECT_ID"=1)
Statistics 统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
2 consistent gets 我们知道leo_t1表的object_id没有重复值，因此使用B-tree索引扫描只有2次一致性读
0 physical reads
0 redo size
339 bytes sent via SQL*Net to client
370 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
结果键值多的情况
LS@LEO> select * from leo_t2 where object_ID=1; （select /*+full(leo_t2) */ * from leo_t2 where object_ID=1;hint方式强制全表扫描）
4943 rows selected.
Execution Plan 执行计划
----------------------------------------------------------
Plan hash value: 3657048469
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4943 | 98860 | 12 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| LEO_T2 | 4943 | 98860 | 12 (0)| 00:00:01 | sql结果是4943row，那么全表扫描也是4943row
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("OBJECT_ID"=1)
Statistics 统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
366 consistent gets 导致有366次一致性读
0 physical reads
0 redo size
154465 bytes sent via SQL*Net to client
4000 bytes received via SQL*Net from client
331 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4943 rows processed
大家肯定会疑惑，为什么要用全表扫描而不用B-tree索引呢，这是因为oracle基于成本优化器CBO认为使用全表扫描要比使用B-tree索引性能更好更快，由于我们结果重复率很高，导致有366次一致性读，从cup使用率12%上看也说明了B-tree索引不适合键值重复率较高的列
我们在看一下强制使用B-tree索引时，效率是不是没有全表扫描高呢？
LS@LEO> select /*+index(leo_t2 leo_t2_index) */ * from leo_t2 where object_ID=1; hint 方式强制索引扫描
4943 rows selected.
Execution Plan 执行计划
----------------------------------------------------------
Plan hash value: 321706586
--------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4943 | 98860 | 46 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| LEO_T2 | 4943 | 98860 | 46 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | LEO_T2_INDEX | 4943 | | 10 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------- Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OBJECT_ID"=1)
Statistics 统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
704 consistent gets 使用B-tree索引704次一致性读> 全表扫描366次一致性读，而且cpu 使用率也非常高，显然效果没有全表扫描高
0 physical reads
0 redo size
171858 bytes sent via SQL*Net to client
4000 bytes received via SQL*Net from client
331 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4943 rows processed
小结：从以上的测试我们可以了解到，B-tree索引在什么情况下使用跟键值重复率高低有很大关系的，之间没有一个明确的分水岭，只能多测试分析执行计划后来决定。
位图索引 Bitmap index
场合：列的基数很少，可枚举，重复值很多，数据不会被经常更新
原理：一个键值对应很多行（rowid），格式：键值 start_rowid end_rowid 位图
优点：OLAP 例如报表类数据库重复率高的数据特定类型的查询例如count、or、and等逻辑操作因为只需要进行位运算即可得到我们需要的结果
缺点：不适合重复率低的字段，还有经常DML操作（insert，update，delete），因为位图索引的锁代价极高，修改一个位图索引段影响整个位图段，例如修改
一个键值，会影响同键值的多行，所以对于OLTP 系统位图索引基本上是不适用的
实验：位图索引和B-tree索引的性能比较
set pagesize 100; 设置页大小
利用dba_objects数据字典创建一个15万行的表
LS@LEO> create table leo_bm_t1 as select * from dba_objects;
T able created.
LS@LEO> insert into leo_bm_t1 select * from leo_bm_t1; 翻倍插入
9876 rows created.
LS@LEO> /
19752 rows created.
LS@LEO> /
39504 rows created.
LS@LEO> /
79008 rows created.
LS@LEO> /
158016 rows created.
因object_type字段重复值较高，顾在此字段上创建bitmap索引
LS@LEO> create bitmap index leo_bm_t1_index on leo_bm_t1(object_type);
Index created.
创建一个和leo_bm_t1表结构一模一样的表leo_bm_t2，并在object_type列上创建一个B-tree索引（15万行记录）
LS@LEO> create table leo_bm_t2 as select * from leo_bm_t1;
T able created.
LS@LEO> create index leo_bm_t2_bt_index on leo_bm_t2(object_type);
Index created.
对比位图索引和B-tree索引所占空间大小,很明显位图要远远小于B-tree索引所占用的空间，节约空间特性也是我们选择位图的理由之一
LS@LEO> select segment_name,bytes from user_segments where segment_type='INDEX'; SEGMENT_NAME BYTES
--------------------------------------------------------------------------------- ----------
LEO_BM_T1_INDEX 327680(327K) LEO_BM_T2_BT_INDEX 7340032(7M) 显示执行计划和统计信息
set autotrace trace exp stat;
在创建有位图索引的表上做count操作对比执行计划
LS@LEO> select count(*) from leo_bm_t1 where object_type='TABLE';
Execution Plan 执行计划
----------------------------------------------------------
Plan hash value: 3251686305
-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 11 | 4 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 11 | | |
| 2 | BITMAP CONVERSION COUNT | | 36315 | 390K| 4 (0)| 00:00:01 |
|* 3 | BITMAP INDEX SINGLE VALUE| LEO_BM_T1_INDEX | | | | |
-----------------------------------------------------------------------------------------------
位图索引上只扫描了一个值
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("OBJECT_TYPE"='TABLE')
Note
-----
- dynamic sampling used for this statement 动态采样
Statistics 统计信息
----------------------------------------------------------
9 recursive calls
0 db block gets
93 consistent gets oracle选择使用位图索引访问数据，导致93次一致性读
7 physical reads
0 redo size
413 bytes sent via SQL*Net to client
381 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
在创建有B-tree索引的表上做count操作对比执行计划
LS@LEO> select count(*) from leo_bm_t2 where object_type='TABLE';
Execution Plan 执行计划
----------------------------------------------------------
Plan hash value: 613433245
----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 11 | 59 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 11 | | |
|* 2 | INDEX RANGE SCAN| LEO_BM_T2_BT_INDEX | 25040 | 268K| 59 (0)| 00:00:01 |
----------------------------------------------------------------------------------------
B-tree索引上全部扫描，cpu使用率达到了59%，比位图索引cpu使用率4%高出许多
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OBJECT_TYPE"='TABLE')
Note
-----
- dynamic sampling used for this statement 动态采样
Statistics 统计信息
----------------------------------------------------------
32 recursive calls
0 db block gets
161 consistent gets B-tree索引表上发生了161次一致性读要远远高于位图索引表上93次一致性读，因此还是位图索引效率高
74 physical reads
0 redo size
413 bytes sent via SQL*Net to client
381 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
我们再看看等值查找where object_type='TABLE'情况下位图索引和B-tree索引的性能对比
LS@LEO> select * from leo_bm_t1 where object_type='TABLE' ;
28512 rows selected.
Execution Plan 执行计划
----------------------------------------------------------
Plan hash value: 4228542614
------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 36315 | 6277K| 562 (0)| 00:00:07 |
| 1 | TABLE ACCESS BY INDEX ROWID | LEO_BM_T1 | 36315 | 6277K| 562 (0)| 00:00:07 |
| 2 | BITMAP CONVERSION TO ROWIDS| 位图映像->rowids | | | | |
|* 3 | BITMAP INDEX SINGLE VALUE | LEO_BM_T1_INDEX | | | | |
------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("OBJECT_TYPE"='TABLE')
Note
-----
- dynamic sampling used for this statement动态采样
Statistics 统计信息
----------------------------------------------------------
7 recursive calls
0 db block gets
4407 consistent gets 使用位图索引发生了4407次一致性读
0 physical reads
0 redo size
2776927 bytes sent via SQL*Net to client
21281 bytes received via SQL*Net from client
1902 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
28512 rows processed
leo_bm_t2表上使用B-tree索引得到执行计划
LS@LEO> select /*+index(leo_bm_t2 leo_bm_t2_bt_index) */ * from leo_bm_t2 where object_type='TABLE' ;
28512 rows selected. 我们强制使用B-tree索引扫描等值条件
Execution Plan 执行计划
----------------------------------------------------------
Plan hash value: 1334503202
--------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 25040 | 4328K| 2063 (1)| 00:00:25 |
| 1 | TABLE ACCESS BY INDEX ROWID| LEO_BM_T2 | 25040 | 4328K| 2063 (1)| 00:00:25 |
|* 2 | INDEX RANGE SCAN | LEO_BM_T2_BT_INDEX | 25040 | | 59 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------
B-tree索引上全部扫描，cpu使用率达到了2063%，比位图索引cpu使用率562%高出许多Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OBJECT_TYPE"='TABLE')
Note
-----
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
7 recursive calls
0 db block gets
6621 consistent gets
0 physical reads
0 redo size
2776927 bytes sent via SQL*Net to client
21281 bytes received via SQL*Net from client
1902 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
28512 rows processed
小结：在等值查找中我们可以看出位图索引的效率依言高于B-tree索引
全文索引Text index
定义：全文索引就是通过将文字按照某种语言进行词汇拆分，重新将数据组合存储，来达到快速检索的目的
场合：当字段里存储的都是文本时适合用全文索引，常用于搜索文字
优点：全文索引不是按照键值存储的，而是按照分词重组数据，常用于模糊查询Where name like '%leonarding%'效率比全表扫描高很多，适用OLAP系统，
OLTP系统里面用到的并不多。
缺点：全文索引会占用大量空间有时比原表本身占的空间还多，bug较多，维护困难。
实验：全文索引性能优势
创建一个表包含2个字段
LS@LEO> create table leo_text_t1 (id int,name varchar(10));
T able created.
在name字段上创建B-tree索引，但检索的时候并没有用，还是全表扫描
LS@LEO> create index leo_text_t1_bt_index on leo_text_t1(name);
Index created.
插入4条记录
insert into leo_text_t1 values(1,'Tom');
insert into leo_text_t1 values(2,'Tom Tom');
insert into leo_text_t1 values(1,'Tom');
insert into leo_text_t1 values(2,'Tom Tom');
commit;
LS@LEO> select * from leo_text_t1;
ID NAME
---------- ----------
1 Tom
2 Tom Tom
1 Tom
2 Tom Tom
我们在创建一个表，并在name字段上创建全文索引
create table leo_text_t2 as select * from leo_text_t1;
创建全文索引的前提
ORACLE10g 创建全文索引过程：
1,首先查看ORACLE是否已安装“全文检索工具”
通过查看是否存在CTXSYS 用户，CTXAPP角色即可判断。
LS@LEO> select username from dba_users;
USERNAME
------------------------------
LS
CTXSYS 默认是没有的，需要安装2个脚本catctx.sql，drdefus.sql 2,如果ORACLE没有安装“全文检索工具”，则使用以下步骤手工安装。
a)进入ORACLE安装目录
cd $ORACLE_HOME
b)使用DBA 角色登陆数据库
sqlplus sys/sys as sysdba
c)查看表空间文件存放路径
select name from v$datafile;
d)为CTXSYS 用户创建表空间
CREATE TABLESPACE ctxsys
LOGGING
DATAFILE '/u01/app/oracle/oradata/LEO/file1/ctxsys01.dbf' SIZE 32m
AUTOEXTEND ON
NEXT 32m MAXSIZE 2048m
EXTENT MANAGEMENT LOCAL ;
e)创建CTXSYS 用户，创建CTXAPP 角色
@?/ctx/admin/catctx.sql ctxsys ctxsys temp1 nolock
--(密码、表空间、临时表空间、用户状态)
--如果当前sql脚本无执行权限，请手工添加。
f)为CTXSYS 执行初始化工作，如果没有此操作，后续操作会失败。
connect ctxsys/ctxsys;
@?/ctx/admin/defaults/drdefus.sql
3,创建全文索引
a)创建词法分析器及相关表
--词法分析器
execute ctx_ddl.create_preference('offerProdAddrLexer','CHINESE_LEXER');
--词法
execute ctx_ddl.create_preference('offerProdAddrList', 'BASIC_WORDLIST');
execute ctx_ddl.set_attribute('offerProdAddrList','PREFIX_INDEX','TRUE');
execute ctx_ddl.set_attribute('offerProdAddrList','PREFIX_MIN_LENGTH',1);
execute ctx_ddl.set_attribute('offerProdAddrList','PREFIX_MAX_LENGTH', 5);
execute ctx_ddl.set_attribute('offerProdAddrList','SUBSTRING_INDEX', 'YES');
b)创建全文索引
LS@LEO> conn ctxsys/ctxsys
Connected.
CTXSYS@LEO> create index ls.leo_text_t2_text_index on ls.leo_text_t2(name) indextype is ctxsys.context;
CTXSYS@LEO> conn ls/ls
Connected.
LS@LEO> set autotrace on;
LS@LEO> select * from leo_text_t1 where name like '%Tom%';
ID NAME
---------- ----------
1 Tom
2 Tom Tom
1 Tom
2 Tom Tom
Execution Plan 执行计划
----------------------------------------------------------
Plan hash value: 3687902158
---------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4 | 80 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| LEO_TEXT_T1 | 4 | 80 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------
全表扫描，cpu使用率3%
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("NAME" LIKE '%Tom%')
Note
-----
- dynamic sampling used for this statement动态采样
Statistics 统计信息
----------------------------------------------------------
56 recursive calls
0 db block gets
23 consistent gets 全表扫描没有使用B-tree索引，导致23次一致性读
0 physical reads
0 redo size
538 bytes sent via SQL*Net to client
381 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
4 rows processed
LS@LEO> select * from leo_text_t2 where contains(name,'Tom')>0;
ID NAME
---------- ----------
1 Tom
2 Tom Tom
1 Tom
2 Tom Tom
Execution Plan 执行计划
----------------------------------------------------------
Plan hash value: 2789465217
-----------------------------------------------------------------------------------------------------
-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 32 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| LEO_TEXT_T2 | 1 | 32 | 4 (0)| 00:00:01 |
|* 2 | DOMAIN INDEX | LEO_TEXT_T2_TEXT_INDEX | | | 4 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("CTXSYS"."CONTAINS"("NAME",'Tom')>0)
Note
-----
- dynamic sampling used for this statement动态采样
Statistics 统计信息
----------------------------------------------------------
11 recursive calls
0 db block gets
19 consistent gets
0 physical reads
0 redo size
545 bytes sent via SQL*Net to client
381 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4 rows processed
小结：从如上实验来看，当我们检索大量文字的时候使用全文索引要比全表扫描快很多了，有弊就有利，
由于全文索引会占用大量空间提前预估全文索引大小保留出足够的空间，context类型全文索引不是基于事务的，无法保证索引和数据实时同步，DML完成后，如果在全文索引中查不到键值时，可以通过手工or定时任务来刷新同步，而B-tree、位图都是实时的。
总结：本次实验了B-tree 位图全文三大索引的性能，同时比较了各自适合场合和用途，还总结了各自的优缺点，由于水平有限有不足之处还请大家指点。
使用Oracle全文索引搜索文本
使用Oracle全文索引搜索文本 不使用Oracle text功能,也有很多方法可以在Oracle数据库中搜索文本.可以使用标准的INSTR 函数和LIKE操作符实现。 SELECT *FROM mytext WHERE INSTR (thetext, 'Oracle') > 0; SELECT * FROM mytext WHERE thetext LIKE '%Oracle%'; 有很多时候，使用instr和like是很理想的, 特别是搜索仅跨越很小的表的时候.然而通过这些文本定位的方法将导致全表扫描,对资源来说消耗比较昂贵,而且实现的搜索功能也非常有限，因此对海量的文本数据进行搜索时，建议使用oralce提供的全文检索功能建立全文检索的步骤步骤一检查和设置数据库角色首先检查数据库中是否有CTXSYS用户和CTXAPP脚色。如果没有这个用户和角色，意味着你的数据库创建时未安装intermedia功能。你必须修改数据库以安装这项功能。默认安装情况下，ctxsys用户是被锁定的，因此要先启用ctxsys 的用户。步骤二赋权在ctxsys用户下把ctx_ddl的执行权限赋于要使用全文索引的用户，例： grant execute on ctx_ddl to pomoho; 步骤三设置词法分析器(lexer) Oracle实现全文检索，其机制其实很简单。即通过Oracle专利的词法分析器(lexer),将文章中所有的表意单元(Oracle 称为term)找出来，记录在一组以dr$开头的表中，同时记下该term 出现的位置、次数、hash 值等信息。检索时，Oracle 从这组表中查找相应的term，并计算其出现频率，根据某个算法来计算每个文档的得分(score),即所谓的‘匹配率’。而lexer则是该机制的核心，它决定了全文检索的效率。Oracle 针对不同的语言提供了不同的lexer, 而我们通常能用到其中的三个： n basic_lexer: 针对英语。它能根据空格和标点来将英语单词从句子中分离，还能自动将一些出现频率过高已经失去检索意义的单词作为‘垃圾’处理，如if , is 等，具有较高的处理效率。但该lexer应用于汉语则有很多问题，由于它只认空格和标点，而汉语的一句话中通常不会有空格，因此，它会把整句话作为一个term,事实上失去检索能力。以‘中国人民站起来了’这句话为例，basic_lexer 分析的结果只有一个term ,就是‘中国人民站起来了’。此时若检索‘中国’，将检索不到内容。 n chinese_vgram_lexer: 专门的汉语分析器，支持所有汉字字符集(ZHS16CGB231280 ZHS16GBK ZHT32EUC ZHT16BIG5 ZHT32TRIS ZHT16MSWIN950 ZHT16HKSCS UTF8 )。该分析器按字为单元来分析汉语句子。‘中国人民站起来了’这句话，会被它分析成如下几个term: ‘中’，‘中国’，‘国人’，‘人民’，‘民站’，‘站起’，起来’，‘来了’，‘了’。可以看出，这种分析方法，实现算法很简单，并且能实现‘一网打尽’，但效率则是差强人意。 n chinese_lexer: 这是一个新的汉语分析器，只支持utf8字符集。上面已经看到，chinese vgram lexer这个分析器由于不认识常用的汉语词汇，因此分析的单元非常机械，像上面的‘民站’，‘站起’在汉语中根本不会单独出现，因此这种term是没有意义的，反而影响效率。chinese_lexer的最大改进就是该分析器能认识大部分常用汉语词汇，因此能更有效率地分析句子，像以上两个愚蠢的单元将不会再出现，极大提高了效率。但是它只支持utf8, 如果你的数据库是zhs16gbk字符集，则只能使用笨笨的那个Chinese vgram lexer. 如果不做任何设置，Oracle 缺省使用basic_lexer这个分析器。要指定使用哪一个lexer, 可以这样操作： 第一．当前用户下下建立一个preference(例：在pomoho用户下执行以下语句) exec ctx_ddl.create_preference ('my_lexer', 'chinese_vgram_lexer');
平面设计模拟试题
第七届全国信息技术应用水平大赛模拟题 平面设计 注：试卷满分150 分，完成时间180 分钟。此模拟题仅供参考，具体题型、题量与分值分配以实际预赛题 为准。 单选题（共60 题，每题 1 分，共60 分） 1. 在Photoshop 中，快速切换工具箱前景色和背景色的快捷键是（ D ）。 A: Ctrl+D 键 B: Ctrl+S 键 C:Ctrl+T 键 D: X 键 2. 使用【矩形选框工具】时，如果在其工具属性栏选项为系统默认设置的情况下，按住键盘中（ A ）键可以绘制正方形选区。 A: Shift B: Alt C:Ctrl D: Ctrl +Alt 3. 使用【涂抹工具】时，如果勾选其工具属性栏中的【手指绘画】复选框，该工具将会在涂抹的过 程中加入（ D ），相当于将手指沾着颜色进行涂抹。 A: 背景色 B: 黑色 C: 白色 D: 前景色 4. 通过下列（ A ）方法不能打开【画笔】控制面板。 A: 敲击键盘中的F6 键 B: 执行【窗口】︱【画笔】命令
C: 单击任意绘图工具属性栏中的按钮 D: 敲击键盘中的F5 键 5. 图像的变换操作是Photoshop 图像处理的常用操作之一，下列（ C ）命令可以一次性实现图像多种变换效果。 A: 【画布大小】 B: 【变换选区】 C: 【自由变换】 D: 【图像大小】 6. 在路径形态调整过程中，如果要单独选择路径上的某一节点，可以使用（ C ）工具来实现。A: 【钢笔工具】 B: 【添加锚点工具】 C: 【直接选择工具】 D: 【路径选择工具】 7. 在Photoshop 众多的图层类型中，可以从整体上调整图像的明暗及色相饱和度的图层是（ B ）。A: 文字图层 B: 新调整图层 C: 形状图层 D: 背景图层 8. 当在Photoshop 内改变了（比如缩小）图像分辨率的时候，图片的信息量和清晰度却没有变化，可能的 原因是（B ）。 A: 在【图像大小】对话框中改变分辨率时，勾选了【重定图像像素】选项 B: 在【图像大小】对话框中改变分辨率时，没有勾选【重定图像像素】选项 C: 减小分辨率对图像清晰度的影响不大 D: 在【画布大小】对话框中改变分辨率时，没有勾选【重定图像像素】选项
浅谈MySQL索引分析和优化
MySQL索引分析和优化列：
由于索引文件以B-树格式保存，MySQL能够立即转到合适的firstname，然后再转到合适的lastname，最后转到合适的age。在没有扫描数据文件任何一个记录的情况下，MySQL就正确地找出了搜索的目标记录！ 那么，如果在firstname、lastname、age这三个列上分别创建单列索引，效果是否和创建一个firstname、lastname、age的多列索引一样呢？答案是否定的，两者完全不同。当我们执行查询的时候，MySQL只能使用一个索引。如果你有三个单列的索引，MySQL会试图选择一个限制最严格的索引。但是，即使是限制最严格的单列索引，它的限制能力也肯定远远低于firstname、lastname、age这三个列上的多列索引。
下面我们就来看看这个EXPLAIN分析结果的含义。 table：这是表的名字。 type：连接操作的类型。下面是MySQL文档关于ref连接类型的说明： “对于每一种与另一个表中记录的组合，MySQL将从当前的表读取所有带有匹配索引值的记录。如果连接操作只使用键的最左前缀，或者如果键不是UNIQUE或PRIMARY KEY类型（换句话说，如果连接操作不能根据键值选择出唯一行），则MySQL使用ref连接类型。如果连接操作所用的键只匹配少量的记录，则ref是一种好的连接类型。” 在本例中，由于索引不是UNIQUE类型，ref是我们能够得到的最好连接类型。 如果EXPLAIN显示连接类型是“ALL”，而且你并不想从表里面选择出大多数记录，那么MySQL的操作效率将非常低，因为它要扫描整个表。你可以加入更多的索引来解决这个问题。预知更多信息，请参见MySQL的手册说明。 possible_keys： 可能可以利用的索引的名字。这里的索引名字是创建索引时指定的索引昵称；如果索引没有昵称，则默认显示的是索引中第一个列的名字（在本例中，它是“firstname”）。默认索引名字的含义往往不是很明显。 Key：它显示了MySQL实际使用的索引的名字。如果它为空（或NULL），则MySQL不使用索引。 key_len：索引中被使用部分的长度，以字节计。在本例中，key_len是102，其中firstname 占50字节，lastname占50字节，age占2字节。如果MySQL只使用索引中的firstname部分，则key_len将是50。 ref：它显示的是列的名字（或单词“const”），MySQL将根据这些列来选择行。在本例中，MySQL根据三个常量选择行。 rows：MySQL所认为的它在找到正确的结果之前必须扫描的记录数。显然，这里最理想的数字就是1。 Extra：这里可能出现许多不同的选项，其中大多数将对查询产生负面影响。在本例中，MySQL 只是提醒我们它将用WHERE子句限制搜索结果集。 索引的缺点 到目前为止，我们讨论的都是索引的优点。事实上，索引也是有缺点的。 首先，索引要占用磁盘空间。通常情况下，这个问题不是很突出。但是，如果你创建每一种可能列组合的索引，索引文件体积的增长速度将远远超过数据文件。如果你有一个很大的表，索引文件的大小可能达到操作系统允许的最大文件限制。 第二，对于需要写入数据的操作，比如DELETE、UPDATE以及INSERT操作，索引会降低它们的速度。这是因为MySQL不仅要把改动数据写入数据文件，而且它还要把这些改动写入索引文件。 【结束语】在大型数据库中，索引是提高速度的一个关键因素。不管表的结构是多么简单，一次500000行的表扫描操作无论如何不会快。如果你的网站上也有这种大规模的表，那么你确实应该花些时间去分析可以采用哪些索引，并考虑是否可以改写查询以优化应用。要了解更多信息，请参见MySQL manual。另外注意，本文假定你所使用的MySQL是3.23版，部分查询不能在3.22版MySQL上执行。
索引存储及使用原理
clustering_factor 是表征表中数据的存储顺序和某索引字段顺序的符合程度。 一、索引的存储结构 索引是一种允许直接访问数据表中某一数据行的树型结构，为了提高查询效率而引入，是一个独立于表的对象，可以存放在与表不同的表空间中。索引记录中存有索引关键字和指向表中数据的指针（地址）。对索引进行的I/O 操作比对表进行操作要少很多。索引一旦被建立就将被Oracle系统自动维护，查询语句中不用指定使用哪个索引。 分类可以按逻辑设计和物理实现来分类。 索引逻辑分类 单列索引：基于一列的操作 多列索引：组合索引，最多为32列。组合索引的列不一定与表中列顺序相同。 惟一索引：列的值各不相同。 非惟一索引：列的值允许相同。 基于函数的惟一索引：利用表中一列或多列基于函数表达式所创建的索引。既可以是B-树，也可以是位图索引。 索引物理分类 分区或非分区索引，非分区既可以是B－树，也可以是位图索引。 B-树：包括正常或反转关键字索引，反转关键字在数据库优化中介绍。 位图索引 B-树索引 索引的存储方式
虽然所有索引都使用B 树结构，但术语“B 树索引”通常与存储每个关键字的行标识列表的索引关联。 B 树索引结构 至上而下，是根结点、分枝结点及叶子结点，叶子结点中有指向表中数据行的索引行。叶子结点被双向链表在一起，以方便按索引关键字升序或降序扫描。 索引的顶部为根，其中包含指向索引中下一级的项，下一级为分枝块，分枝块又指向索引中下一级的块，最低一级为叶节点，其中包含指向表行的索引项。叶块为双重链接，有助于按关键字值的升序和降序扫描索引。 索引项叶节点的格式 索引项由以下三部分组成： ? 项标题（entry header），存储列数和锁定信息 ? 关键字列的“长度- 值”(length-value pairs) ，必需成对出现，定义了列长度，紧跟在列长度之后的就是列的值。 ? 行的行标识（RowID），包含关键字值。 索引项叶结点的特征 在非分区表上的B 树索引中： ? 如果多行具有相同的关键字值，并且索引没有被压缩，则关键字值重复存放。 ? 没有索引项与所有关键字列都为NULL 的行对应，即如果某列值为Null，则不存储相应的索引项。如果Where子句中索引的所在列值为null，Oracle将不使用索引进行全表扫描。 ? 因为所有行都属于同一段，所以使用受限行标识指向表中的行，使用RowID可以节省索引存储空间。 DML 操作对索引的影响 当在表上执行DML 操作时，Oracle 服务器将自动维护所有的索引，下面解释DML命令对索引的影响： ? 插入（Insert）操作导致在适当的块中插入索引项。 ? 删除（Delete）行只导致逻辑删除索引项，删除的行所用的空间不能用于新项，直到删除块中的所有项。 ? 更新（Update）操作将选删除，再插入，除了在创建时，其它任何时候PCTFREE 设置对索引都没有影响，即使索引块空间少于PCTFREE 指定的空间，仍可以向索引块添加新项。 二、查询使用索引探索： §1.1 简介 本文简要介绍了CBO成本计算的基本原理，并初步解释了初始化参数optimizer_index_cost_adj和db_file_multiblock_read_count对CBO的影响。 数据库版本为Oracle 9.0.1 平台为Windows2000 system@FXSB01> select *from v$version; BANNER ---------------------------------------------------------------- Oracle9i Enterprise Edition Release 9.0.1.1.1 - Production PL/SQL Release 9.0.1.1.1 - Production CORE 9.0.1.1.1 Production TNS for 32-bit Windows: Version 9.0.1.1.0 - Production NLSRTL Version 9.0.1.1.1 – Production
一种基于Lucene的中文全文检索系统
—94— 一种基于Lucene 的中文全文检索系统 苏潭英1，郭宪勇2，金 鑫3 （1. 解放军信息工程大学电子技术学院，郑州 450004；2. 北京飞燕技术公司，北京 100072；3. 解放军通信指挥学院，武汉 430010）摘 要：在开源全文索引引擎Lucene 的基础上，设计了一个中文全文检索系统模型，该模型系统由7个模块组成，索引模块、检索模块是其中的核心部分。论述了模型的整体结构，分析设计了索引及检索模块，通过具体的索引技术和检索技术来提高整个系统的检索效率。该系统增加了加密模块，实现对建立的全文索引进行加密处理，增强了信息的安全性。 关键词：全文检索；Lucene ；倒排索引 Chinese Full-text Retrieval System Based on Lucene SU Tan-ying 1, GUO Xian-yong 2, JIN Xin 3 (1. Institute of Electronic Technology, PLA Information Engineering University, Zhengzhou 450004; 2. Technology Company of Beijing Feiyan, Beijing 100072; 3. Institute of PLA Communication Command, Wuhan 430010) 【Abstract 】This paper proposes a model of Chinese full-text retrieval system based on Lucene which is an open source full-text retrieval engine,and expatiates its frame. This model is composed of seven modules, among which the index module and the search module are the core parts. It designs them concretely, and improves the search efficiency of the full-text retrieval system with index technology and search technology. The system model concludes an encryption module to encrypt the index and increases the system security. 【Key words 】full-text retrieval; Lucene; inverse index 计 算 机 工 程Computer Engineering 第33卷 第23期 Vol.33 No.23 2007年12月 December 2007 ·软件技术与数据库· 文章编号：1000—3428(2007)23—0094—03 文献标识码：A 中图分类号：TP391 1 中文全文检索系统 全文检索技术是一个最普遍的信息查询应用，人们每天在网上使用Google 、百度等搜索引擎查找自己所需的信息，这些搜索引擎的核心技术之一就是全文检索。随着文档处理电子化、无纸化的发展，图书馆、新闻出版、企业甚至个人的电子数据激增，如何建立数据库、管理好自己的数据，是亟待解决的问题，而全文检索是其中一个非常实用的功能。全文检索产品实际上是一个内嵌该项技术的数据库产品[1]。 西文的全文检索已有许多成熟的理论与方法，其中，开放源代码的全文检索引擎Lucene 是Apache 软件基金会Jakarta 项目组的一个子项目，它的目的是为软件开发人员提供一个简单易用的工具包，方便在目标系统中实现全文检索的功能。很多项目使用了Lucene 作为其后台的全文索引引擎，比较著名的有： (1)Jive ：Web 论坛系统； (2)Cocoon ：基于XML 的Web 发布框架，全文检索部分使用了Lucene ； (3)Eclipse ：基于Java 的开放开发平台，帮助部分的全文索引使用了Lucene 。 Lucene 不支持中文，但可以通过扩充它的语言分析器实现对中文的检索。本文在深入学习研究Lucene 的前提下，设计了一个中文的全文检索系统，对其核心的索引模块和检索模块进行了阐释，并添加了加密模块对索引信息加密，增强了系统的安全性。 2 系统的总体结构 本模型总体上采用了Lucene 的架构。Lucene 的体系结构如表1所示，它的源代码程序由7个模块组成。 表1 Lucene 的组成结构 模块名 功能 org.apache.Lucene.search 搜索入口 org.apache.Lucene.index 索引入口 org.apache.Lucene.analysis 语言分析器 org.apache.Lucene.queryParser 查询分析器 org.apache.Lucene.document 存储结构 org.apache.Lucene.store 底层IO/存储结构 org.apache.Lucene.util 一些公用的数据结构 本文通过扩充Lucene 系统来完成中文的全文检索系统，Lucene 包含了大量的抽象类、接口、文档类型等，需要根据具体应用来定义实现，本文对其作了如下扩充修改： (1)按照中文的词法结构来构建相应的语言分析器。Lucene 的语言分析器提供了抽象的接口，因此，语言分析(analyser)是可以定制的。Lucene 缺省提供了2个比较通用的分析器SimpleAnalyser 和StandardAnalyser ，但这2个分析器缺省都不支持中文，因此，要加入对中文语言的切分规则，需要对其进行修改。 (2)按照被索引的文件的格式对不同类型的文档进行解析，进而建立全文索引。例如HTML 文件，通常需要把其中的内容分类加入索引，这就需要从org.apache.lucene.子document 中定义的类Document 继承，定义自己的HTMLDocument 类，然后将之交给org. apache.lucene.index 模块写入索引文件。Lucene 没有规定数据源的格式，只提供 作者简介：苏潭英(1981－)，女，硕士研究生，主研方向：数据库全文检索；郭宪勇，高级工程师；金 鑫，硕士研究生 收稿日期：2007-01-10 E-mail ：sutanyingwendy@https://www.wendangku.net/doc/9210349693.html,
搜索引擎
搜索引擎简介 专业:智能1001 学号:06103008 姓名:周树亮
搜索引擎 有人说，会搜索才叫会上网，搜索引擎在我们日常生活中的地位已是举足轻重。 你也许是个刚要兴冲冲地要上网冲浪，也许已经在互联网上蛰伏了好几年，无论怎样，要想在浩如烟海的互联网信息中找到自己所需的信息，都需要一点点技巧。 对于企业而言，学习搜索，提高技巧，就能找到更多的潜在客户。对于大家而言，学习搜索引擎技巧可以有助我们的学习和生活！ 一、搜索引擎含义由来及发展历史 1、搜索引擎（search engines）px+no2end px 是对互联网上的信息资源进行搜集整理，然后供你查询的系统，它包括信息搜集、信息整理和用户查询三部分。 搜索引擎是一个为你提供信息“检索”服务的网站，它使用某些程序把因特网上的所有信息归类以帮助人们在茫茫网海中搜寻到所需要的信息。 早期的搜索引擎是把因特网中的资源服务器的地址收集起来，由其提供的资源的类型不同而分成不同的目录，再一层层地进行分类。人们要找自己想要的信息可按他们的分类一层层进入，就能最后到达目的地，找到自己想要的信息。这其实是最原始的方式，只适用于因特网信息并不多的时候。随着因特网信息按几何式增长，出现了真正意义上的搜索引擎，这些搜索引擎知道网站上每一页的开始，随后搜索因特网上的所有超级链接，把代表超级链接的所有词汇放入一个数据库。这就是现在搜索引擎的原型。 2.搜索引擎发展史 在互联网发展初期，网站相对较少，信息查找比较容易。然而伴随互联网爆炸性的发展，普通网络用户想找到所需的资料简直如同大海捞针，这时为满足大众信息检索需求的专业搜索网站便应运而生了。现代意义上的搜索引擎的祖先，是1990年由蒙特利尔大学学生Alan Emtage发明的Archie。虽然当时World Wide Web还未出现，但网络中文件传输还是相当频繁的，而且由于大量的文件散布在各个分散的FTP主机中，查询起来非常不便，因此Alan Emtage想到了开发一个可以以文件名查找文件的系统，于是便有了Archie。Archie工作原理与现在的搜索引擎已经很接近，它依靠脚本程序自动搜索网上的文件，然后对有关信息进行索引，供使用者以一定的表达式查询。由于Archie深受用户欢迎，受其启发，美国内华达System Computing Services 大学于1993年开发了另一个与之非常相似的搜索工具，不过此时的搜索工具除了索引文件外，已能检索网页。当时，“机器人” 一词在编程者中十分流行。 二、搜索引擎介绍及其使用技巧 人们经常问我搜索技巧，虽然要成为一个搜索专家远非学几条技巧那么简单，但确实有些精彩的搜索技巧能够极大的提高你的搜索能力，帮你成为不错的网络侦探。 这里是我的十条最精华的搜索技巧，它们大致分为基础技巧、通用搜索策略、以及何时使用专业搜索工具的建议。 每一个搜索都是不同的，如果你为每一个搜索都选择最好的搜索工具，那么每次你都会得到最好的搜索结果。最常见的选择是使用全文搜索引擎还是网站分类目录。 一般的规则是，如果你在找什么特殊的内容或文件，那么使用全文搜索引擎如google和altavista，如果你想从总体上或比较全面的了解一个主题，那么使用网站分类目录如yahoo和odp。 对于特殊类型的信息考虑使用特殊的搜索工具，比如你要找人或找地点，那么使用专业的寻人引擎或地图和位置搜索网站。 事实上几乎每种主题都有特殊的搜索工具。 如果有个陌生人跑过来对你说"anchovy paste!" 或 "sibberidge!" ，你会有什么反映呢？大多数人会笑，或者询问那个人到底想说什么。可是搜索引擎无法作出这种选择——它们只能猜测你的问题，然后提供它们利用这有限的信息能够得到的最好结果。 好的搜索请求应该包含多个能限制搜索范围的关键词。 多数搜索引擎对自然语言的处理很好。事实上，搜索引擎能够从语句结构得到很有用的信息，不会象仅得到几个关键词那样容易迷失。 与其输入几个不合语法的关键词，还不如试一下一句自然的提问。与其搜索“北京公交车路线”，不如试一下 "我在北京如何乘坐公交车？"
SQL Server 全文索引查询
SQL Server 全文索引查询T-SQL学习笔记之一(Full-text index) 2009-12-11 11:29 引言 这段时间为了提高海量字符串数据的查询效率，我对字段添加了全文索引。首先全文索引相对于传统的索引是有区别的，这是因为传统的索引主要是以首字母开始建立的索引，处理like 'keword%'这样的查询会很高效，但是如果查询时不限定首字母，而只是包含某个词，比如like '%keyword%'这样的查询，实际操作中无法使用传统索引加速查询效率，而只能一项一项比较了。 而全文索引正是提供了“包含”式查询机制，查询一个长字符串中是否包含给定关键词的功能，这无论是在搜索引擎或是网站的搜索平台都是很有用处的。 首先，推荐一本学习SQL Server全文索引的书籍，这本书详细的讲解了全文索引的方方面面，甚至还阐述许多设计搜索引擎的思想和方法。书名是《Pro Full-Text Search in SQL Server 2008》，是Apress出版的。 这本书的内容是按章划分的，同时由浅入深，从一般的技巧到高级的技巧。我这里就简单分享一下基本的全文查询方法，更多高级的技巧应该在实际应用中按需进行学习。 要实现全文查询，首先安装的SQL Server实例要支持全文查询服务，可以查看windows服务是否有全文索引服务。如果没有，则要重新安装SQL Server并选择添加功能，将Full-Text功能选中，然后再安装或升级。
有了全文查询服务，还不能直接进行查询，需要先在想要建立全文索引的字段上建立一个全文索引。方法是打开企业管理器，选择字段所在表格，然后点击右键，选择"Full-text inde”，然后选择"define Full-text index"就能进入设置面板。 需要注意的是，全文索引只能建立在Unique（唯一）字段上，并且每个表最多只能有一个全文索引字段，因此要慎重。然后按照提示建立全文索引即可（可以参见我推荐的那本书，会有一步一步操作的详细说明和注释） 建立好全文索引后，就能够运用T-SQL的全文查询语法进行全文查询了。 主要有两个语法，一个是contains，另一个是freetext Contains contains从字面上就能很好理解，即包含，比如我们在表Sample的一个字段Column里查询包含“世界末日”这个关键词的所有记录，该表一共有60万条记录，传统的查询语法是 select * from Sample where [Column] like '%世界末日%'
mysql性能优化-慢查询分析、优化索引和配置
mysql性能优化-慢查询分析、优化索引和配置目录 一、优化概述 二、查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三、配置优化 1) max_connections 2) back_log 3) interactive_timeout 4) key_buffer_size 5) query_cache_size 6) record_buffer_size 7) read_rnd_buffer_size 8) sort_buffer_size 9) join_buffer_size 10) table_cache 11) max_heap_table_size 12) tmp_table_size
13) thread_cache_size 14) thread_concurrency 15) wait_timeout 一、优化概述 MySQL数据库是常见的两个瓶颈是CPU和I/O的瓶颈，CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候。磁盘I/O瓶颈发生在装入数据远大于内存容量的时候，如果应用分布在网络上，那么查询量相当大的时候那么平瓶颈就会出现在网络上，我们可以用mpstat, iostat, sar和vmstat来查看系统的性能状态。 除了服务器硬件的性能瓶颈，对于MySQL系统本身，我们可以使用工具来优化数据库的性能，通常有三种：使用索引，使用EXPLAIN分析查询以及调整MySQL的内部配置。 二、查询与索引优化分析 在优化MySQL时，通常需要对数据库进行分析，常见的分析手段有慢查询日志，EXPLAIN 分析查询，profiling分析以及show命令查询系统状态及系统变量，通过定位分析性能的瓶颈，才能更好的优化数据库系统的性能。 1 性能瓶颈定位 Show命令 我们可以通过show命令查看MySQL状态及变量，找到系统的瓶颈： Mysql> show status ——显示状态信息（扩展show status like ‘XXX’） Mysql> show variables ——显示系统变量（扩展show variables like ‘XXX’） Mysql> show innodb status ——显示InnoDB存储引擎的状态 Mysql> show processlist ——查看当前SQL执行，包括执行状态、是否锁表等
搜索引擎论文
搜索引擎发展状态及未来趋势 【摘要】 搜索引擎包括图片搜索引擎、全文索引、目录索引等，其发展历史可分为五个阶段，目前企业搜索引擎和网站运营搜索引擎运用范围较广。在搜索引擎的未来发展中，呈现出个性化，多元化，智能化，移动化，社区化等多个趋势。 【关键词】 发展起源、索引、数据库、网站运营、未来趋势 【参考文献】 《个性化搜索引擎原理与技术》《搜索引擎的设计与实现》搜索引擎是指根据一定的策略、运用特定的计算机程序从互联网上搜集信息，在对信息进行组织和处理后，为用户提供检索服务，将用户检索相关的信息展示给用户的系统。其工作作原理分为抓取网页，处理网页和提供检索服务。抓取每个独立的搜索引擎都有自己的网页抓取程序，它顺着网页中的超链接，连续地抓取网页。由于互联网中超链接的应用很普遍，理论上，从一定范围的网页出发，就能搜集到绝大多数的网页。搜索引擎抓到网页后，还要做大量的预处理工作，才能提供检索服务。其中，最重要的就是提取关键词，建立索引文件。 搜索引擎的发展起源可以追溯到第一个Gopher搜索工具Veronica。后来的搜索引擎的发展分为五个阶段。第一阶段，出现World wide Web Wanderer，用于追踪互联网发展规模。刚开始它只用来统
计互联网上的服务器数量，后来则发展为也能够捕获网址。第二阶段，出现了以概念搜索闻名的Excite以及元搜索引擎Dogpile。第三阶段，即yahoo的出现。随着访问量和收录链接数的增长，Yahoo目录开始支持简单的数据库搜索。Yahoo以后陆续有Google等提供搜索引擎服务，但不可否认的是，Yahoo几乎成为20世纪90年代的因特网的代名词。第四阶段，一种新的搜索引擎形式出现了，即元搜索引擎。用户只需提交一次搜索请求，由元搜索引擎负责转换处理后提交给多个预先选定的独立搜索引擎，并将从各独立搜索引擎返回的所有查询结果，集中起来处理后再返回给用户。第五阶段的代表是智能检索的产生：它利用分词词典、同义词典，同音词典改善检索效果，进一步还可在知识层面或者说概念层面上辅助查询，给予用户智能知识提示，最终帮助用户获得最佳的检索效果。 搜索引擎目前包括图片搜索引擎、全文索引、目录索引、元搜索引擎、垂直搜索引擎等。全文索引引擎是名副其实的搜索引擎，国外代表有Google，国内有百度、搜狐等。它们从互联网提取各个网站的信息，建立起数据库，并能检索与用户查询条件相匹配的记录，按一定的排列顺序返回结果。搜索引擎的自动信息搜集功能分为定期搜索和提交网站搜索。它的特点是搜全率比较高。目录索引，就是将网站分门别类地存放在相应的目录中，因此用户在查询信息时，可选择关键词搜索，也可按分类目录逐层查找。与全文搜索引擎相比，目录索引有许多不同之处。首先，搜索引擎属于自动网站检索，而目录索引则完全依赖手工操作。其次，搜索引擎收录网站时，只要网站本身
数据库及SQL代码优化方案
1.1、数据库及SQL代码优化方案 （1）每周检查统计信息是否及时更新。 （2）每周检查各索引是否有效。 （3）每周检查分区是否正确。 （4）每周检查执行计划是否正确。 （5）每天检查RAC和ASM是否正常运行。 （6）每天检查相关日志是否正常备份。 （7）每天检查相关文件系统和表空间的占用率是否在国家税务总局规定的阀值以下。 （8）在每月申报高峰等业务繁忙期采样并找出消耗I/O资源和CPU资源较多的SQL语句。 （9）分析上述SQL语句，与软件服务商充分沟通后，提出优化建议。 （10）在每月申报高峰期每隔15分钟检查一次数据库连接数，发现异常及时处理。 1.1.1、系统数据库索引、表分区和对象优化方案 数据库对象的优化主要包括：表、索引和sequence等对象，通过优化对象参数、调整对象属性（例如分区表、分区索引、反转索引等等）等方法来实现对数据库对象的优化改造。 1.1.1.1表和索引并行参数优化 数据库的表和索引的并行参数值的设置对相关的sql语句的执行计划会造成影响，表和索引的degree值大于1，执行计划就偏向于使用全表和全索引扫描，另外如果并行参数值过大，短时间内也会对主机和数据库的资源造成很大的压力，因此在oltp的数据库下建议将表和索引的degree值设为1。 1.1.1.2热点大表的分区改造 对访问量很大、表的记录数很多、存在热块争用的表，可以考虑对表和索引进行适当的分区改造，分散访问压力，提高数据访问的性能。 对以下表的记录数超过1000万并且记录数持续增长的大表，建议进行分区
改造（地区+时间）： 1.1.1.3分区索引的清理 对最近30天数据库分区索引访问情况进行统计，对访问次数为0的分区索引和应用部门进行确认，若确认为多余的索引，建议进行删除清理。 1.1.1.4Sequence序列优化 加大sequence 的 cache，并使用noorder选项。在RAC中经常会遇到SQ 锁等待，这是因为在RAC环境下，sequence也成为全局性的了，不同节点要生成序列号，就会产生对sequence资源的争用。而目前大多数系统中，sequence 大多数被作为主键发生器来使用，使用的频率十分高，在RAC环境中，需要设置较大的 sequence cache，否则会造成较为严重的争用，从而影响业务。 1.1.2、SQL硬解析优化方案 1.1. 2.1相关知识点介绍 1.1. 2.1.1Oracle的硬解析和软解析 Oracle对sql的处理过程：当发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程： 1、语法检查(syntax check) 检查此sql的拼写是否语法。 2、语义检查(semantic check) 诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。 3、对sql语句进行解析(prase) 利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。 4、执行sql，返回结果(execute and return) 其中，软、硬解析就发生在第三个过程里。 Oracle利用内部的hash算法来取得该sql的hash值，然后在library cache
全文检索功能
在应用中加入全文检索功能 ——基于java的全文索引引擎lucene简介 作者：车东 email: https://www.wendangku.net/doc/9210349693.html,/https://www.wendangku.net/doc/9210349693.html, 写于：2002/08 最后更新： 版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明 https://www.wendangku.net/doc/9210349693.html,/tech/lucene.html 关键词：lucene java full-text search engine chinese word segment 内容摘要： lucene是一个基于java的全文索引工具包。 1.基于java的全文索引引擎lucene简介：关于作者和lucene的历史 2.全文检索的实现：luene全文索引和数据库索引的比较 3.中文切分词机制简介：基于词库和自动切分词算法的比较 4.具体的安装和使用简介：系统结构介绍和演示 5.hacking lucene：简化的查询分析器，删除的实现，定制的排序，应用接口的扩展 6.从lucene我们还可以学到什么 基于java的全文索引/检索引擎——lucene lucene不是一个完整的全文索引应用，而是是一个用java写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。 lucene的作者：lucene的贡献者doug cutting是一位资深全文索引/检索专家，曾经是v-twin搜索引擎(apple的copland操作系统的成就之一)的主要开发者，后在excite担任高级系统架构设计师，目前从事于一些internet底层架构的研究。他贡献出的lucene的目标是为各种中小型应用程序加入全文检索功能。 lucene的发展历程：早先发布在作者自己的https://www.wendangku.net/doc/9210349693.html,，后来发布在sourceforge，2001年年底成为apache基金会jakarta的一个子项目：https://www.wendangku.net/doc/9210349693.html,/lucene/ 已经有很多java项目都使用了lucene作为其后台的全文索引引擎，比较著名的有： ?jive：web论坛系统； ?eyebrows：邮件列表html归档/浏览/查询系统，本文的主要参考文档“thelucene search engine: powerful, flexible, and free”作者就是eyebrows系统的主要开发者之一，而eyebrows已 经成为目前apache项目的主要邮件列表归档系统。 ?cocoon:基于xml的web发布框架，全文检索部分使用了lucene ?eclipse:基于java的开放开发平台，帮助部分的全文索引使用了lucene
PLSQL编写规范v
3. 基本策略 3.1 设计策略 分类拆分数据量大的表。 对于经常使用的表（如某些参数表或代码对照表），由于其使用频率很高，要尽量减少表中的记录数量。例如，银行的户主账表原来设计成一张表，虽然可以方便程序的设计与维护，但经过分析发现，由于数据量太大，会影响数据的迅速定位。如果将户主账表分别设计为活期户主账、定期户主账及对公户主账等，则可以大大提高查询效率。 分区策略 在拥有数500行以上的表时，采用分区策略。 索引设计。 对于大的数据库表，合理的索引能够提高整个数据库的操作效率。在索引设计中，索引字段应挑选重复值较少的字段；在对建有复合索引的字段进行检索时，应注意按照复合索引字段建立的顺序进行。例如，如果对一个５万多条记录的流水表以日期和流水号为序建立复合索引，由于在该表中日期的重复值接近整个表的记录数，用流水号进行查询所用的时间接近３秒；而如果以流水号为索引字段建立索引进行相同的查询，所用时间不到１秒。因此在大型数据库设计中，只有进行合理的索引字段选择，才能有效提高整个数据库的操作效率。 有时候为了提高性能。减少表的关联，恰当的数据冗余是允许的。 索引对新增，删除，更新的性能影响比较大，对相关的表的索引使用要权衡为表和索引建立不同的表空间，禁止在系统表空间中放入非核心oracle系统成分的对象，确保数据表空间和索引表空间位于不同的磁盘磁盘驱动器上。 对于经常发生同时查询或频繁查询的表，最好把他放到不同的磁盘空间上 4. 逻辑设计规范 4.1 范式 如果没有性能上的原因，应该使用关系数据库理论，达到较高的范式，避免数据冗 余。 如果在数据量上与性能上无特别要求，考虑到实现的方便性可以有适当的数据冗 余，但基本上要达到3NF。 4.2 表设计 对于数据量比较大的表，根据表数据的属性进行分区，以得到较好的性能。如果表 按某些字段进行增长，则采用按字段值范围进行范围分区；如果表按某个字段的几
SQL Server 2008 中全文搜索步骤
/*建立测试环境*/ if object_id('tb')isnotnull droptable tb go createtable tb (id intidentity(1,1), title varchar(200), detail varchar(1000), constraint pk_id primarykey(id)--在建立全文索引时需要使用 ) insertinto tb select'火箭即将签下新秀射手','据悉，巴丁格与火箭队的合同谈判是于昨天完成的，巴丁格将得到与泰勒一样的合同。此前媒体曝光泰勒的合同为期四年，总价值万美元，其中前两年为保障性合同。巴丁格预计会在接下来几天内正式宣布签约加盟火箭。' union all select'韦弗被曝已与希腊豪门签约','据国际篮球网报道，前火箭队球员范-韦弗已经与希腊豪门奥林匹亚科斯队签订了合同。韦弗得到一份为期两年，总价值万美元的合同。' union all select'马刺豪掷千金为对抗湖人','马刺队在今夏休赛期补充了几员大将，主教练格雷格-波波维奇日前在接受Yahoo!体育采访时透露，马刺队不惜缴纳奢侈税构建豪华阵容就是为了对抗湖人队，争取拿到第五个总冠军。' union all select'华莱士未曾想过离开汽车城','此前本-华莱士已经同意重返底特律活塞，并且以老将底薪和活塞签下一份年万美元的合同，而据《每日先驱报》专栏作家米克-麦格劳透露，这位当年叱咤NBA赛场的内线防守悍将甚至从来就没有考虑过要离开活塞队。' union all
select'米勒竟好横刀夺爱追求人妻','对于那些没看过雷吉·米勒在步行者创造“米勒时间” 的“后”们，应该怎么介绍这位前NBA球星呢？难道从前天洛杉矶马里布海滩上空那架飞机拉的横幅说起？恐怕没有哪位家长愿意这么做。' union all select'姚明：没把上海当投资项目乐得生意做了好人当了','“姚蜜”说：不缺广告效应的姚明收购濒临绝境的上海东方篮球俱乐部，说明他是真的想为曾经的母队做点事情。' union all select'火箭不敌奇才终结年纪录','此役姚麦组合状态糟糕，姚明投中得到分个篮板次盖帽，麦迪投中拿下分个篮板次助攻，两人联手竟不如得到分个篮板次助攻次盖帽的贾米森。' --- --第一步启用数据库的全文索引 sp_fulltext_database enable--启用数据库的全文索引 go --第二步：建立全文目录 createfulltextcatalog tb_fulltext in path N'D:/Program Files/Microsoft SQL Server2005/MSSQL.1/MSSQL/FTData' withaccent_sensitivity=on--区分重音 authorization dbo;--全文目录的所有者 --第三步：建立全文索引 createfulltextindexon tb (title,detail) keyindex pk_id--指定索引列，为了提高性能，最好使用聚集索引 on tb_fulltext withchange_trackingauto--在关联的表中修改了数据时，自动更新全文索引。 --第四步：查询示例：
- 索引和全文索引
- (转)sql2005全文索引
- 基于语义的全文搜索引擎
- 基于Lucene的网站全文搜索的设计与实现.
- SQL创建全文索引
- Sql2008 全文索引详解
- SQL Server 全文索引查询
- Lucene：基于Java的全文检索引擎简介
- lucene全文检索汇总
- Sphinx 全文搜索引擎
- Oracle全文索引技术-使用说明文档解析
- MSSQL全文索引的例子
- 一种基于Lucene的中文全文检索系统
- 基于Java的全文索引引擎
- 全文检索中的索引策略-倒排索引
- SQL Server 2008 中全文搜索步骤
- 文摘索引型数据库和全文数据库区别
- Sql2008全文索引详解
- 使用Oracle全文索引搜索文本
- MySQL全文索引应用简明教程