在當(dāng)今信息化時(shí)代，數(shù)據(jù)庫(kù)已經(jīng)成為各種企業(yè)、機(jī)構(gòu)和組織中必不可少的數(shù)據(jù)管理工具，通過(guò)對(duì)各類數(shù)據(jù)進(jìn)行存儲(chǔ)、查詢、更新等操作，為組織決策和業(yè)務(wù)運(yùn)營(yíng)提供重要的支撐。然而，如果不對(duì)數(shù)據(jù)庫(kù)的性能進(jìn)行優(yōu)化，長(zhǎng)時(shí)間使用容易出現(xiàn)查詢緩慢甚至崩潰的問(wèn)題，給用戶和業(yè)務(wù)帶來(lái)相當(dāng)大的困擾和損失。為了解決這類問(wèn)題，本文將探討一種。

成都創(chuàng)新互聯(lián)于2013年開(kāi)始，先為湟源等服務(wù)建站，湟源等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為湟源企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

什么是多字段索引？

一般來(lái)說(shuō)，當(dāng)我們需要對(duì)數(shù)據(jù)庫(kù)中的一張表進(jìn)行復(fù)雜查詢時(shí)，比如需要查詢多個(gè)字段的值滿足特定條件的記錄，如果使用單字段索引，則需要針對(duì)每個(gè)字段各創(chuàng)建一個(gè)索引，這樣在查詢時(shí)需要對(duì)所有索引進(jìn)行遍歷，顯然速度很慢。而多字段索引則是指針對(duì)多個(gè)字段創(chuàng)建一個(gè)索引，比如CREATE INDEX idxname ON tablename (field1, field2, ……, fieldn)，這樣只需要對(duì)一個(gè)索引進(jìn)行遍歷，提高了查詢效率。

多字段索引的使用場(chǎng)景

在什么情況下需要使用多字段索引呢？以下是幾個(gè)可能的場(chǎng)景：

1. 復(fù)合查詢：如果查詢需要滿足多個(gè)條件，比如SELECT * FROM employees WHERE department=’sales’ AND salary>5000 AND age

2. 順序查詢：如果查詢需要按照某個(gè)字段的順序進(jìn)行排序或分組，比如SELECT * FROM employees ORDER BY department, salary，則可以針對(duì)department和salary這兩個(gè)字段創(chuàng)建一個(gè)多字段索引，這樣可以避免對(duì)兩個(gè)字段分別進(jìn)行排序或分組，提高效率。

3. 子查詢：如果查詢涉及到嵌套子查詢，比如SELECT salesperson, department, sales_amount FROM sales WHERE sales_amount > (SELECT AVG(sales_amount) FROM sales)，則可以針對(duì)sales_amount這個(gè)字段創(chuàng)建一個(gè)索引，同時(shí)salesperson和department也可以加入到多字段索引中，這樣可以提高子查詢和連接操作的效率。

4. 類型轉(zhuǎn)換：如果查詢涉及到對(duì)字段類型進(jìn)行轉(zhuǎn)換，比如SELECT * FROM orders WHERE DATE_FORMAT(order_date,’%Y-%m-%d’)=’2023-05-01’，則可以創(chuàng)建一個(gè)多字段索引，包括order_date和DATE_FORMAT(order_date,’%Y-%m-%d’)，這樣可以避免對(duì)每個(gè)記錄進(jìn)行類型轉(zhuǎn)換。

需要注意的是，在創(chuàng)建多字段索引時(shí)，需要根據(jù)實(shí)際使用場(chǎng)景權(quán)衡各個(gè)字段的順序，確定多字段索引的順序，這樣可以避免不必要的索引遍歷，影響查詢效率。

多字段索引的優(yōu)點(diǎn)和缺點(diǎn)

與單字段索引相比，多字段索引具有以下優(yōu)點(diǎn)：

1. 提高查詢效率：多字段索引可以避免對(duì)多個(gè)單字段索引進(jìn)行遍歷，從而提高查詢效率。

2. 減少索引數(shù)量：通過(guò)使用多字段索引可以減少索引的數(shù)量，避免不必要的維護(hù)和資源占用。

3. 提高空間利用率：多字段索引可以將多個(gè)索引合并到一起，提高空間利用率。

不過(guò)，多字段索引也有一些缺點(diǎn)：

1. 創(chuàng)建和維護(hù)成本高：與單字段索引相比，多字段索引創(chuàng)建和維護(hù)成本更高，需要耗費(fèi)更多的資源和時(shí)間。

2. 可能增加查詢復(fù)雜度：如果多字段索引的順序不當(dāng)，可能會(huì)增加查詢復(fù)雜度，降低查詢效率。

3. 可能導(dǎo)致磁盤(pán)占用增加：多字段索引占用的磁盤(pán)空間可能更大，特別是如果需要對(duì)多個(gè)字段進(jìn)行數(shù)據(jù)類型轉(zhuǎn)換時(shí)。

如何創(chuàng)建多字段索引

創(chuàng)建多字段索引需要注意以下幾點(diǎn)：

1. 在確定需要?jiǎng)?chuàng)建多字段索引時(shí)，需要先選擇需要建立索引的字段，盡量避免選擇過(guò)多的字段。

2. 根據(jù)實(shí)際使用場(chǎng)景選擇合適的字段順序，避免不必要的索引遍歷。

3. 在創(chuàng)建多字段索引時(shí)需要考慮磁盤(pán)空間和資源占用的成本，并進(jìn)行必要的優(yōu)化和調(diào)整。

4. 注意維護(hù)索引的一致性和可用性，定期進(jìn)行索引優(yōu)化和重建。

使用多字段索引可以大大提高數(shù)據(jù)庫(kù)查詢效率，從而促進(jìn)業(yè)務(wù)運(yùn)營(yíng)的高效發(fā)展。然而，需要注意的是，在實(shí)際使用過(guò)程中，需要綜合考慮多個(gè)因素，包括數(shù)據(jù)庫(kù)的大小、訪問(wèn)頻率、查詢條件等，選擇合適的索引類型和數(shù)量。只有在實(shí)際場(chǎng)景中合理使用多字段索引，才能發(fā)揮更大的優(yōu)勢(shì)。

相關(guān)問(wèn)題拓展閱讀：

• MySQL最多可建立多少索引和索引的限制
• 在Oracle中合理創(chuàng)建數(shù)據(jù)庫(kù)的索引
• 數(shù)據(jù)庫(kù)的索引以及在哪些列上創(chuàng)建索引

MySQL最多可建立多少索引和索引的限制

MySQL

索引

類型包括：

一、普通索引

這是最基本的索引，它沒(méi)有任何限制。有以下幾種創(chuàng)建方式：

1.創(chuàng)建索引

代碼如下:

CREATE INDEX indexName ON mytable(username(length));

如果是CHAR，VARCHAR類型，length可以小于字段實(shí)際長(zhǎng)度；如果是BLOB和TEXT類型，必須指定 length，下同。

2.修改表結(jié)構(gòu)

代碼如下:

ALTER mytable ADD INDEX ON (username(length)) — 創(chuàng)建表的時(shí)候直接指定。

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX (username(length)) );

— 刪除索引的語(yǔ)法：

DROP INDEX ON mytable;

二、唯一索引

它與前面的普通索引類似，不同的就是：索引列的值必須唯一，但允許有空值。如果是組合索引，則列值的組合必運(yùn)賣須唯一。它有以下幾種創(chuàng)建方式：

代碼如下:

CREATE UNIQUE INDEX indexName ON mytable(username(length))

— 修旁清逗改表結(jié)構(gòu)

ALTER mytable ADD UNIQUE ON (username(length))

— 創(chuàng)建表的時(shí)候直接指定

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, UNIQUE (username(length)) );

三、

主鍵

索引

它是一種特殊的唯一索引，不允許有空值。一般是在建表的時(shí)候同時(shí)創(chuàng)建主鍵索引：

代碼如下:

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) );

當(dāng)然也可以用 ALTER 命令。記?。阂粋€(gè)表只能有一個(gè)主鍵。

四、組合索引

為了形象地對(duì)比單列索引和組合索引，為表添加多個(gè)字段：

代碼如下:

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL );

為了進(jìn)一步榨取MySQL的效率，就要考慮建立組合索引。

二：使用索引的注意事項(xiàng)

使用索引時(shí)，有以下一些技巧和注意事項(xiàng)：

1.索引不會(huì)包含有NULL值的列

只要列中包含有NULL值都將不會(huì)被包含在索引中，復(fù)合索引中只要有一列含有NULL值，那么這一列對(duì)于此復(fù)合索引就是無(wú)效的。所以我們?cè)?/p>

數(shù)據(jù)庫(kù)設(shè)計(jì)

時(shí)不要讓字段的默認(rèn)值為NULL。

2.使用短索引

對(duì)串列進(jìn)行索引，如果可能應(yīng)該指定一個(gè)前綴長(zhǎng)度。例如，如果有一個(gè)CHAR(255)的列，如正好果在前10個(gè)或20個(gè)字符內(nèi)，多數(shù)值是惟一的，那么就不要對(duì)整個(gè)列進(jìn)行索引。短索引不僅可以提高查詢速度而且可以節(jié)省磁盤(pán)空間和I/O操作。

3.索引列排序

MySQL查詢只使用一個(gè)索引，因此如果where子句中已經(jīng)使用了索引的話，那么

order by

中的列是不會(huì)使用索引的。因此數(shù)據(jù)庫(kù)默認(rèn)排序可以符合要求的情況下不要使用排序操作；盡量不要包含多個(gè)列的排序，如果需要更好給這些列創(chuàng)建復(fù)合索引。

4.like語(yǔ)句操作

一般情況下不鼓勵(lì)使用like操作，如果非使用不可，如何使用也是一個(gè)問(wèn)題。like “%aaa%” 不會(huì)使用索引而like “aaa%”可以使用索引。

5.不要在列上進(jìn)行運(yùn)算

select * from users where YEAR(adddate)操作。

三：sql優(yōu)化原則

常見(jiàn)的簡(jiǎn)化規(guī)則如下：

1.不要有超過(guò)5個(gè)以上的表連接（JOIN）

2.考慮使用臨時(shí)表或表變量存放中間結(jié)果。

3.少用子查詢

4.視圖嵌套不要過(guò)深,一般視圖嵌套不要超過(guò)2個(gè)為宜。

5.連接的表越多，其編譯的時(shí)間和連接的開(kāi)銷也越大，性能越不好控制。

6.更好是把連接拆開(kāi)成較小的幾個(gè)部分逐個(gè)順序執(zhí)行。

7.優(yōu)先執(zhí)行那些能夠大量減少結(jié)果的連接。

8.拆分的好處不僅僅是減少SQL Server優(yōu)化的時(shí)間，更使得SQL語(yǔ)句能夠以你可以預(yù)測(cè)的方式和順序執(zhí)行。

如果一定需要連接很多表才能得到數(shù)據(jù)，那么很可能意味著設(shè)計(jì)上的缺陷。

在滿足語(yǔ)句需求的情況下，盡盯巧量少的訪問(wèn)資源是數(shù)據(jù)庫(kù)設(shè)計(jì)的重要原則，這和執(zhí)行的 SQL 有直接的關(guān)系，索引問(wèn)題又是 SQL 問(wèn)題中出現(xiàn)頻率更高的，常見(jiàn)的索引問(wèn)題包括：無(wú)索引（失效）、隱式轉(zhuǎn)換。

1. SQL 執(zhí)行流程看一個(gè)問(wèn)題，在下面這個(gè)表 T 中，如果我要執(zhí)行 select * from T where k between 3 and 5; 需要執(zhí)行幾次樹(shù)的搜索操作，會(huì)掃描多少行？mysql> create table T (    -> ID int primary key,    -> k int NOT NULL DEFAULT 0,    -> s varchar(16) NOT NULL DEFAULT ”,    -> index k(k))    -> engine=InnoDB;mysql> insert into T values(100,1, ‘a(chǎn)a’),(200,2,’bb’),\      (300,3,’或慧cc’),(500,5,’ee’),(600,6,’ff’),(700,7,’gg’);

這分別是 ID 字段索引樹(shù)、k 字段索引樹(shù)。 

這條 SQL 語(yǔ)句的執(zhí)行流程：

1. 在 k 索引樹(shù)上找到 k=3，獲得 ID=3002. 回表到 ID 索引樹(shù)查找 ID=300 的記錄，對(duì)應(yīng) R33. 在 k 索引樹(shù)找到下一個(gè)值 k=5，ID=5004. 再回到 ID 索引樹(shù)找到對(duì)應(yīng) ID=500 的 R4

5. 在 k 索引樹(shù)去下一個(gè)值 k=6，不符合條件，循環(huán)結(jié)束

這個(gè)過(guò)程讀取了 k 索引樹(shù)的三條記錄，回表了兩次。因?yàn)椴樵兘Y(jié)果所需要的數(shù)據(jù)只在主鍵索引上有，所以必須得回表。所以，我們?cè)撊绾瓮ㄟ^(guò)優(yōu)化索引，來(lái)避免回表呢？

2. 常見(jiàn)索引優(yōu)化2.1 覆蓋索引覆蓋索引，換言之就是索引要覆蓋我們的查詢請(qǐng)求，無(wú)需回表。

如果執(zhí)行的語(yǔ)句是 select ID from T wherek between 3 and 5;，這樣的話因?yàn)?ID 的值在 k 索引樹(shù)上，就不需要回表了。

覆蓋索引可以減少樹(shù)的搜索次數(shù)，顯著提升查詢性能，是常用的性能優(yōu)化手衫則答段。

但是，維護(hù)索引是有代價(jià)的，所以在建立冗余索引來(lái)支持覆蓋索引時(shí)要權(quán)衡利弊。

2.2 最左前綴原則

B+ 樹(shù)的數(shù)據(jù)項(xiàng)是復(fù)合的數(shù)據(jù)結(jié)構(gòu)，比如 (name,sex，age) 的時(shí)候，B+ 樹(shù)是按照從左到右的順序來(lái)建立搜索樹(shù)的，當(dāng) (張三,F,26) 這樣的數(shù)據(jù)來(lái)檢索的時(shí)候，B+ 樹(shù)會(huì)優(yōu)先比較 name 來(lái)確定下一步的檢索方向，如果 name 相同再依次比較 sex 和 age，最后得到檢索的數(shù)據(jù)。

# 有這樣一個(gè)表 P

mysql> create table P (id int primary key, name varchar(10) not null, sex varchar(1), age int, index tl(name,sex,age)) engine=IInnoDB;

mysql> insert into P values(1,’張三’,’F’,26),(2,’張三’,’M’,27),(3,’李四’,’F’,28),(4,’烏茲’,’F’,22),(5,’張三’,’M’,21),(6,’王五’,’M’,28);

# 下面的語(yǔ)句結(jié)果相同

mysql> select * from P where name=’張三’ and sex=’F’;     ## A1

mysql> select * from P where sex=’F’ and age=26;## A2

# explain 看一下

mysql> explain select * from P where name=’張三’ and sex=’F’;

+—-++++——+-+——+++——+++

| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref| rows | filtered | Extra|

+—-++++——+-+——+++——+++

|  1 | SIMPLE      | P     | NULL| ref  | tl| tl   || const,const |    1 |   100.00 | Using index |

+—-++++——+-+——+++——+++

mysql> explain select * from P where sex=’F’ and age=26;

+—-+++++-+——++——+——+++

| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra      |

+—-+++++-+——++——+——+++

|  1 | SIMPLE      | P     | NULL| index | NULL| tl   || NULL |    6 |    16.67 | Using where; Using index |

+—-+++++-+——++——+——+++

可以清楚的看到，A1 使用 tl 索引，A2 進(jìn)行了全表掃描，雖然 A2 的兩個(gè)條件都在 tl 索引中出現(xiàn)，但是沒(méi)有使用到 name 列，不符合最左前綴原則，無(wú)法使用索引。所以在建立聯(lián)合索引的時(shí)候，如何安排索引內(nèi)的字段排序是關(guān)鍵。評(píng)估標(biāo)準(zhǔn)是索引的復(fù)用能力，因?yàn)橹С肿钭笄熬Y，所以當(dāng)建立（a，b）這個(gè)聯(lián)合索引之后，就不需要給 a 單獨(dú)建立索引。原則上，如果通過(guò)調(diào)整順序，可以少維護(hù)一個(gè)索引，那么這個(gè)順序往往就是需要優(yōu)先考慮采用的。上面這個(gè)例子中，如果查詢條件里只有 b，就是沒(méi)法利用（a，b）這個(gè)聯(lián)合索引的，這時(shí)候就不得不維護(hù)另一個(gè)索引，也就是說(shuō)要同時(shí)維護(hù)（a，b）、（b）兩個(gè)索引。這樣的話，就需要考慮空間占用了，比如，name 和 age 的聯(lián)合索引，name 字段比 age 字段占用空間大，所以創(chuàng)建（name，age）聯(lián)合索引和（age）索引占用空間是要小于（age，name）、(name）索引的。

2.3 索引下推

以人員表的聯(lián)合索引（name, age）為例。如果現(xiàn)在有一個(gè)需求：檢索出表中“名字之一個(gè)字是張，而且年齡是26歲的所有男性”。那么，SQL 語(yǔ)句是這么寫(xiě)的mysql> select * from tuser where name like ‘張%’ and age=26 and sex=M;

通過(guò)最左前綴索引規(guī)則，會(huì)找到 ID1，然后需要判斷其他條件是否滿足在 MySQL 5.6 之前，只能從 ID1 開(kāi)始一個(gè)個(gè)回表。到主鍵索引上找出數(shù)據(jù)行，再對(duì)比字段值。而 MySQL 5.6 引入的索引下推優(yōu)化(index condition pushdown)，可以在索引遍歷過(guò)程中，對(duì)索引中包含的字段先做判斷，直接過(guò)濾掉不滿足條件的記錄，減少回表次數(shù)。這樣，減少了回表次數(shù)和之后再次過(guò)濾的工作量，明顯提高檢索速度。

2.4 隱式類型轉(zhuǎn)化

隱式類型轉(zhuǎn)化主要原因是，表結(jié)構(gòu)中指定的數(shù)據(jù)類型與傳入的數(shù)據(jù)類型不同，導(dǎo)致索引無(wú)法使用。所以有兩種方案：

修改表結(jié)構(gòu)，修改字段數(shù)據(jù)類型。

修改應(yīng)用，將應(yīng)用中傳入的字符類型改為與表結(jié)構(gòu)相同類型。

3. 為什么會(huì)選錯(cuò)索引3.1 優(yōu)化器選擇索引是優(yōu)化器的工作，其目的是找到一個(gè)更優(yōu)的執(zhí)行方案，用最小的代價(jià)去執(zhí)行語(yǔ)句。在數(shù)據(jù)庫(kù)中，掃描行數(shù)是影響執(zhí)行代價(jià)的因素之一。掃描的行數(shù)越少，意味著訪問(wèn)磁盤(pán)數(shù)據(jù)的次數(shù)越少，消耗的 CPU 資源越少。當(dāng)然，掃描行數(shù)并不是唯一的判斷標(biāo)準(zhǔn)，優(yōu)化器還會(huì)結(jié)合是否使用臨時(shí)表、是否排序等因素進(jìn)行綜合判斷。

3.2 掃描行數(shù)

MySQL 在真正開(kāi)始執(zhí)行語(yǔ)句之前，并不能精確的知道滿足這個(gè)條件的記錄有多少條，只能通過(guò)索引的區(qū)分度來(lái)判斷。顯然，一個(gè)索引上不同的值越多，索引的區(qū)分度就越好，而一個(gè)索引上不同值的個(gè)數(shù)我們稱為“基數(shù)”，也就是說(shuō)，這個(gè)基數(shù)越大，索引的區(qū)分度越好。# 通過(guò) show index 方法，查看索引的基數(shù)mysql> show index from t;++++++++++——+++-+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |++++++++++——+++-+| t     || PRIMARY  || id| A||     NULL | NULL   |      | REE      || || t     || a|| a| A||     NULL | NULL   | YES  | REE      || || t     || b|| b| A||     NULL | NULL   | YES  | REE      || |++++++++++——+++-+

MySQL 使用采樣統(tǒng)計(jì)方法來(lái)估算基數(shù)：采樣統(tǒng)計(jì)的時(shí)候，InnoDB 默認(rèn)會(huì)選擇 N 個(gè)數(shù)據(jù)頁(yè)，統(tǒng)計(jì)這些頁(yè)面上的不同值，得到一個(gè)平均值，然后乘以這個(gè)索引的頁(yè)面數(shù)，就得到了這個(gè)索引的基數(shù)。而數(shù)據(jù)表是會(huì)持續(xù)更新的，索引統(tǒng)計(jì)信息也不會(huì)固定不變。所以，當(dāng)變更的數(shù)據(jù)行數(shù)超過(guò) 1/M 的時(shí)候，會(huì)自動(dòng)觸發(fā)重新做一次索引統(tǒng)計(jì)。

在 MySQL 中，有兩種存儲(chǔ)索引統(tǒng)計(jì)的方式，可以通過(guò)設(shè)置參數(shù) innodb_stats_persistent 的值來(lái)選擇：

on 表示統(tǒng)計(jì)信息會(huì)持久化存儲(chǔ)。默認(rèn) N = 20，M = 10。

off 表示統(tǒng)計(jì)信息只存儲(chǔ)在內(nèi)存中。默認(rèn) N = 8，M = 16。

由于是采樣統(tǒng)計(jì)，所以不管 N 是 20 還是 8，這個(gè)基數(shù)都很容易不準(zhǔn)確。所以，冤有頭債有主，MySQL 選錯(cuò)索引，還得歸咎到?jīng)]能準(zhǔn)確地判斷出掃描行數(shù)。

可以用 yze table 來(lái)重新統(tǒng)計(jì)索引信息，進(jìn)行修正。

ANAZE TABLE tbl_name …

在Oracle中合理創(chuàng)建數(shù)據(jù)庫(kù)的索引

在Oracle數(shù)據(jù)庫(kù)中 創(chuàng)建索引雖然比較簡(jiǎn)單 但是要合理的創(chuàng)建索引則比較困慧塌難了 筆者認(rèn)為 在創(chuàng)建索引時(shí)要做到三個(gè)適當(dāng) 即在適當(dāng)?shù)谋砩?適當(dāng)?shù)牧猩蟿?chuàng)建適當(dāng)數(shù)量的索引 雖然這可以通過(guò)一句話來(lái)概括優(yōu)化的索引的基本準(zhǔn)則 但是要做到這一點(diǎn)的話 需要數(shù)據(jù)庫(kù)管理員做出很大的努力 具體的來(lái)說(shuō) 要做到這個(gè)三個(gè)適當(dāng)有如下幾個(gè)要求

　　

一 根據(jù)表的大小來(lái)創(chuàng)建索引

　　雖然給表創(chuàng)建索引 可以提高查詢的效率 但是數(shù)據(jù)庫(kù)管理員需要注意的是 索引也需要一定的開(kāi)銷的 為此并不是說(shuō)給所有的表都創(chuàng)建索引 那么就可以提高數(shù)據(jù)庫(kù)的性能 這個(gè)認(rèn)識(shí)是錯(cuò)誤的 恰恰相反 如果不管三七二十一 給所有的表都創(chuàng)建了索引 那么其反而會(huì)給數(shù)據(jù)庫(kù)的性能造成負(fù)面的影響 因?yàn)榇藭r(shí)濫用索引的開(kāi)銷可能已經(jīng)遠(yuǎn)遠(yuǎn)大于由此帶來(lái)的性能方面的收益 所以筆者認(rèn)為 數(shù)據(jù)庫(kù)管理員首先需要做到 為合適的表來(lái)建立索引 而不是為所有的表建立索引

　　一般來(lái)說(shuō) 不需要為比較小的表創(chuàng)建索引 如在一個(gè)ERP系統(tǒng)的數(shù)據(jù)庫(kù)中 department表用來(lái)存儲(chǔ)企業(yè)部門(mén)的信息 一般企業(yè)的部分也就十幾個(gè) 最多不會(huì)超過(guò)一百個(gè) 這 條記錄對(duì)于人來(lái)說(shuō) 可能算是比較多了 但是對(duì)于計(jì)算機(jī)來(lái)說(shuō) 這給他塞塞牙縫都還不夠 所以 對(duì)類似的小表沒(méi)有必要建立索引 因?yàn)榧词菇⒘怂饕?其性能也不會(huì)得到很大的改善 相反索引建立的開(kāi)銷 如維護(hù)成本等等 要比這個(gè)要大 也就是說(shuō) 付出的要比得到的多 顯然違反常理

　　另外 就是對(duì)于超大的表 也不一定要建立索引 有些表雖然比較大 記錄數(shù)量非常的多 但是此時(shí)為這個(gè)表建立索引并一定的合適 如系統(tǒng)中有一張表 其主要用來(lái)保存數(shù)據(jù)庫(kù)中的一些變更信息 往往這些信息只給數(shù)據(jù)庫(kù)管理員使用 此時(shí)為這張表建立索引的話 反而不合適 因?yàn)檫@張表很少用到 只有在出問(wèn)題的時(shí)候才需要查看 其次其即使查看 需要查詢的紀(jì)錄也不會(huì)很多 可能就是最近一周的更新記錄等等 對(duì)于對(duì)于一些超大的表 建立索引有時(shí)候往往不能夠達(dá)到預(yù)計(jì)的效果 而且在打表上建立索引 其索引的開(kāi)銷要比普通的表大的多 那么到底是否給大表建立索引呢?筆者認(rèn)為 主要是看兩個(gè)方面的內(nèi)容 首前中圓先是需要關(guān)注一下 在這張大表中經(jīng)常需要查詢的記錄數(shù)量 一般來(lái)說(shuō) 如果經(jīng)常需要查詢的數(shù)據(jù)不超過(guò) %到 %的話 那就沒(méi)有必要為其建立索引的必要 因?yàn)榇藭r(shí)建立索引的開(kāi)銷可能要比性能的改善大的多 這個(gè)比例只是一個(gè)經(jīng)驗(yàn)的數(shù)據(jù) 如果數(shù)據(jù)庫(kù)管理員需要得出一個(gè)比較精確的結(jié)論 那么就需要進(jìn)行測(cè)試分析 即數(shù)據(jù)庫(kù)管理員需要測(cè)試一下全表掃描的時(shí)間 看看其是否比建立索引后的查詢時(shí)間要長(zhǎng)或者短 如果是長(zhǎng)的話 則說(shuō)明有建立索引的必要 但是如果沒(méi)有的話 則說(shuō)明還是全表掃描速度來(lái)的快 此時(shí)也就沒(méi)有必要建立索引了

　　總之 在考慮是否該為表建立索引時(shí) 一般來(lái)說(shuō)小表沒(méi)有建立索引的必要 而對(duì)于打表的話 則需要進(jìn)行實(shí)際情況實(shí)際分析 簡(jiǎn)單一點(diǎn)的 可以根據(jù)大致的比率來(lái)確定 如果要精確一點(diǎn)的 則可以進(jìn)行全表掃描性能分析 以判斷建立索引后是否真的如預(yù)期那樣改善了數(shù)據(jù)庫(kù)性能

　　

二 根據(jù)列的特征來(lái)創(chuàng)建索引

　　列的特點(diǎn)不同 索引創(chuàng)建的效果也不同 數(shù)據(jù)庫(kù)管理員需要了解為哪些列創(chuàng)建索引可以起到事倍功半的效果 同時(shí)也需要了解為哪些列創(chuàng)建索引反而起到的是事倍功半的效果 這有利于他們了解到底給為怎么樣的字段建立索引

　　根據(jù)筆者的經(jīng)驗(yàn) 往往為如下特征的列創(chuàng)建索引能夠起到比較明顯的效果 如對(duì)于一些重復(fù)內(nèi)容比較少的列 特別是對(duì)于那些定義了唯一約束的列 在這些列上建立索引 往往可以起到非常不錯(cuò)的效果 如對(duì)于一些null值的列與非Null值的列培敏混合情況下 如果用戶需要經(jīng)常查詢所有的非Null值記錄的列 則更好為其設(shè)置索引 如果經(jīng)常需要多表連接查詢 在用與連接的列上設(shè)置索引可以達(dá)到事半功倍的效果

　　可見(jiàn) 索引設(shè)置的是否恰當(dāng) 不僅跟數(shù)據(jù)庫(kù)設(shè)計(jì)架構(gòu)有關(guān) 而且還跟企業(yè)的經(jīng)濟(jì)業(yè)務(wù)相關(guān) 為此 對(duì)于一些套裝軟件 雖然一開(kāi)始數(shù)據(jù)庫(kù)管理員已經(jīng)做了索引的優(yōu)化工作 但是隨著后來(lái)經(jīng)濟(jì)數(shù)據(jù)的增加 這個(gè)索引的效果會(huì)越來(lái)越打折扣 這主要是因?yàn)橛涗浀谋砘绊懙搅怂饕齼?yōu)化的效果 所以筆者建議各位數(shù)據(jù)庫(kù)管理員 即使采用的是大牌軟件公司的套裝軟件 也需要隔一段時(shí)間 如一年 對(duì)數(shù)據(jù)庫(kù)的索引進(jìn)行優(yōu)化 該去掉的去掉 該調(diào)整的調(diào)整 以提高數(shù)據(jù)庫(kù)的性能

　　如在數(shù)據(jù)庫(kù)中有一張表是用來(lái)保存用戶信息的 其中有個(gè)字段身份證號(hào)碼 這是一個(gè)唯一的字段 在數(shù)據(jù)庫(kù)設(shè)計(jì)時(shí) 給這個(gè)字段創(chuàng)建了索引 但是當(dāng)這個(gè)數(shù)據(jù)庫(kù)投入使用之后 用戶不怎么輸入用戶的身份證號(hào)碼 而且平時(shí)也基本不按這個(gè)號(hào)碼來(lái)進(jìn)行查詢 當(dāng)記錄月來(lái)月多時(shí) 這個(gè)身份證號(hào)碼上的索引字段不但不能夠改善數(shù)據(jù)庫(kù)的查詢性能 反而成了雞肋 對(duì)于這些有很多NULL值的列 而且不會(huì)經(jīng)常查詢所有的非NULL值記錄的列 數(shù)據(jù)庫(kù)管理員要下決心 即使清除這些列上的索引

　　所以說(shuō)索引的優(yōu)化與調(diào)整是一個(gè)動(dòng)態(tài)的過(guò)程 并不是說(shuō)數(shù)據(jù)庫(kù)設(shè)計(jì)好之后就不需要經(jīng)過(guò)調(diào)整 數(shù)據(jù)庫(kù)管理員往往需要根據(jù)記錄的變化情況 來(lái)進(jìn)行適當(dāng)?shù)淖兏?以提高索引的效果

　　

三 在一個(gè)表上創(chuàng)建多少索引合適?

　　雖然說(shuō) 在表上創(chuàng)建索引的數(shù)量沒(méi)有限制 但是決不是越多越好 也就是說(shuō) 在創(chuàng)建索引這項(xiàng)事情上 + 〉 往往不成立 有時(shí)候 創(chuàng)建索引越多 其可能會(huì)得到適得其反的效果 那么在一個(gè)表上 到底給創(chuàng)建多少索引合適呢?這個(gè)沒(méi)有一個(gè)明確的標(biāo)準(zhǔn) 而是需要數(shù)據(jù)庫(kù)管理員根據(jù)實(shí)際的用途以及數(shù)據(jù)庫(kù)中記錄的情況 來(lái)進(jìn)行判斷

　　通常來(lái)說(shuō) 表的索引越多 其查詢的速度也就越快 但是 表的更新速度則會(huì)降低 這主要是因?yàn)楸淼母?如往表中插入一條記錄)速度 反而隨著索引的增加而增加 這主要是因?yàn)?在更新記錄的同時(shí)需要更新相關(guān)的索引信息 為此 到底在表中創(chuàng)建多少索引合適 就需要在這個(gè)更新速度與查詢速度之間取得一個(gè)均衡點(diǎn) 如對(duì)于一些數(shù)據(jù)倉(cāng)庫(kù)或者決策型數(shù)據(jù)庫(kù)系統(tǒng) 其主要用來(lái)進(jìn)行查詢 相關(guān)的記錄往往是在數(shù)據(jù)庫(kù)初始化的時(shí)候倒入 此時(shí) 設(shè)置的索引多一點(diǎn) 可以提高數(shù)據(jù)庫(kù)的查詢性能 同時(shí)因?yàn)橛涗洸辉趺锤?所以索引比較多的情況下 也不會(huì)影響到更新的速度 即使在起初的時(shí)候需要導(dǎo)入大量的數(shù)據(jù) 此時(shí)也可以先將索引禁用掉 等到數(shù)據(jù)導(dǎo)入完畢后 再啟用索引 可以通過(guò)這種方式來(lái)減少索引對(duì)數(shù)據(jù)更新的影響 相反 如果那些表中經(jīng)常需要更新記錄 如一些事務(wù)型的應(yīng)用系統(tǒng) 數(shù)據(jù)更新操作是家常便飯的事情 此時(shí)如果在一張表中建立過(guò)多的索引 則會(huì)影響到更新的速度 由于更新操作比較頻繁 所以對(duì)其的負(fù)面影響 要比查詢效率提升要大的多 此時(shí)就需要限制索引的數(shù)量 只在一些必要的字段上建立索引

　　筆者在平時(shí)數(shù)據(jù)庫(kù)優(yōu)化時(shí) 往往會(huì)根據(jù)這些表的用途來(lái)為列設(shè)置索引 可以查詢相關(guān)的動(dòng)態(tài)視圖 看看對(duì)于這張表的操作 是更新操作(包括更新 刪除 插入等等)占的比例大 還是查詢操作占的比例大 當(dāng)過(guò)多的索引已經(jīng)影響到更新操作的速度時(shí) 則數(shù)據(jù)庫(kù)管理員就需要先禁用某些索引 以提高數(shù)據(jù)庫(kù)的性能

lishixinzhi/Article/program/Oracle/202311/18407

數(shù)據(jù)庫(kù)的索引以及在哪些列上創(chuàng)建索引

選擇開(kāi)始菜單中→程序→【management

sql

server

2023】→【sql

server

management

studio】命令，打開(kāi)【sql

server

management

studio】窗口，并使用windows或

sql

server身份驗(yàn)證建立連接。

在【對(duì)象資源管理器】窗口中展開(kāi)服務(wù)器，然后選擇【數(shù)據(jù)庫(kù)】節(jié)點(diǎn)

右鍵單擊【數(shù)據(jù)庫(kù)】節(jié)點(diǎn)，從彈出來(lái)的快捷菜單中選擇【新建數(shù)據(jù)庫(kù)】命令。

執(zhí)行上述操作后，會(huì)彈出【新察畢此建數(shù)據(jù)庫(kù)】對(duì)話框。在對(duì)話框、左側(cè)有3個(gè)選項(xiàng)，分別是【常規(guī)】、【選項(xiàng)】和【文件組】。完成這三個(gè)選項(xiàng)中的設(shè)置會(huì)后，就完成了數(shù)據(jù)庫(kù)的創(chuàng)建工作，

在【數(shù)據(jù)庫(kù)名稱】文本框中數(shù)閉輸入要新建數(shù)據(jù)庫(kù)的名稱。例如，這里以“新建的數(shù)據(jù)庫(kù)”。

在【所有者】文本框中輸入新敗迅建數(shù)據(jù)庫(kù)的所有者，如sa。根據(jù)數(shù)據(jù)庫(kù)的使用情況，選擇啟用或者禁用【使用全文索引】復(fù)選框。

在【數(shù)據(jù)庫(kù)文件】列表中包括兩行，一行是數(shù)據(jù)庫(kù)文件，而另一行是日記文件。通過(guò)單擊下面的【添加】、【刪除】按鈕添加或刪除數(shù)據(jù)庫(kù)文件。

切換到【選項(xiàng)頁(yè)】、在這里可以設(shè)置數(shù)據(jù)庫(kù)的排序規(guī)則、恢復(fù)模式、兼容級(jí)別和其他屬性。

切換到【文件組】頁(yè)，在這里可以添加或刪除文件組。

完成以上操作后，單擊【確定】按鈕關(guān)閉【新建數(shù)據(jù)庫(kù)】對(duì)話框。至此“新建的數(shù)據(jù)”數(shù)據(jù)庫(kù)創(chuàng)建成功。新建的數(shù)據(jù)庫(kù)可以再【對(duì)象資源管理器】窗口看到。

數(shù)據(jù)庫(kù)創(chuàng)建多字段索引的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于數(shù)據(jù)庫(kù)創(chuàng)建多字段索引,提高數(shù)據(jù)庫(kù)查詢效率的方法：創(chuàng)建多字段索引,MySQL最多可建立多少索引和索引的限制,在Oracle中合理創(chuàng)建數(shù)據(jù)庫(kù)的索引,數(shù)據(jù)庫(kù)的索引以及在哪些列上創(chuàng)建索引的信息別忘了在本站進(jìn)行查找喔。

香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開(kāi)通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過(guò)10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開(kāi)發(fā)經(jīng)驗(yàn)。專業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊(cè)、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。

新聞標(biāo)題：提高數(shù)據(jù)庫(kù)查詢效率的方法：創(chuàng)建多字段索引(數(shù)據(jù)庫(kù)創(chuàng)建多字段索引)
URL鏈接：http://uogjgqi.cn/article/coddojc.html