本文是面試基礎的第二篇。本篇偏理論，包括三節：

• 事務和并發

• 數據庫設計

• 索引

所選的三個內容均是面試的高頻考察點，需要細致地理解

No.1?????事務和并發

---

事務：數據庫操作的基本單元。對于數據庫的一系列操作，要么全部成功，要么全部失敗

1. 事務的ACID屬性

原子性(Atomic)

一個事務包含多個操作，這些操作要么全部執行，要么全都不執行。實現事務的原子性，要支持回滾操作，在某個操作失敗后，回滾到事務執行之前的狀態。

回滾實際上是一個比較高層抽象的概念。大多數DB在實現事務時，是在事務操作的數據快照上進行的，執行事務時并不修改實際的數據，只有事務完成后才會提交到數據庫，完成對數據庫的修改。如有錯，則不會提交，所以很自然的支持回滾。

而在其他支持簡單事務的系統中，不會在快照上更新，而直接操作實際數據。可以先預演一邊所有要執行的操作，如果失敗則這些操作不會被執行，通過這種方式很簡單的實現了原子性。

一致性(Consistency)

一致性是指事務使得系統從一個一致的狀態轉換到另一個一致狀態。事務的一致性決定了一個系統設計和實現的復雜度。事務可以不同程度的一致性：強一致性：讀操作可以立即讀到提交的更新操作弱一致性：提交的更新操作，不一定立即會被讀操作讀到，此種情況會存在一個不一致窗口，指的是讀操作可以讀到最新值的一段時間最終一致性：是弱一致性的特例。事務更新一份數據，最終一致性保證在沒有其他事務更新同樣的值的話，最終所有的事務都會讀到之前事務更新的最新值。如果沒有錯誤發生，不一致窗口的大小依賴于：通信延遲，系統負載等。其他一致性變體還有：單調一致性：如果一個進程已經讀到一個值，那么后續不會讀到更早的值。會話一致性：保證客戶端和服務器交互的會話過程中，讀操作可以讀到更新操作后的最新值。

隔離性(Isolation)

并發事務之間互相影響的程度，比如一個事務會不會讀取到另一個未提交的事務修改的數據。在事務并發操作時，可能出現的問題有：臟讀：事務A修改了一個數據，但未提交，事務B讀到了事務A未提交的更新結果，如果事務A提交失敗，事務B讀到的就是臟數據。不可重復讀：在同一個事務中，對于同一份數據讀取到的結果不一致。比如，事務B在事務A提交前讀到的結果，和提交后讀到的結果可能不同。不可重復讀出現的原因就是事務并發修改記錄，要避免這種情況，最簡單的方法就是對要修改的記錄加鎖，這會導致鎖競爭加劇，影響性能。另一種方法是通過MVCC可以在無鎖的情況下，避免不可重復讀。幻讀：在同一個事務中，同一個查詢多次返回的結果不一致。事務A新增了一條記錄，事務B在事務A提交前后各執行了一次查詢操作，發現后一次比前一次多了一條記錄。幻讀是由于并發事務增加記錄導致的，這個不能像不可重復讀通過記錄加鎖解決，因為對于新增的記錄根本無法加鎖。需要將事務串行化，才能避免幻讀。為解決上述問題，需要在并發和隔離進行平衡。事務的隔離級別從低到高有：Read Uncommitted：未提交讀，最低的隔離級別，一個事務可以讀到另一個事務未提交的結果。所有的并發事務問題都會發生。Read Committed：提交讀。只有在事務提交后，其更新結果才會被其他事務看見。可以解決臟讀問題。Repeated Read：可重復讀。在一個事務中，對于同一份數據的讀取結果總是相同的，無論是否有其他事務對這份數據進行操作，以及這個事務是否提交。可以解決臟讀、不可重復讀。Serialization：串行化。事務串行化執行，隔離級別最高，犧牲了系統的并發性。可以解決并發事務的所有問題。通常，在工程實踐中，為了性能的考慮會對隔離性進行折中。

持久性(Durability)

事務提交后，對數據庫的影響是永久的。

2. 四種隔離級別

在MySQL中設置隔離級別：

查看當前隔離級別：

show variables like 'transaction_isolation'

結果為可重復讀

設置下次事務的隔離級別：

set transaction isolation level serializable

設置將來所有事務的隔離級別：

set?session?transaction?isolation?level?serializable

設置全局事務的隔離級別：

set global transaction isolation level serializable

下面利用具體例子來解釋四種隔離級別的含義，以及可能會出現的問題。假設有兩個事務A和B

1. 未提交讀：read uncommitted

原本A事務想讀50的余額，在讀的過程中因為B的修改，造成讀的結果為100，但由于B事務最后回滾了，數據庫中最終張三的余額還是50，即查詢結果并不為數據庫的最終真實結果。該現象稱為臟讀(dirty read)

2. 提交讀：commit read

為避免臟讀，最直接的做法是屏蔽掉沒有提交的修改。下圖中事務B真正將修改持久到數據庫中后，才會對事務A產生影響。

但這又回造成新的問題。假設A事務中有兩次查詢，第一次查詢得到結果50，第二次查詢之前，B事務修改余額為100并提交，那么A事務中的第二次查詢得到的結果為100。這樣在同一個事務中，兩次查詢結果不同，該現象稱為不可重復讀。

3. 可重復讀：repeatable read

為解決上述問題，可以給數據加上時間戳，規定每次讀的都是開啟事務時刻的數據庫數據。這樣即使在事務處理期間，數據庫發生了變化，也不會對本事務產生影響。該處理方式稱為快照，相當于開始事務時，對數據庫進行一個記錄，之后事務的進行都以之為準。

但是這又帶來新的問題。可重復讀意味著，A事務處理期間，數據庫的任何改變都不會被感知，這種做法雖然保證了可重復讀的一致性，但是也丟失了B事務的有用修改，會引起幻讀現象。

4. 串行化：serialization

一張表一次只能被一個事務訪問，完全沒有并發。每個事務占用一張表時，會將該表上鎖。表處于鎖定期間，其他事務只能等待。只有當占有該表的事務結束，該表才會被釋放。

因此，當兩個事務互相等待時，便會造成死鎖現象。

一般發生死鎖的四個必要條件為：

• 互斥條件：一個資源每次只能被一個進程使用

• 占有且等待：一個進程因請求資源而阻塞時，對已獲得的資源保持不放

• 不可剝奪：進程已獲得的資源，在末使用完之前，不能強行剝奪

• 循環等待條件：若干進程之間形成一種頭尾相接的循環等待資源關系

解決死鎖的途徑：

打破上述四個條件中的一個或多個。例如設置事務執行時間，一旦timeout，則該事務自動回滾并釋放資源。再比如，在寫并發執行的SQL語句時，盡量按照相同的處理次序，這樣至多只會出現爭搶，避免形成循環等待。

No.2????設計數據庫

---

1.?基本過程

一個設計合理的數據庫，將大大提高讀寫效率和擴展性。設計數據庫，由表及里，包含四個步驟：

1. 理解需求：對象是什么，滿足什么功能2. 構建概念模型：確定實體有哪些，實體之間什么關系3. 構建邏輯模型：對概念模型進行具體化，確定有哪幾張表，每個表之間有哪些字段，每個表之間是什么關系4. 構建物理模型：具體的數據庫表格，如果每個字段的類型，哪些是主鍵，外鍵，唯一鍵等等

舉例：設計一個數據庫，記錄學生選課的信息

概念模型

數據庫模型本質就是具有不同屬性實體及其相互關系。對于上述問題，可以分析出：

學生實體：姓名，郵箱，注冊日

期課程實體：標題，價格，教師，標簽

學生實體和課程實體之間關系：多對多。因為一個學生可以選多門課，一門課會包含多個學生。

圖中二者之間的連接線端點形狀代表不同的關系類型。實體之間的關系類型：三種

邏輯模型

假設現在要記錄某個學生參加某門課程的日期。這個時間如果放在student表，由于每個學生可能選擇多門課，即有多個時間，僅根據學生信息無法確定具體對應哪個時間(student表中不記錄課程信息)。若將該時間字段放在course表，也會面臨同樣的問題。問題的本質是，某個學生選某門課的時間，既不是student實體的屬性，也不是course表的屬性，而是二者關系(即enroll)的屬性。解決方案是，利用第三張表，將多對多的關系，轉換為兩個一對多的關系。不妨建一個enrollment表，記錄各個學生，各門課的選擇信息。同時，每張表中補充了具體字段的類型和名稱細分。有了邏輯模型，便可以明確總共有三張表，每張表有哪些字段，以及各個字段的類型。同時各個表的關系也得到體現。

物理模型：

即邏輯模型在MySQL的具體實現。對于不同的SQL軟件，其邏輯模型相同，物理模型有差異。

在創建一張表時，我們依次指定各個字段名，字段類型(varchar，datetime等)，能否為空，默認值等。在完成各個表的構建后，我們接著實現對各個表之間關系的指定。

原則：一張表只描述一個實體，該表中的所有字段，都只描述該實體。當涉及其他實體時，需要用外鍵進行連接。這樣做使得各個表的邊界清晰，當某個屬性發生修改時，不用修改多個表。本質是盡量降低數據的重復率

主鍵：每行記錄在表中的唯一標識

• 一個或多個屬性的組合，一張表只有一個主鍵，其值不可為空

外鍵：建立表的父子關系

如students表、courses表可認為由enrollment表派生而來。前者為子表，后者為其父表

• 外鍵約束：當外鍵所依賴的父表主鍵對應的值發生變化時，子表是否自動同步變化。例如student表中新加入一個學生，若設置外鍵為casecade，則erollment表會同步加入該學生信息。同理，當刪除某個學生時，erollment表也會同步刪除相應學生信息

唯一鍵：該屬性的值不重復

有時候，我們希望某個屬性的值各不相同，如訂單號，可以設置為唯一鍵

• 一個或多個屬性的組合，一張表中可以有多個唯一鍵，其值允許為空

• 主鍵一定是唯一鍵，唯一鍵并不一定是主鍵

2. 范式

第一范式：屬性的原子性

屬性具有原子性，不可再分解。如：

表：字段1、 字段2(字段2.1、字段2.2)、字段3 ......

如學生(學號，姓名，性別，出生年月日)，如果認為最后一列還可以再分成(出生年，出生月，出生日)，它就不滿足第一范式

例如：原本course表中的標簽(tags)字段，每門課可能有多個tag(tag1，tag2，...)，因此在該表中，tags 不能只有一列(否則可能出現A課程在tags字段下，同時有多個值)。因此，就有tag1，tag2等一系列的tags值的列，這顯然不合理，因為我們可能不知道總共有幾個tag，同時tags的新增和刪除也會涉及全表掃描。

稍微思考可以發現，course與tag是多對多的關系，每門課有多個tags，每個tags對應多門課。因此，可以將tags從courses表中分離出來，作為一個單獨的只與tag有關的表。而courses表與tags表則通過鏈接表course_tags表連接。如下圖所示：

第二范式：記錄的唯一性

表中的每行由主鍵唯一區分，非主屬性完全依賴主鍵，不存在部分依賴

表：學號、課程號、姓名、學分

這個表明顯說明了兩個事務:學生信息, 課程信息。由于非主鍵字段必須依賴主鍵，這里學分依賴課程號，姓名依賴與學號，所以不符合二范式

可能會存在問題：

• 數據冗余: ? 每條記錄都含有相同信息；

• 刪除異常：刪除所有學生成績，就把課程信息全刪除了；

• 插入異常：學生未選課，無法記錄進數據庫；

• 更新異常：調整課程學分，所有行都調整。

正確做法:

學生表：學號, 姓名課程表：課程號, 學分選課關系表：學號, 課程號, 成績

第三范式：字段的冗余性

任何字段不能由其他字段派生出來，它要求字段沒有冗余，即不存在傳遞依賴

表: 學號, 姓名, 年齡, 學院名稱, 學院電話

上表存在依賴傳遞: (學號) → (學生)→(所在學院) → (學院電話)?

可能會存在問題：

• 數據冗余: 有重復值，如某學院電話有多個，則多行記錄前三個屬性值都相同，只有學院電話不同；

• 更新異常: 有重復的冗余信息，修改時需要同時修改多條記錄，否則會出現數據不一致的情況 。

正確做法：

學生表：學號, 姓名, 年齡, 所在學院

學院表：學院, 電話

反范式化

沒有冗余的數據庫設計可以做到。但是，沒有冗余的數據庫未必是最好的數據庫，有時為了提高運行效率，就必須降低范式標準，適當保留冗余數據。具體做法是：在概念數據模型設計時遵守第三范式，降低范式標準的工作放到物理數據模型設計時考慮。降低范式就是增加字段，允許冗余，達到以空間換時間的目的。

例如：有一張存放商品的基本表，“金額”這個字段的存在，表明該表的設計不滿足第三范式，因為“金額”可以由“單價”乘以“數量”得到，說明“金額”是冗余字段。但是，增加“金額”這個冗余字段，可以提高查詢統計的速度，這就是以空間換時間的作法。

范式與反范式對比

范式化：適合寫

優點：降低數據冗余，數據表體積小，更新快

缺點：查詢需要將多個表進行連接，更難進行索引優化

反范式化：適合讀

優點：減少表關聯，更易索引優化

缺點：存在冗余數據和數據維護異常(數據不一致)，修改成本高

3. 基本操作

1. 數據庫的創建與刪除

create?database?if?not?exists?sql_store?--創建一個名為sql_store的數據庫drop database if exists sql_store --刪除數據庫sql_store

2. 表的創建刪除與修改

聲明方式與數據庫的創建和刪除類似，但表需要指定其中的字段。指定方式為：名稱+類型+屬性：

類型：如int，varchar等，varchar可在括號中分配指定容量屬性：包括主鍵、外鍵、唯一鍵、非空、自增、默認值等等

use sql_store2; -- 建表之前一般都會檢查刪除原來的表drop table if exists customers; create table if not exists customers( customer_id int primary key auto_increment, first_name varchar(50) not null, points int not null default(0), email varchar(255) not null unique);

表的修改：

alter table custormers -- 在first_name后增加一個last_name字段 add last_name varchar(50) not null after firat_name, -- 修改first_name字段的類型和默認值 modify first_name varchar(55) default(''), -- 刪除points字段 drop points;

3. 關系的創建與修改

下面創建一個訂單表：orders。orders表通過外鍵custormer_id與之前創建的custormers表相關聯。該關聯又稱為外鍵約束。

drop table if exists orders;create table if not exists orders( order_id int primary key, custormer_id int not null, foreign key fk_orders_custormers (custormer_id) references customers (custormer_id) on update cascade on delete no action);

(1)外鍵的命名中，首先是子表名，然后是父表名。orders表通過custormer_id依賴父表custormers，因此命名為fk_orders_custormers。

(2)括號中聲明表中哪個字段為外鍵

(3)references聲明依賴的哪張表的哪個字段(主鍵)

(4)on update和on delete用來聲明，父表的對應字段變化時，子表是否要同步變化

update和delete分別指代父表的更新和刪除的變化。分析可知，顧客id變化時，訂單表中的id也應該同步，從而維持一致性，因此采用cascase模型；而當顧客id意外刪除時，訂單表應保持原來的訂單信息，不能同步刪除，因此采用no action模式，即什么也不做

(5)刪除表時需要按照先刪除子表，再刪除父表的順序。因此需要將刪除orders表的語句，放在刪除custormers表之前

修改主鍵或外鍵約束，同樣使用alter關鍵字：

alter table orders add primary key (order_id), drop primary key, add foreign key fk_orders_custormers (customer_id) references customers (customer_id) on update cascade on delete no action, drop foreign key fk_orders_custorms, ;

No.3? ? 索引

---

在查詢數據時，如果時逐行掃描，無疑查詢速度會非常慢。索引的出現，便是為了加速查詢。

舉例：在customers表中查詢state為CA的記錄

可以預先將state的值建立成有序的索引，這樣先通過索引查到相應行，再依次讀取customers表中的相應行即可，從而避免了全表掃描

索引優點：

• 避免全表掃描，提升查詢效率
• 相比放在磁盤的數據庫表，索引比較小，可以放在內存中，提升查詢速度

索引缺點：

• 增加了額外的索引表，數據庫體積變大
• 每次更新數據，都要同步維護索引，降低寫效率

1. 索引的優化原理

查詢問題，就是算法中的查找問題。查找問題最經典的解決方案，是二分查找。索引是一種有序的數據結構，其本質是一棵搜索樹。為了提高平均查詢性能，基本都是平衡搜索樹(balance search tree)。MySQL中采用的數據結構為B樹/B+樹。

舉例：8條數據，編號依次為1，2，...，8，如何組織索引？

數據庫中的記錄在磁盤中按照頁式存儲，由于頁的大小固定(一般為16kB)，因此數據分布在若干頁上，為簡化問題，假設每頁的容量為2。如下圖所示，8條數據兩兩組合構成了4頁，每組之間通過前后指針連接。

下面建立索引。由于頁號有序，我們可以依次記錄每一頁的起始編號，這樣得到了4條索引，分別為1，3，5，7。代表所指向頁中的最小編號。同樣，這4條索引兩兩組合，共占用兩頁。依次類推，可以得到最上層的兩個索引1，6，共占用一頁。索引樹建立完成，可以看到是一棵二叉搜索樹，本質就是一個分級目錄

此時，如查詢4，從樹根開始走過的路徑如下。對1-8中任何一條記錄的查詢，操作次數不會超過三次。由上到下，每下一層，數據范圍減半。這便是最典型的二分法

從上面的描述中，我們發現只有最底層的葉子節點存儲數據，建立在其上的索引并不存儲真實數據。

在實際中，每一頁存儲的數據不止兩個，因此索引的數量也遠遠小于數據的數量。這兩點使得索引需要的存儲體積很小，不用放在硬盤中，而可以直接放在內存中。

上述為最簡情況，可以看到具備以下三個局限：

• 單次查詢的次數，取決于索引樹的樹高。對于二叉樹來說，樹高即為log2(n)，其中n為數據總量。因此，索引樹應該越低越好。如何降低樹高？增加樹的出度即可，如3叉樹，4叉樹等等

• 以上分析是靜態的，實際中數據是動態地插入和刪除，因此搜索樹必須自動平衡，避免退化為鏈表。

• 范圍查詢難以實現，如查詢編號在4到6之間到數據，上述方法只能拆為4，5，6三次查詢

基于以上原因，索引一般采取B樹或B+樹。因為：

• B/B+樹出度大，因此樹高小，具有更少的比較次數

• B/B+樹的節點中可以存儲多個數據，可以充分利用磁盤的預讀特性減少磁盤I/O

• B/B+樹是平衡樹，在插入或刪除時會利用旋轉來使得失衡的樹恢復平衡

• B+樹只需遍歷葉子節點便可遍歷所有數據(如上圖葉子節點之間用指針互相連接)，有利于范圍查詢，這一點B樹則難以做到

例子中的編號有序，當我們指定某個字段作為索引時，MySQL會先將該字段的所有當前值構建一個B+樹，后續數據的插入和刪除，會對索引樹進行同步處理。

2. 索引的使用和分類

在MySQL中創建一個索引：

create index idx_points on customers(points); -- 基于points字段建立表customers表的索引，索引名稱為idx_points查看索引：show indexes in customers; 刪除索引：drop index idx_points on customers;

索引的建立本質上就是一個對原數據進行分段分層的目錄管理問題，根據某個字段建立索引，即將該列的值進行了排序。

1. 聚簇索引：索引和數據存儲在一塊

也叫主鍵索引，根據主鍵創建的索引，自動創建，只有一個

按照主鍵構造一棵B+樹，若無主鍵，采用非空唯一鍵。如果仍沒有，則會隱式采用某個字段。

葉子節點中存放的整張表的行記錄數據。葉子節點稱為數據頁，每個數據頁通過一個雙向鏈表來進行鏈接，而且數據頁按照主鍵的順序進行排列。每個數據頁上存放的是完整的行記錄，而在非數據頁的索引頁中，僅存放鍵值及指向數據頁的頁號。即上面圖例所示

2. 非聚簇索引：索引和數據分離

也叫輔助索引(二級索引)，用戶定義，可以有多個

非聚簇索引構建的B+樹，只記錄主鍵值。在進行查詢時，先利用輔助索引查找到主鍵值，再通過主索引查找到行數據。因此需要兩次索引查找

舉例：學生表：，，，，其中id為主鍵，會自動根據id建立主索引：idx_id。用戶也可以指定，根據city或者score建立輔助索引：idx_city或idx_score

非聚簇索引包含：普通索引，唯一索引，前綴索引等，這些因為只依據一個字段，因此又稱為單列索引。與之相對的，是由多個字段組合構成的索引，稱為組合索引。下面分兩類分別介紹。

2.1 單列索引

普通索引：最基本的索引，沒有任何限制，是我們大多數情況下使用到的索引

唯一索引：與普通索引類似，不同的是唯一索引的列值必須唯一，但允許為空值

全文索引：僅可以適用于MyISAM引擎的數據表；作用于CHAR、VARCHAR、TEXT數據類型的列

前綴索引：對于string類的數據，可將值的前一部分作為索引，如前5個字符。這樣既可以節約空間，又可以提高查詢效率。所取長度需根據具體情況來確定最優值。但無法使用前綴索引做 ORDER BY 和 GROUP BY，也無法使用前綴索引做覆蓋掃描。

舉例：學生表：，，，，其中name有：streadeerff，addedeasa，defwwdserfs三個記錄值。假設直接指定name字段建立輔助索引，那么B+樹中需要存儲streadeerff，addedeasa，stfwwdserfs這三個string。但其實我們根據前三個字符即可區分，指定前綴索引長度為3，則B+樹中記錄的為：str，add，stf

覆蓋索引：索引本身就包含所有需要查詢的字段的值，sql只需要通過索引就可以返回查詢所需要的數據，這樣避免了查到索引后再返回表拿取數據的操作，減少I/O提高效率。

具有以下優點：

• 索引通常遠小于數據行的大小，只讀取索引能大大減少數據訪問量。

• 一些存儲引擎(例如 MyISAM)在內存中只緩存索引，而數據依賴于操作系統來緩存。因此，只訪問索引可以不使用系統調用(通常比較費時)。

• 對于 InnoDB 引擎，若輔助索引能夠覆蓋查詢，則無需訪問主索引。

2.2 組合索引

采用多個字段構成索引

當查詢條件涉及多個字段，而每個字段都有單列索引時，MySQL會根據書寫順序采取第一個字段對應的索引來進行查詢，然后對查詢結果依次掃描，效率較低

如下圖中，查詢涉及state字段和points字段，對應索引為idx_state和idx_points，實際MySQL采用idx_state進行查詢出所有位于CA的記錄，然后遍歷比對其points是否大于1000

創建組合索引：idx_state_points，查詢效率會大大提升

組合索引適用于多條件查詢的情況，同時能縮減輔助索引數量。如上例中，有了idx_state_points，便不再需要idx_state和idx_points，減少了索引開銷

組合索引順序

應讓選擇性最強的索引列放在前面

如性別，只有男、女兩類，那么通過性別來篩選，只能縮減為原來的1/2。而如果根據城市，假設有48個城市，那么通過城市來篩選，便可將數據規模縮減為原來的1/48。顯然后者的篩選效率更高

舉例：查詢居住在CA，名字以A開頭的顧客

組合索引1: inx_lastName_state，先根據last_name排序，再根據state排序，查詢過程如左圖

組合索引1: inx_state_lastName，先根據state，再根據last_name，查詢過程如右圖

索引失效

1. 在進行查詢時，索引列不能是表達式的一部分，也不能是函數的參數，否則無法使用索引。

例如下面的查詢不能使用 ?points 列的索引：

select customer_id FROM customers WHERE points + 1 = 5

2. 組合索引順序與where子句順序應相統一

當創建(a,b,c)組合索引時，相當于創建了(a)單列索引，(a,b)組合索引以及(a,b,c)組合索引

想要索引生效的話,只能使用 a和a,b和a,b,c三種組合。當然，a,c組合也可以，但實際上只用到了a的索引，c并沒有用到！

舉例：復合索引的結構與電話簿類似，人名由姓和名構成，電話簿首先按姓氏對進行排序，然后按名字對有相同姓氏的人進行排序。如果知道姓，電話簿將非常有用；如果知道姓和名，電話簿則更為有用，但如果只知道名不知道姓，電話簿將沒有用處。

所以說創建復合索引時，應該仔細考慮列的順序。對索引中的所有列執行搜索或僅對前幾列執行搜索時，組合索引非常有用；僅對后面的任意列執行搜索時，組合索引則沒有用處。

本質原因：組合索引是按照字段依次排序生成的

3. 索引總結

索引的優點

1. 大大減少了服務器需要掃描的數據行數。

2. 幫助服務器避免進行排序和分組，以及避免創建臨時表(B+Tree 索引是有序的，可以用于 ORDER BY 和 GROUP BY 操作。臨時表主要是在排序和分組過程中創建，不需要排序和分組，也就不需要創建臨時表)

3. 將隨機 I/O 變為順序 I/O(B+Tree 索引是有序的，會將相鄰的數據都存儲在一起)

索引的使用條件

1. 對于非常小的表、大部分情況下簡單的全表掃描比建立索引更高效；

2. 對于中到大型的表，索引就非常有效；

3. 但是對于特大型的表，建立和維護索引的代價將會隨之增長。這種情況下，需要用到一種技術可以直接區分出需要查詢的一組數據，而不是一條記錄一條記錄地匹配，例如可以使用分區技術。

總結

以上是生活随笔為你收集整理的mysql 同一张表 某个字段更新到另一条数据上_面试基础：数据库MySQL基础入门(下)...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。