當前位置:首頁 » 編程語言 » sql索引分析
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

sql索引分析

發布時間: 2022-02-15 13:06:14

⑴ 建立資料庫索引的優缺點,分析一張表上如何建立索引

1、表的主鍵、外鍵必須有索引;
2、數據量超過300的表應該有索引;
3、經常與其他表進行連接的表,在連接欄位上應該建立索引;
4、經常出現在Where子句中的欄位,特別是大表的欄位,應該建立索引;
5、索引應該建在選擇性高的欄位上;
6、索引應該建在小欄位上,對於大的文本欄位甚至超長欄位,不要建索引;
7、復合索引的建立需要進行仔細分析;盡量考慮用單欄位索引代替:
A、正確選擇復合索引中的主列欄位,一般是選擇性較好的欄位;
B、復合索引的幾個欄位是否經常同時以AND方式出現在Where子句中?單欄位查詢是否極少甚至沒有?如果是,則可以建立復合索引;否則考慮單欄位索引;
C、如果復合索引中包含的欄位經常單獨出現在Where子句中,則分解為多個單欄位索引;
D、如果復合索引所包含的欄位超過3個,那麼仔細考慮其必要性,考慮減少復合的欄位;
E、如果既有單欄位索引,又有這幾個欄位上的復合索引,一般可以刪除復合索引;
8、頻繁進行數據操作的表,不要建立太多的索引;
9、刪除無用的索引,避免對執行計劃造成負面影響;
以上是一些普遍的建立索引時的判斷依據。一言以蔽之,索引的建立必須慎重,對每個索引的必要性都應該經過仔細分析,要有建立的依據。因為太多的索引與不充分、不正確的索引對性能都毫無益處:在表上建立的每個索引都會增加存儲開銷,索引對於插入、刪除、更新操作也會增加處理上的開銷。另外,過多的復合索引,在有單欄位索引的情況下,一般都是沒有存在價值的;相反,還會降低數據增加刪除時的性能,特別是對頻繁更新的表來說,負面影響更大。
只做參考,整理自網路。

⑵ 試述sql的定義功能(從表、視圖、索引分析)。

數據定義:這一部分又稱為「SQL DDL」,定義資料庫的邏輯結構,包括定義資料庫、基本表、視圖和索引4部分。資料庫模式定義語言DDL (Data Definition Language)用於定義和管理對象,例如資料庫、數據表以及視圖。DDL 語句通常包括每個對象的CREATE、ALTER 以及 DROP 命令。舉例來說,CREATE TABLE、ALTER TABLE 以及 DROP TABLE 這些語句便可以用來建立新數據表、修改其屬性(如新增或刪除資料行)、刪除數據表等

⑶ Oracle資料庫表做表分析、索引分析的命令是什麼

analyze index 索引ID compute statistics 如果想分析所有的表名和index名可以從視圖user_tables, user_indexes取得相關的信息,自動生成SQL命令 答案3:: 不知道- - :::::::::::::::::::請參考以下相關問題:::::::::::::::::::: 一張表最多可以創建多少個索引 ? oracle資料庫 :::::::::::::::::::請參考以下相關問題:::::::::::::::::::: 使用命令行創建ORACLE資料庫 :::::::::::::::::::請參考以下相關問題:::::::::::::::::::: :::::::::::::::::::請參考以下相關問題:::::::::::::::::::: 分析oracle表索引的若干問題 :::::::::::::::::::請參考以下相關問題::::::::::::::::::::

⑷ 資料庫索引優缺點

優點:資料庫系統是用來管理數據的,建立的數理邏輯和集合操作基礎上的。
具有高效、可靠、完整、自同步等特性,是業務系統進行數據控制的最佳選擇。
資料庫系統一般提供高效的數據控制和數據檢索功能,採用SQL語言來進行數據操作。
目前市面上流行的資料庫系統很多:較小型的資料庫系統有:mysql,MSSQL_SERVER等等,適用於企業級的大型資料庫有:ORACEL,DB2(IBM),INFORMIX(IBM)等等

缺點:安全性不夠,加了用戶級密碼容易破解
C/S 結構下對伺服器要求很高,否則容易造成 MDB 損壞並發數255。
但是對高強度操作適應性差,如果伺服器不夠好,網路不夠好,編程的方法不夠好,6-7個人同時訪問就能導致 MDB 損壞或者並死不能將 VBA 代碼開發的軟體系統直接編譯成 EXE 可執行文件。
不能脫離 ACCESS 或者 ACCESS RUNTIME 環境,該環境相對其他軟體體積較大(50M左右)

⑸ 如何看mysql sql查詢語句用了哪些索引如何分析查詢語句

運行explain + SQL語句,例如:

explain select * from students where phone like '45%'G

圖中

possible_keys:可能被利用的索引名

key:被利用的索引名

rows:掃描的行數,1表示只掃描了一行說明充分利用了索引,此數自然越少越好

還有查詢耗時等等都可為查詢語句效率分析提供參數依據

⑹ 你了解SQL的索引原理嗎

索引是為檢索而存在的,就是說索引並不是一個表必須的。表索引由多個頁面組成,這些頁面一起組成了一個樹形結構,即我們通常說的B樹,首先來看下錶索引的組成部分: 根極節點,root,它指向另外兩個頁,把一個表的記錄從邏輯上分成非葉級節點Non-Leaf Level(枝),它指向了更加小的葉級節點Leaf Level(葉)。 根節點、非葉級節點和葉級節點都位於索引頁中,統稱為索引葉節點,屬於索引頁的范籌。這些"枝"、"葉"最終指向數據頁Page。根級節點和葉級節點之間的葉又叫數據中間頁。根節點對應了sysindexes表的Root欄位,記載了非葉級節點的物理位置(即指針);非葉級節點位於根節點和葉節點之間,記載了指向葉級節點的指針;而葉級節點則最終指向數據頁,這就是最後的B樹。 資料庫是怎樣訪問表數據的: 第一:沒有創建任何索引的表。 這種表我們稱為堆表,因為所有的數據頁都是無序的,雜亂無章的,在查詢數據時,需要一條一條記錄查詢,有時第一條記錄就能找到,最壞的情況是在最後一條記錄中查找到,但是千萬不要認為SQL此時查找到數據後會當成結果立即返回,SQL即使查找到了記錄,也會將所有數據遍歷一次,這能從最終的執行計劃中得知,就是平時說的表掃描,對於沒有索引的表也能查詢,就是效率會特別低,如果數據量稍大的話。 問題:SQL是如何得知表沒有索引呢? SQL在接到查詢請求的時候,會分析sysindexes表中索引標志符(INDID: Index ID)的欄位的值,如果該值為0,表示這是一張數據表而不是索引表,SQL就會使用sysindexes表的另一個欄位FirstIAM值中找到該表的IAM 頁鏈也就是所有數據頁集合。至於什麼是IAM,大家可以網上搜索下。 第二:訪問創建有非聚集索引的表。

⑺ sql server 使用 索引 和 不使用 索引 的區別,能否舉例給我分析一下

使用索引 增加查詢速度 但是會消耗硬碟(索引有索引文件)
對索引列的修改刪除增加 會比 不增加索引需要更多的資源和時間
樓主可以按實際情況進行創建索引
以下是我自己找的資料 更多的還需要樓主自己找找

◆根據表數據大小創建索引
1.小表不需要建立索引
建立索引其性能也不會得到很大的改善,而且查詢時索引開銷,維護成本增加。
2. 大表建立索引
在大表建立索引的開銷要比普通的表大的多,是否要建索引需要考慮兩個方面
a.使用頻率,不常用的表不需要建立索引,例如系統日誌表,不需要用戶查看,系統管理員也不常看的表,就不需要建索引了。
b.查詢的數據量大小,一般查詢很小的數據量時就不要建索引了。
例如在1000萬數據表中查詢2條數據,建索引的開銷會很大。

◆根據列的特徵來創建索引
1.返回某范圍內的數據:頻繁查詢列
2.經常被分組排序列
3.外鍵列

一個表建多少索引合適?
1.索引主要用來進行查詢的表,設置的索引多一點,可以提高資料庫的查詢性能。同時因為記錄不怎麼更新,所以索引比較多的情況下,也不會影響到更新的速度。
2.經常更新記錄的表,如果在一張表中建立過多的索引,則會影響到更新的速度。由於更新操作比較頻繁,所以對其的負面影響,要比查詢效率提升要大的多。此時就需要限制索引的數量,只在一些必要的欄位上建立索引。

⑻ Oracle資料庫表做表分析、索引分析的命令是什麼

dbms_stats.gather_table_stats('USERNAME','TABLENAME',CASCADE=>TRUE)
此命令同時分析表及改表的索引

⑼ 分析SQL執行過程中,哪些SQL條件會走索引

這樣回答你,以下幾種情況sql中索引不會被用到
1、查詢謂詞沒有使用索引的主要邊界,換句話說就是select *,可能會導致不走索引。
比如,你查詢的是SELECT * FROM T WHERE Y=XXX;假如你的T表上有一個包含Y值的組合索引,但是優化器會認為需要一行行的掃描會更有效,這個時候,優化器可能會選擇TABLE ACCESS FULL,但是如果換成了SELECT Y FROM T WHERE Y = XXX,優化器會直接去索引中找到Y的值,因為從B樹中就可以找到相應的值。

2、單鍵值的b樹索引列上存在null值,導致COUNT(*)不能走索引。
如果在B樹索引中有一個空值,那麼查詢諸如SELECT COUNT(*) FROM T 的時候,因為HASHSET中不能存儲空值的,所以優化器不會走索引,有兩種方式可以讓索引有效,一種是SELECT COUNT(*) FROM T WHERE XXX IS NOT NULL或者把這個列的屬性改為not null (不能為空)。

3、索引列上有函數運算,導致不走索引
如果在T表上有一個索引Y,但是你的查詢語句是這樣子SELECT * FROM T WHERE FUN(Y) = XXX。這個時候索引也不會被用到,因為你要查詢的列中所有的行都需要被計算一遍,因此,如果要讓這種sql語句的效率提高的話,在這個表上建立一個基於函數的索引,比如CREATE INDEX IDX FUNT ON T(FUN(Y));這種方式,等於Oracle會建立一個存儲所有函數計算結果的值,再進行查詢的時候就不需要進行計算了,因為很多函數存在不同返回值,因此必須標明這個函數是有固定返回值的。

4、隱式轉換導致不走索引。
索引不適用於隱式轉換的情況,比如你的SELECT * FROM T WHERE Y = 5 在Y上面有一個索引,但是Y列是VARCHAR2的,那麼Oracle會將上面的5進行一個隱式的轉換,SELECT * FROM T WHERE TO_NUMBER(Y) = 5,這個時候也是有可能用不到索引的。

5、表的資料庫小或者需要選擇大部分數據,不走索引
在Oracle的初始化參數中,有一個參數是一次讀取的數據塊的數目,比如你的表只有幾個數據塊大小,而且可以被Oracle一次性抓取,那麼就沒有使用索引的必要了,因為抓取索引還需要去根據rowid從數據塊中獲取相應的元素值,因此在表特別小的情況下,索引沒有用到是情理當中的事情。
6、cbo優化器下統計信息不準確,導致不走索引
很長時間沒有做表分析,或者重新收集表狀態信息了,在數據字典中,表的統計信息是不準確的,這個情況下,可能會使用錯誤的索引,這個效率可能也是比較低的。
7、!=或者<>(不等於),可能導致不走索引,也可能走 INDEX FAST FULL SCAN
例如select id from test where id<>100
8、表欄位的屬性導致不走索引,字元型的索引列會導致優化器認為需要掃描索引大部分數據且聚簇因子很大,最終導致棄用索引掃描而改用全表掃描方式,
由於字元型和數值型的在insert的時候排序不同,字元類型導致了聚簇因子很大,原因是插入順序與排序順序不同。詳細點說,就是按照數字類型插入(1..3200000),按字元類型('1'...'32000000')t排序,在對字元類型使用大於運算符時,會導致優化器認為需要掃描索引大部分數據且聚簇因子很大,最終導致棄用索引掃描而改用全表掃描方式。

⑽ SQL,索引的例子

就用 mysql 資料庫舉例吧

一、什麼是索引?

索引用來快速地尋找那些具有特定值的記錄,所有MySQL索引都以B-樹的形式保存。如果沒有索引,執行查詢時MySQL必須從第一個記錄開始掃描整個表的所有記錄,直至找到符合要求的記錄。表裡面的記錄數量越多,這個操作的代價就越高。如果作為搜索條件的列上已經創建了索引,MySQL無需掃描任何記錄即可迅速得到目標記錄所在的位置。如果表有1000個記錄,通過索引查找記錄至少要比順序掃描記錄快100倍。

假設我們創建了一個名為people的表:

CREATE TABLE people ( peopleid SMALLINT NOT NULL, name CHAR(50) NOT NULL );

然後,我們完全隨機把1000個不同name值插入到people表。下圖顯示了people表所在數據文件的一小部分:

可以看到,在數據文件中name列沒有任何明確的次序。如果我們創建了name列的索引,MySQL將在索引中排序name列:

對於索引中的每一項,MySQL在內部為它保存一個數據文件中實際記錄所在位置的「指針」。因此,如果我們要查找name等於「Mike」記錄的peopleid(SQL命令為「SELECT peopleid FROM people WHERE name=\'Mike\';」),MySQL能夠在name的索引中查找「Mike」值,然後直接轉到數據文件中相應的行,准確地返回該行的peopleid(999)。在這個過程中,MySQL只需處理一個行就可以返回結果。如果沒有「name」列的索引,MySQL要掃描數據文件中的所有記錄,即1000個記錄!顯然,需要MySQL處理的記錄數量越少,則它完成任務的速度就越快。

二、索引的類型

MySQL提供多種索引類型供選擇:

普通索引

這是最基本的索引類型,而且它沒有唯一性之類的限制。普通索引可以通過以下幾種方式創建:

創建索引,例如CREATE INDEX <索引的名字> ON tablename (列的列表);
修改表,例如ALTER TABLE tablename ADD INDEX [索引的名字] (列的列表);
創建表的時候指定索引,例如CREATE TABLE tablename ( [...], INDEX [索引的名字] (列的列表) );

唯一性索引

這種索引和前面的「普通索引」基本相同,但有一個區別:索引列的所有值都只能出現一次,即必須唯一。唯一性索引可以用以下幾種方式創建:

創建索引,例如CREATE UNIQUE INDEX <索引的名字> ON tablename (列的列表);
修改表,例如ALTER TABLE tablename ADD UNIQUE [索引的名字] (列的列表);
創建表的時候指定索引,例如CREATE TABLE tablename ( [...], UNIQUE [索引的名字] (列的列表) );

主鍵

主鍵是一種唯一性索引,但它必須指定為「PRIMARY KEY」。如果你曾經用過AUTO_INCREMENT類型的列,你可能已經熟悉主鍵之類的概念了。主鍵一般在創建表的時候指定,例如「CREATE TABLE tablename ( [...], PRIMARY KEY (列的列表) ); 」。但是,我們也可以通過修改表的方式加入主鍵,例如「ALTER TABLE tablename ADD PRIMARY KEY (列的列表); 」。每個表只能有一個主鍵。

全文索引

MySQL從3.23.23版開始支持全文索引和全文檢索。在MySQL中,全文索引的索引類型為FULLTEXT。全文索引可以在VARCHAR或者TEXT類型的列上創建。它可以通過CREATE TABLE命令創建,也可以通過ALTER TABLE或CREATE INDEX命令創建。對於大規模的數據集,通過ALTER TABLE(或者CREATE INDEX)命令創建全文索引要比把記錄插入帶有全文索引的空表更快。本文下面的討論不再涉及全文索引,要了解更多信息,請參見MySQL documentation。

三、單列索引與多列索引

索引可以是單列索引,也可以是多列索引。下面我們通過具體的例子來說明這兩種索引的區別。假設有這樣一個people表:

ALTER TABLE people ADD INDEX fname_lname_age (firstname,lastname,age);

由於索引文件以B-樹格式保存,MySQL能夠立即轉到合適的firstname,然後再轉到合適的lastname,最後轉到合適的age。在沒有掃描數據文件任何一個記錄的情況下,MySQL就正確地找出了搜索的目標記錄!

那麼,如果在firstname、lastname、age這三個列上分別創建單列索引,效果是否和創建一個firstname、lastname、age的多列索引一樣呢?答案是否定的,兩者完全不同。當我們執行查詢的時候,MySQL只能使用一個索引。如果你有三個單列的索引,MySQL會試圖選擇一個限制最嚴格的索引。但是,即使是限制最嚴格的單列索引,它的限制能力也肯定遠遠低於firstname、lastname、age這三個列上的多列索引。

四、最左前綴

多列索引還有另外一個優點,它通過稱為最左前綴(Leftmost Prefixing)的概念體現出來。繼續考慮前面的例子,現在我們有一個firstname、lastname、age列上的多列索引,我們稱這個索引為fname_lname_age。當搜索條件是以下各種列的組合時,MySQL將使用fname_lname_age索引:

firstname,lastname,age
firstname,lastname
firstname
從另一方面理解,它相當於我們創建了(firstname,lastname,age)、(firstname,lastname)以及(firstname)這些列組合上的索引。下面這些查詢都能夠使用這個fname_lname_age索引:

table type possible_keys key key_len ref rows Extra people ref fname_lname_age fname_lname_age 102 const,const,const 1 Where used
下面我們就來看看這個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上執行。