改进索引的最佳方法

Ⅰ 倒排索引的更新策略

更新策略有四种 ：完全重建、再合并策略、原地更新策略以及混合策略。 完全重建策略：当新增文档到达一定数量，将新增文档和原先的老文档整合，然后利用静态索引创建方法对所有文档重建索引，新索引建立完成后老索引会被遗弃。此法代价高，但是主流商业搜索引擎一般是采用此方式来维护索引的更新（这句话是书中原话） 再合并策略：当新增文档进入系统，解析文档，之后更新内存中维护的临时索引，文档中出现的每个单词，在其倒排表列表末尾追加倒排表列表项；一旦临时索引将指定内存消耗光，即进行一次索引合并，这里需要倒排文件里的倒排列表存放顺序已经按照索引单词字典顺序由低到高排序，这样直接顺序扫描合并即可。其缺点是：因为要生成新的倒排索引文件，所以对老索引中的很多单词，尽管其在倒排列表并未发生任何变化，也需要将其从老索引中取出来并写入新索引中，这样对磁盘消耗是没必要的。 原地更新策略：试图改进再合并策略，在原地合并倒排表，这需要提前分配一定的空间给未来插入，如果提前分配的空间不够了需要迁移。实际显示，其索引更新的效率比再合并策略要低。 混合策略：出发点是能够结合不同索引更新策略的长处，将不同索引更新策略混合，以形成更高效的方法。

Ⅱ 如何更好的使用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');

第二． 在建立全文索引索引时，指明所用的lexer:
CREATE INDEX myindex ON mytable(mycolumn) indextype is ctxsys.context

parameters('lexer my_lexer');

这样建立的全文检索索引，就会使用chinese_vgram_lexer作为分析器。
步骤四 建立索引
通过以下语法建立全文索引
CREATE INDEX [schema.]index on [schema.]table(column) INDEXTYPE IS ctxsys.context [ONLINE]

LOCAL [(PARTITION [partition] [PARAMETERS('paramstring')]

[, PARTITION [partition] [PARAMETERS('paramstring')]])]

[PARAMETERS(paramstring)] [PARALLEL n] [UNUSABLE];
例：

CREATE INDEX ctx_idx_menuname ON pubmenu(menuname)
indextype is ctxsys.context parameters('lexer my_lexer')

步骤五 使用索引
使用全文索引很简单，可以通过：
select * from pubmenu where contains(menuname,'上传图片')>0
全文索引的种类
建立的Oracle Text索引被称为域索引(domain index)，包括4种索引类型：
l CONTEXT
2 CTXCAT
3 CTXRULE
4 CTXXPATH
依据你的应用程序和文本数据类型你可以任意选择一种。
对多字段建立全文索引
很多时候需要从多个文本字段中查询满足条件的记录，这时就需要建立针对多个字段的全文索引，例如需要从pmhsubjects(专题表)的 subjectname(专题名称)和briefintro(简介)上进行全文检索，则需要按以下步骤进行操作：
Ø 建议多字段索引的preference
以ctxsys登录，并执行：
EXEC ctx_ddl.create_preference(' ctx_idx_subject_pref',

'MULTI_COLUMN_DATASTORE');

Ø 建立preference对应的字段值(以ctxsys登录)

EXEC ctx_ddl.set_attribute(' ctx_idx_subject_pref ','columns','subjectname,briefintro');

Ø 建立全文索引
CREATE INDEX ctx_idx_subject ON pmhsubjects(subjectname)
INDEXTYPE ISctxsys.CONTEXT PARAMETERS('DATASTORE ctxsys.ctx_idx_subject_pref lexer my_lexer')
Ø 使用索引
select * from pmhsubjects where contains(subjectname,'李宇春')>0

全文索引的维护
对于CTXSYS.CONTEXT索引，当应用程序对基表进行DML操作后，对基表的索引维护是必须的。索引维护包括索引同步和索引优化。
在索引建好后，我们可以在该用户下查到Oracle自动产生了以下几个表：(假设索引名为myindex)：
DR$myindex$I、DR$myindex$K、DR$myindex$R、DR$myindex$N其中以I表最重要，可以查询一下该表，看看有什么内容：
SELECT token_text, token_count FROM dr$i_rsk1$I WHERE ROWNUM <= 20;

这里就不列出查询接过了。可以看到，该表中保存的其实就是Oracle 分析你的文档后，生成的term记录在这里，包括term出现的位置、次数、hash值等。当文档的内容改变后，可以想见这个I表的内容也应该相应改变，才能保证Oracle在做全文检索时正确检索到内容(因为所谓全文检索，其实核心就是查询这个表)。这就用到sync(同步) 和 optimize(优化)了。
同步(sync): 将新的term 保存到I表；
优化(optimize): 清除I表的垃圾，主要是将已经被删除的term从I表删除。
当基表中的被索引文档发生insert、update、delete操作的时候，基表的改变并不能马上影响到索引上直到同步索引。可以查询视图 CTX_USER_PENDING查看相应的改动。例如：
SELECT pnd_index_name, pnd_rowid,
TO_CHAR (pnd_timestamp, 'dd-mon-yyyy hh24:mi:ss') timestamp
FROM ctx_user_pending;
该语句的输出类似如下：
PND_INDEX_NAME PND_ROWID TIMESTAMP
------------------------------ ------------------ --------------------
MYINDEX AAADXnAABAAAS3SAAC 06-oct-1999 15:56:50

同步和优化方法: 可以使用Oracle提供的ctx_ddl包同步和优化索引
一. 对于CTXCAT类型的索引来说， 当对基表进行DML操作的时候，Oracle自动维护索引。对文档的改变马上反映到索引中。CTXCAT是事务形的索引。
索引的同步
在对基表插入，修改，删除之后同步索引。推荐使用sync同步索引。语法：
ctx_ddl.sync_index(
idx_name IN VARCHAR2 DEFAULT NULL
memory IN VARCHAR2 DEFAULT NULL,
part_name IN VARCHAR2 DEFAULT NULL
parallel_degree IN NUMBER DEFAULT 1);
idx_name 索引名称
memory 指定同步索引需要的内存。默认是系统参数DEFAULT_INDEX_MEMORY 。

指定一个大的内存时候可以加快索引效率和查询速度，且索引有较少的碎片
part_name 同步哪个分区索引。
parallel_degree 并行同步索引。设置并行度。
例如：
同步索引myindex:Exec ctx_ddl.sync_index ('myindex');
实施建议：建议通过oracle的job对索引进行同步
索引的优化
经常的索引同步将会导致你的CONTEXT索引产生碎片。索引碎片严重的影响了查询的反应速度。你可以定期优化索引来减少碎片，减少索引大小，提高查询效率。
当文本从表中删除的时候，Oracle Text标记删除的文档，但是并不马上修改索引。因此，就的文档信息占据了不必要的空间，导致了查询额外的开销。你必须以FULL模式优化索引，从索引中删除无效的旧的信息。这个过程叫做垃圾处理。当你经常的对表文本数据进行更新，删除操作的时候，垃圾处理是很必要的。
exec ctx_ddl.optimize_index ('myidx', 'full');
实施建议：每天在系统空闲的时候对全文索引进行相应的优化，以提高检索的效率
P.S.定时优化索引
3.定时优化同步域索引
创建定时任务，定期优化和同步域索引
SQL> create or replace procere hsp_sync_index as
2 begin
3 ctx_ddl.sync_index('id_cont_msg');
4 end;
5 /

Procere created.

Elapsed: 00:00:00.08
SQL> VARIABLE jobno number;
SQL> BEGIN
2 DBMS_JOB.SUBMIT(:jobno,'hsp_sync_index();',
3 SYSDATE, 'SYSDATE + (1/24/4)');
4 commit;
5 END;
6 /

PL/SQL procere successfully completed.

Elapsed: 00:00:00.27
SQL> create or replace procere hsp_optimize_index as
2 begin
3 ctx_ddl.optimize_index('id_cont_msg','FULL');
4 end;
5 /

SQL> VARIABLE jobno number;
SQL> BEGIN
2 DBMS_JOB.SUBMIT(:jobno,'hsp_optimize_index();',
3 SYSDATE, 'SYSDATE + 1');
4 commit;
5 END;
6 /
Procere created.

Elapsed: 00:00:00.03

PL/SQL procere successfully completed.

Elapsed: 00:00:00.02
SQL>

Ⅲ Oracle索引技术之如何建立最佳索引

怎样建立最佳索引?1、明确地创建索引create index index_name on table_name(field_name)tablespace tablespace_namepctfree 5initrans 2maxtrans 255storage(minextents 1maxextents 16382pctincrease 0); 2、创建基于函数的索引常用与UPPER、LOWER、TO_CHAR(date)等函数分类上，例：create index idx_func on emp(UPPER(ename)) tablespace tablespace_name; 3、创建位图索引对基数较小，且基数相对稳定的列建立索引时，首先应该考虑位图索引，例：create bitmap index idx_bitm on class (classno) tablespace tablespace_name; 4、明确地创建唯一索引可以用create unique index语句来创建唯一索引，例：create unique index dept_unique_idx on dept(dept_no) tablespace idx_1; 5、创建与约束相关的索引可以用using index字句，为与unique和primary key约束相关的索引，例：alter table table_nameadd constraint PK_primary_keyname primary key(field_name)using index tablespace tablespace_name; 如何创建局部区索引？1)基础表必须是分区表2)分区数量与基础表相同3)每个索引分区的子分区数量与相应的基础表分区相同4)基础表的自分区中的行的索引项，被存储在该索引的相应的自分区中，例如create index TG_CDR04_SERV_ID_IDX on TG_CDR04(SERV_ID)Pctfree 5Tablespace TBS_AK01_IDXStorage(MaxExtents 32768PctIncrease 0FreeLists 1FreeList Groups 1)local/ 如何创建范围分区的全局索引？基础表可以是全局表和分区表create index idx_start_date on tg_cdr01(start_date)global partition by range(start_date)(partition p01_idx vlaues less than ('0106')partition p01_idx vlaues less than ('0111')...partition p01_idx vlaues less than ('0401'))/ 如何重建现存的索引？重建现存的索引的当前时刻不会影响查询重建索引可以删除额外的数据块提高索引查询效率alter index idx_name rebuild nologging;对于分区索引alter index idx_name rebuild partition partition_name nologging; 删除索引的原因？1)不再需要的索引2)索引没有针对其相关的表所发布的查询提供所期望的性能改善3)应用没有用该索引来查询数据4)该索引无效，必须在重建之前删除该索引5)该索引已经变的太碎了，必须在重建之前删除该索引语句：drop index idx_name;drop index idx_name partition partition_name; 建立索引的代价？基础表维护时，系统要同时维护索引，不合理的索引将严重影响系统资源，主要表现在CPU和I/O上。插入、更新、删除数据产生大量db file sequential read锁等待。

Ⅳ 如何为Mysql优化选择最佳索引

我个人建议用explain extended先得到一条简短的语句，然后用explain看看你的访问类型，根据explain进行索引添加，然后在执行语句。用show status like 'Handler_read%';查看你的索引使用情况，Handler_read_rnd_next很高意味着查询效率低下，说明你要换一个索引值。然后用show profile看看你的线程到底在哪里消耗的开销比较大。

Ⅳ 如何为MySQL查询优化选择最佳索引

说一下不同引擎的优化，myisam读的效果好，写的效率差，这和它数据存储格式，索引的指针和锁的策略有关的，它的数据是顺序存储的（innodb数据存储方式是聚簇索引），他的索引btree上的节点是一个指向数据物理位置的指针，所以查找起来很快，（innodb索引节点存的则是数据的主键，所以需要根据主键二次查找）；myisam锁是表锁，只有读读之间是并发的，写写之间和读写之间（读和插入之间是可以并发的，去设置concurrent_insert参数，定期执行表优化操作，更新操作就没有办法了）是串行的，所以写起来慢，并且默认的写优先级比读优先级高，高到写操作来了后，可以马上插入到读操作前面去，如果批量写，会导致读请求饿死，所以要设置读写优先级或设置多少写操作后执行读操作的策略;myisam不要使用查询时间太长的sql，如果策略使用不当，也会导致写饿死，所以尽量去拆分查询效率低的sql,

Ⅵ mysql全文索引 很慢，速度不如like的百分之一

从explain开始说起吧，很显然第一个sql语句压根没用任何索引（key列内什么都没有）！第二个倒是用到索引，却是主键索引，并非你添加的fulltext索引！

接下来，分析下原因：
sql1：执行步骤：先s_a和s_a_t两表笛卡尔集，然后筛选满足on条件的，接着在从结果集中筛选满足where字句的；该过程中处理的记录条目为69*105479，并且未用到任何索引，未用到的原因可能是你先定义了一个复合索引a_concent_split（a_title_split，a_content_split），然后又定义了一个a_content_split2（a_content_split），当引擎执行查找优化时候会先用到a_content_split，可是又由于复合索引是从最左边开始（不能跳过第一个字段），而你却忽略了a_title_split字段，故未能正常使用索引。
sql2：执行步骤：先调用where字句对s_a表进行筛选形成新的s_a表，然后与s_a_t表笛卡尔积，再利用on字句筛选，最后再次利用where字句形成最终结果集；经过第一个where，该过程处理结果集会大幅少于sql1，并且该过程还用到了主键索引。你所设置的fulltext索引再次没有用到，原因是like字句中开始部分为模糊匹配%时候用不了全文索引，这与fulltext存储机制有关。

另，你说的删除速度慢，原因：设置fulltext字段设置太多，fulltext索引在更新删除大量数据时候，需要同步更改索引，你的三个fulltext压力太大！

改进方法：1、删除a_content_split索引重试 2、在删除时候打开delay_key_write变量

有关fulltext比较复杂，用的时候要谨慎设置，还有很多参数也对其有影响
另外sql语句中外连接有关on where字句也是个比较绕的地方，两者你都占了，唉，所以我写的略复杂，前天看到该问题，思忖两天这才作答

望有结果了予以回复交流！

Ⅶ 跪求“倒排索引表的改进策略”

关于这个问题，比较简单，怎么会这么简单呢？因为。。。。。。。

嘿嘿！！！

正确答案：人＝吃饭＋睡觉＋上班＋玩,

猪＝吃饭＋睡觉,

代入：人＝猪＋上班＋玩,

即：人－玩＝猪＋上班.

结论：不懂玩的人＝会上班的猪

男人＝吃饭＋睡觉＋赚钱

猪＝吃饭＋睡觉

代入：男人＝猪＋赚钱

即：猪＝男人－赚钱

所以男人不赚钱等于猪。

女人＝吃饭＋睡觉＋花钱。

猪＝吃饭＋睡觉。

代入：女人＝猪＋花钱

即：女人－花钱＝猪。

结论：女人不花钱的都是猪。

综上：

男人为了让女人不变成猪而赚钱！

女人为了让男人不变成猪而花钱！

结论：

男人＋女人

＝(猪＋赚钱)＋(猪＋花钱)

＝两头猪!!!!

结果：问这个问题的人是头猪！

Ⅷ 求教：dbeaver执行mysql查询，突然需要添加用户名且表名需大写了该如何恢复

MySQL Explain语法

如下

执行计划包含的信息

ID 说明

表示执行SELECT语句的顺序，ID相同时，执行顺序由上至下。如果是子查询，ID的序号会递增，ID越大优先级越高，越优先被执行。

SELECT_TYPE说明

SIMPLE：简单查询，即不包含子查询或是UNION操作的查询。
PRIMARY：最外层查询，即查询中包含任何子查询，则最外层的查询则被标记为PRIMARY。
SUBQUERY：映射为子查询，即在SELECT 或 WHERE列表中包含了子查询 。
DEPENDENT SUBQUERY：依赖外部结果的子查询。
DERIVED：子查询，即出现在FROM子句中的子查询。
UNION：联合，若第二个SELECT出现在UNION之后，则被标记为UNION。若UNION包含在FROM子句的子查询中，外层SELECT将被标记为DERIVED。
UNION RESULT：使用联合的结果，即UNION产生的结果集。
TABLE 说明

指的就是当前执行的表，即输出数据行所在的表的名称。由ID为M,N查询union产生的结果集，或者是由ID为N的查询产生的结果。

TYPE 说明

ALL：全数据表扫描 ，遍历全表以找到匹配的行，效率最差。
INDEX：全索引表扫描，INDEX与ALL区别为index类型只遍历索引树。
RANGE：对索引列进行范围查找，只检索给定范围的行，使用一个索引来选择行，常见于BETWEEN、>、
INDEX_MERGE：合并索引，使用多个单列索引搜索。
REF：使用非唯一索引扫描或者唯一索引的前缀扫描，返回匹配某个单独值的数据行，然而他可能会找到多个符合条件的行，所以它应该属于查找和扫描的混合体 。
EQ_REF：唯一性索引扫描，对于每个索引键，表中只有一条数据与之匹配。常见于主键 或 唯一索引扫描。
CONST：表中有且只有一个匹配的行时使用。因为仅有一行，在这行的列值可被优化器剩余部分认为是常数，如对主键或是唯一索引的查询，效率最高的联接方式。
SYSTEM：SYSTEM是CONST类型的特例，即当查询的表只有一行的情况下(等于系统表)。
NULL: MySQL在优化过程中分解语句，执行时甚至不用访问表或索引，例如从一个索引列里选取最小值可以通过单独索引查找完成。
性能排序如下：

一般来说，得保证查询至少达到RANGE级别，最好能达到REF。

POSSIBLE_KEYS 说明

可能使用的索引，指出MySQL能使用哪些索引来优化查询，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。

KEY 说明

KEY 列显示MySQL实际决定使用的索引，如果没有可用的索引，则显示为NULL。如查询使用了覆盖索引，则该索引仅出现在Key列中。要想强制MySQL使用或忽视POSSIBLE_KEYS 列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

KEY_LEN 说明

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度，KEY_LEN 显示的值为索引字段的最大可能长度，理论上长度越短越好，但并非实际使用长度，即KEY_LEN 是根据表定义计算而得，而不是通过表内检索出的。

REF 说明

表示上述表的连接匹配条件，即表示哪些列或常量被用于查找索引列上的值。

ROWS 说明

表示MySQL根据表统计信息及索引选用情况，估算的找到所需的数据所需要读取的行数，ROWS值的大小是个统计抽样结果，并不完全准确。

Extra 说明

不适合在其他列中显示，但又很重要的额外信息，有以下几种情况：

using index：使用了覆盖索引(Covering Index)进行查询，以避免访问表。
using where：MySQL将在存储引擎检索行后再进行过滤。许多WHERE条件里涉及索引中的列，当它读取索引时，就能被存储引擎检验，因此不是所有带WHERE子句的查询都会显示"using where"。
using temporary：MySQL需要使用临时表来存储结果集，常见于排序、子查询和分组查询。
using filesort：MySQL中无法利用索引完成的排序操作称为文件排序。MySQL有两种文件排序方式，都可以在内存或者磁盘上完成， 通常会出现在ORDER BY或GROUP BY查询中。
not exists：使用Not Exists来优化查询。
select tables optimized away：直接通过索引来获取数据，不用访问表。
Using join buffer：表示在获取连接条件时没有使用索引，并且需要连接缓冲区来存储中间结果。如果出现了这个值，应该注意，根据查询的具体情况可能需要添加索引来改进性能。
引发索引失效，导致全表扫描的原因有：
索引列进行计算、函数、类型转换等操作。
索引列使用不等于，如!= 或<>。
索引列使用 IS NULL ，IS NOT NULL。
模糊查询LIKE 以通配符开头如，%ab。
索引列使用使用 OR 来连接条件。
索引列使用IN 和 NOT IN 。
隐式转换，类型错误，如字段NUM类型为varchar，WHERE条件用number，NUM = 1。
WHERE子句和ORDER BY使用相同的索引，并且ORDER BY的顺序和索引顺序相同，并且ORDER BY的字段都是升序或者降序，否则不会使用索引。
复合索引不符合最佳左前缀原则或存在断点。
如果MYSQL评估使用索引比全表扫描更慢，则不使用索引。
索引失效优化技巧
可阅读：日拱一卒，SQL语法优化方法及实例详解

SQL 执行顺序
可阅读：SQL查询语句的执行顺序解析

Ⅸ > SEO基础:如何尽快建立新的网站页面索引

添加新的页面可以为你的网站带来新的流量和访问者，当它们在搜索结果中排名很好时，它们是完成这个目标的最有效的方式。

为了让你的内容显示在搜索结果中，它需要被索引。这意味着你需要尽最大的努力，并尽可能快地建立新的索引页。

如果你的内容没有被索引，你的潜在客户将无法找到该页面，而且这个页面也不会对你的业务提供任何价值。

这就是为什么在本文中，我们将解释如何快速地索引你的新页面，以便它们能够帮助你实现你的目标。

要理解的重要术语

在你了解影响你的内容快速被索引的因素之前，有几个关键术语你应该知道。

1、网络机器人

网络机器人也被称为“网络爬虫”或“网页蜘蛛”。网络机器人是网络爬行程序，在网上发现和抓取网页。他们收集在线文档和内容，然后决定如何在搜索引擎数据库中组织它们。网络机器人必须抓取网站的内容以使其被索引，或者出现在网络和其他搜索引擎的结果中。

2、爬行

“爬行”指的是网络机器人进入虚拟网络世界并寻找新信息的过程。网络机器人在互联网上找到新信息的方式和我们一样 —— 通过从一个页面链接到下一个页面。

然后，他们将新信息发送回搜索引擎，如被网络索引。

3、索引

在机器人带来新的在线信息后，他们会处理并检查每一页。不过，主要内容并不是他们唯一检查的东西。当他们处理页面时，他们还检查网站标题标签、正文标题标签和其他显示主题的元素。

使用这些信息，搜索引擎可以开始在他们的搜索结果中精确显示新的页面。

但值得注意的是，索引与搜索结果中的页面没有任何关系。这个因素是由SEO决定的。

为什么你的网站需要被索引

1、建立你的网页索引对于建立你的在线存在感是绝对必要的

如果你的网站页面没有被索引，它们就不会出现在网络搜索结果中。考虑到网络用户每天执行超过 35 亿的搜索，这是一个很大的错失机会，让你的网站流量。

2、你的网站应该被索引的另一个原因可以用多米诺效应来进行解释

如果你的站点没有被索引，它就不会出现在网络搜索结果中。

如果你的网站没有出现在搜索结果中，用户很难找到你的网站。反过来，无论你的内容、产品或服务有多好，你都很难获得业务。

如果你把时间和资源投入到创建一个高大上的网站上，你应该确保它是在驱动你想要的结果。

由于这些原因，你的网站被索引是至关重要的。

如何确保我的新页面快速被索引

虽然索引新页面所需的时间各不相同，但有一些方法可以确保站点经常被抓取，并且你的新页面能够尽可能快地显示在搜索引擎结果页面(SERPs)中。

1、创建一个站点地图(Sitemap)

在网站上创建站点地图是确保网站快速索引的第一步。Sitemap作为网络机器人的地图，帮助它们在你的站点上找到新的页面。

Sitemap不仅为你的站点提供了一个大纲，而且可以帮助搜索引擎蜘蛛了解重要的信息，比如你的站点有多大，你更新或添加的内容，以及存储在你的网站上最重要的内容。

2、将你的网站提交给网络

网络站长工具是你首先应该提交你的网站的地方，但是你必须先用网络站长工具验证你的站点。

这使得网络更容易找到你的网站，因为你基本上是在给网络提供你的URL。

你也可以将你的站点地图提交给其他搜索引擎，如搜狗和360。

3、强大的内部链接结构

链接对于帮助搜索引擎蜘蛛爬行和索引你的站点非常重要。

通过链接，搜索引擎蜘蛛会抓取你的网站，确保你的网站快速被索引的一种方法是建立一个强大的内部链接结构。

当你把你的旧页面添加到你的网站的时候，你应该从你的旧页面创建链接。你的旧页面很可能已经被索引了，因此添加与它们的链接就不那么重要了。

例如，如果你在一个特定的服务中添加了一个新页面，那么在你的网站上添加一个关于相关服务的更早且更有意义的页面链接，并链接到该页面是很有帮助的。

当你链接到这些新页面时，你会让搜索引擎蜘蛛更容易找到和爬行。不久，它们将被索引，并准备在搜索引擎结果中显示。

4、创建并维护一个博客

创建并维护一个常规的博客是一个很好的方法，可以确保你的网站是爬行的，而且你的新页面经常被索引。定期添加新内容也有助于提高网站的搜索引擎优化。

定期发表的博客不仅能吸引到搜索引擎蜘蛛爬行，而且你改进的搜索引擎优化也能帮助你的网站提升你的网站排名。

5、使用robots.txt

Robots.txt是一个文本文件，robots.txt是一个协议，而不是一个命令。Robots.txt是搜索引擎中访问网站的时候要查看的第一个文件。

Robots.txt文件告诉网络机器人在服务器上什么文件是可以被查看的。它给机器人提供了他们可以做什么，不能爬行和索引的方向。

然而，有时你可能不希望机器人抓取所有的页面，因为你知道在某些页面上有重复的内容。

例如，如果你在你的一个网站页面上进行A/B测试，你就不需要所有的变量索引，因为它们可能被标记为重复的内容。

如果你不想让搜索引擎蜘蛛抓取这些页面，你就可以避免这些问题，而搜索引擎蜘蛛只专注于你想要索引的新的、独特的页面。

6、积累反向链接

就像在你的网站中链接到页面一样重要，可以从其他网站上获得链接，这在索引过程中也非常有用。

当搜索引擎蜘蛛抓取其他网站链接到你的页面时，你的页面也会被索引。

虽然获取反向链接并不容易，但它增加了网站被索引的速度。这意味着，当你发布可能引起读者兴趣的新内容时，你可以向编辑、投稿网站和博客站长寻求帮助。

7、安装网络统计

网络统计是一个很好的平台，可以跟踪你的网站的性能并获得分析数据。

然而，众所周知，一个新网站即将推出，需要索引，虽然这不是一个有保证的策略，但有可能帮助索引过程。另外，没有理由不让网络统计在你的网站上安装，因为它是最好的免费分析平台之一。

8、在社交媒体上分享你的内容

社交媒体不会直接帮助你的新页面在你的网站上被索引，但可以帮助你获得在线的知名度。用户看到你的内容越多，你的网站就越有可能在网上获得吸引力，并从其他网站获得链接。

正如我们上面提到的，这些链接可以帮助搜索引擎蜘蛛定位你的新页面。

Ⅹ 如何使用索引提高查询速度

人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的
性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明
显。笔者在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。在对
它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个方面分别进行总结：

---- 为了更直观地说明问题，所有实例中的SQL运行时间均经过测试，不超过1秒的均表示为（< 1秒）。

---- 测试环境--
---- 主机：HP LH II
---- 主频：330MHZ
---- 内存：128兆
---- 操作系统：Operserver5.0.4
----数据库：Sybase11.0.3

一、不合理的索引设计
----例：表record有620000行，试看在不同的索引下，下面几个 SQL的运行情况：
---- 1.在date上建有一个非群集索引

select count(*) from record where date >'19991201' and date < '19991214'and amount >2000 (25秒)
select date,sum(amount) from record group by date(55秒)
select count(*) from record where date >'19990901' and place in ('BJ','SH') (27秒)

---- 分析：
----date上有大量的重复值，在非群集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描才能找到这一范围内的全部行。

---- 2.在date上的一个群集索引

select count(*) from record where date >'19991201' and date < '19991214' and amount >2000（14秒）
select date,sum(amount) from record group by date（28秒）
select count(*) from record where date >'19990901' and place in ('BJ','SH')（14秒）

---- 分析：
---- 在群集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。

---- 3.在place，date，amount上的组合索引

select count(*) from record where date >'19991201' and date < '19991214' and amount >2000（26秒）
select date,sum(amount) from record group by date（27秒）
select count(*) from record where date >'19990901' and place in ('BJ, 'SH')（< 1秒）

---- 分析：
---- 这是一个不很合理的组合索引，因为它的前导列是place，第一和第二条SQL没有引用place，因此也没有利用上索引；第三个SQL使用了place，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。

---- 4.在date，place，amount上的组合索引
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000(< 1秒)
select date,sum(amount) from record group by date（11秒）
select count(*) from record where date >'19990901' and place in ('BJ','SH')（< 1秒）

---- 分析：
---- 这是一个合理的组合索引。它将date作为前导列，使每个SQL都可以利用索引，并且在第一和第三个SQL中形成了索引覆盖，因而性能达到了最优。

---- 5.总结：

---- 缺省情况下建立的索引是非群集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测
上。一般来说：

---- ①.有大量重复值、且经常有范围查询

（between, >,< ，>=,< =）和order by
、group by发生的列，可考虑建立群集索引；

---- ②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；

---- ③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。

二、不充份的连接条件：
---- 例：表card有7896行，在card_no上有一个非聚集索引，表account有191122行，在 account_no上有一个非聚集索引，试看在不同的表连接条件下，两个SQL的执行情况：

select sum(a.amount) from account a,card b where a.card_no = b.card_no（20秒）

---- 将SQL改为：
select sum(a.amount) from account a,card b where a.card_no = b.card_no and a.account_no=b.account_no（< 1秒）

---- 分析：
---- 在第一个连接条件下，最佳查询方案是将account作外层表，card作内层表，利用card上的索引，其I/O次数可由以下公式估算为：

---- 外层表account上的22541页+（外层表account的191122行*内层表card上对应外层表第一行所要查找的3页）=595907次I/O

---- 在第二个连接条件下，最佳查询方案是将card作外层表，account作内层表，利用account上的索引，其I/O次数可由以下公式估算为：

---- 外层表card上的1944页+（外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O

---- 可见，只有充份的连接条件，真正的最佳方案才会被执行。

---- 总结：

---- 1.多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。

---- 2.查看执行方案的方法-- 用set showplanon，打开showplan选项，就可以看到连接顺序、使用何种索引的信息；想
看更详细的信息，需用sa角色执行dbcc(3604,310,302)。

三、不可优化的where子句
---- 1.例：下列SQL条件语句中的列都建有恰当的索引，但执行速度却非常慢：

select * from record where substring(card_no,1,4)='5378'(13秒)
select * from record where amount/30< 1000（11秒）
select * from record where convert(char(10),date,112)='19991201'（10秒）

---- 分析：
---- where子句中对列的任何操作结果都是在SQL运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被SQL优化器优化，使用索引，避免表搜索，因此将SQL重写成
下面这样：

select * from record where card_no like '5378%'（< 1秒）
select * from record where amount < 1000*30（< 1秒）
select * from record where date= '1999/12/01' （< 1秒）

---- 你会发现SQL明显快起来！

---- 2.例：表stuff有200000行，id_no上有非群集索引，请看下面这个SQL：

select count(*) from stuff where id_no in('0','1')（23秒）

---- 分析：
---- where条件中的'in'在逻辑上相当于'or'，所以语法分析器会将in ('0','1')转化为id_no ='0' or id_no='1'来执行。我们期望它会根据每个or子句分别查找，再将结果相加，这样可以利用id_no上的索引；但实际上（根据showplan）,它却采用了"OR策略"，即先取出满足每个or子句的行，存入临时数据库的工作表中，再建立唯一索引以去掉重复行，最后从这个临时表中计算结果。因此，实际过程没有利用id_no上索引，并且完成时间还要受tempdb数据库性能的影响。

---- 实践证明，表的行数越多，工作表的性能就越差，当stuff有620000行时，执行时间竟达到220秒！还不如将or子句分
开：

select count(*) from stuff where id_no='0'
select count(*) from stuff where id_no='1'

---- 得到两个结果，再作一次加法合算。因为每句都使用了索引，执行时间只有3秒，在620000行下，时间也只有4秒。或者，用更好的方法，写一个简单的存储过程：
create proc count_stuff as
declare @a int
declare @b int
declare @c int
declare @d char(10)
begin
select @a=count(*) from stuff where id_no='0'
select @b=count(*) from stuff where id_no='1'
end
select @c=@a+@b
select @d=convert(char(10),@c)
print @d

---- 直接算出结果，执行时间同上面一样快！
---- 总结：

---- 可见，所谓优化即where子句利用了索引，不可优化即发生了表扫描或额外开销。

---- 1.任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

---- 2.in、or子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把子句拆开；拆开的子句中应该包含索引。

---- 3.要善于使用存储过程，它使SQL变得更加灵活和高效。

---- 从以上这些例子可以看出，SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。