改進索引的最佳方法

Ⅰ 倒排索引的更新策略

更新策略有四種 ：完全重建、再合並策略、原地更新策略以及混合策略。 完全重建策略：當新增文檔到達一定數量，將新增文檔和原先的老文檔整合，然後利用靜態索引創建方法對所有文檔重建索引，新索引建立完成後老索引會被遺棄。此法代價高，但是主流商業搜索引擎一般是採用此方式來維護索引的更新（這句話是書中原話） 再合並策略：當新增文檔進入系統，解析文檔，之後更新內存中維護的臨時索引，文檔中出現的每個單詞，在其倒排表列表末尾追加倒排表列表項；一旦臨時索引將指定內存消耗光，即進行一次索引合並，這里需要倒排文件里的倒排列表存放順序已經按照索引單詞字典順序由低到高排序，這樣直接順序掃描合並即可。其缺點是：因為要生成新的倒排索引文件，所以對老索引中的很多單詞，盡管其在倒排列表並未發生任何變化，也需要將其從老索引中取出來並寫入新索引中，這樣對磁碟消耗是沒必要的。 原地更新策略：試圖改進再合並策略，在原地合並倒排表，這需要提前分配一定的空間給未來插入，如果提前分配的空間不夠了需要遷移。實際顯示，其索引更新的效率比再合並策略要低。 混合策略：出發點是能夠結合不同索引更新策略的長處，將不同索引更新策略混合，以形成更高效的方法。

Ⅱ 如何更好的使用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的性能優化是一個復雜的過程，上述這些只是在應用層次的一種體現，深入研究還會涉及資料庫層的資源配置、網路層的流量控制以及操作系統層的總體設計。