MySQL 詞彙表

ARCHIVE 表格的中繼資料。與 .ARZ 檔案 對比。具有此副檔名的檔案始終包含在 MySQL Enterprise Backup 產品的 mysqlbackup 命令所產生的備份中。

另請參閱 .ARZ 檔案、MySQL Enterprise Backup、mysqlbackup 命令。

ARCHIVE 表格的資料。與 .ARM 檔案 對比。具有此副檔名的檔案始終包含在 MySQL Enterprise Backup 產品的 mysqlbackup 命令所產生的備份中。

另請參閱 .ARM 檔案、MySQL Enterprise Backup、mysqlbackup 命令。

代表原子性 (atomicity)、一致性 (consistency)、隔離性 (isolation) 和持久性 (durability) 的縮寫。這些屬性在資料庫系統中都是理想的，並且都與 交易 的概念密切相關。InnoDB 的交易功能遵循 ACID 原則。

交易是可以 提交 或 回滾 的 原子 工作單元。當交易對資料庫進行多項變更時，若交易提交，則所有變更都會成功；若交易回滾，則所有變更都會復原。

資料庫在任何時候都保持一致的狀態 — 在每次提交或回滾之後，以及在交易進行中。如果相關資料正在多個表格中更新，則查詢會看到所有舊值或所有新值，而不是舊值和新值的混合。

交易在進行時會受到彼此的保護（隔離）；它們不能相互干擾或看到彼此未提交的資料。這種隔離是透過 鎖定 機制實現的。經驗豐富的使用者可以調整 隔離等級，在他們可以確定交易確實不會相互干擾的情況下，以較少的保護來換取更高的效能和 並行性。

交易的結果是持久的：一旦提交操作成功，該交易進行的變更將免於斷電、系統崩潰、競爭條件或其他許多非資料庫應用程式容易遭受的潛在危險。持久性通常涉及寫入磁碟儲存，並具有一定程度的冗餘，以防止在寫入操作期間發生斷電或軟體崩潰。（在 InnoDB 中，雙寫緩衝區 有助於持久性。）

另請參閱 原子、提交、並行性、雙寫緩衝區、隔離等級、鎖定、回滾、交易。

一種適用於 InnoDB 表格的演算法，可消除 檢查點 引入的 I/O 負擔。MySQL 會定期刷新一小組已修改的頁面，而不是一次性將所有已修改的 頁面 從 緩衝池 刷新 至 資料檔案。自適應刷新演算法透過根據刷新速率和 重做 資訊的產生速度，估算執行這些定期刷新的最佳速率，進一步擴展此過程。

另請參閱 緩衝池、檢查點、資料檔案、刷新、InnoDB、頁面、重做日誌。

InnoDB 表格的一種最佳化，透過在記憶體中建構 雜湊索引，可以加快使用 = 和 IN 運算子的查找速度。MySQL 會監視 InnoDB 表格的索引搜尋，如果查詢可以從雜湊索引中受益，則會自動為經常存取的索引 頁面 建構一個雜湊索引。從某種意義上說，自適應雜湊索引會在執行階段設定 MySQL，以充分利用充足的主記憶體，使其更接近主記憶體資料庫的架構。此功能由 innodb_adaptive_hash_index 設定選項控制。由於此功能對某些工作負載有利，而對其他工作負載則不利，並且雜湊索引使用的記憶體會在 緩衝池 中保留，因此通常應在啟用和停用此功能的情況下進行基準測試。

雜湊索引始終以表格上現有的 B 樹 索引為基礎建構。MySQL 可以根據對索引的搜尋模式，在 B 樹定義的索引鍵的任何長度字首上建構雜湊索引。雜湊索引可以是部分的；不需要在緩衝池中快取整個 B 樹索引。

另請參閱 B 樹、緩衝池、雜湊索引、頁面、次要索引。

用於使用 .NET 技術（例如 ASP.NET）建構的應用程式的物件關聯式對應 (ORM) 架構。此類應用程式可以透過 Connector/NET 元件與 MySQL 連接。

另請參閱 .NET、ASP.net、Connector/NET、Mono、Visual Studio。

非同步 I/O 的縮寫。您可能會在 InnoDB 訊息或關鍵字中看到此縮寫。

另請參閱 非同步 I/O。

在 ODBC 中，支援字元集和其他國際化方面的一種替代方法。與 萬國碼 對比。Connector/ODBC 3.51 是 ANSI 驅動程式，而 Connector/ODBC 5.1 則是萬國碼驅動程式。

另請參閱 Connector/ODBC、ODBC、萬國碼。

API 提供從 用戶端 程式對 MySQL 通訊協定和 MySQL 資源的低階存取。與 連接器 提供的高階存取對比。

另請參閱 C API、用戶端、連接器、原生 C API、Perl API、PHP API、Python API、Ruby API。

一組函式或程序。API 為函式、程序、參數和傳回值提供一組穩定的名稱和類型。

當 MySQL Enterprise Backup 產品產生的備份不包含備份進行期間發生的最新變更時，將備份檔案更新為包含這些變更的過程稱為 套用 步驟。它由 mysqlbackup 命令的 apply-log 選項指定。

在套用變更之前，我們將檔案稱為 原始備份。在套用變更之後，我們將檔案稱為 準備好的備份。變更會記錄在 ibbackup_logfile 檔案中；一旦套用步驟完成，此檔案就不再需要。

另請參閱 熱備份、ibbackup_logfile、MySQL Enterprise Backup、準備好的備份、原始備份。

Kerberos 認證伺服器。AS 也可以指認證伺服器提供的認證服務。

另請參閱 認證伺服器。

一個使用 .NET 技術和語言開發網頁應用程式的框架。此類應用程式可以透過 Connector/NET 元件與 MySQL 進行介接。

另一個使用 MySQL 編寫伺服器端網頁的技術是 PHP。

另請參閱 .NET、ADO.NET、Connector/NET、Mono、PHP、Visual Studio。

.NET 系統中經過編譯的程式碼庫，透過 Connector/NET 存取。儲存在 GAC 中，允許版本控制而不會產生命名衝突。

另請參閱 .NET、GAC。

一種 I/O 操作類型，允許在 I/O 完成之前繼續進行其他處理。也稱為非阻塞 I/O，縮寫為 AIO。InnoDB 對於某些可以平行執行的操作使用這種 I/O 類型，而不會影響資料庫的可靠性，例如將尚未實際請求但可能很快需要的頁面讀取到緩衝池中。

在過去，InnoDB 僅在 Windows 系統上使用非同步 I/O。從 InnoDB Plugin 1.1 和 MySQL 5.5 開始，InnoDB 在 Linux 系統上使用非同步 I/O。此變更引入了對 libaio 的依賴。Linux 系統上的非同步 I/O 使用 innodb_use_native_aio 選項進行設定，預設情況下啟用。在其他類 Unix 系統上，InnoDB 僅使用同步 I/O。

另請參閱 緩衝池、非阻塞 I/O。

在 SQL 環境中，交易是工作單元，它們要么完全成功（當提交時），要么根本沒有效果（當回滾時）。交易的不可分割（"原子"）屬性是縮寫 ACID 中的 “A”。

另請參閱 ACID、提交 (commit)、回滾 (rollback)、交易 (transaction)。

原子DDL 語句是指將與 DDL 操作相關的資料字典更新、儲存引擎操作和二進位日誌寫入合併到單個原子交易中的語句。即使伺服器在操作期間停止，該交易也會完全提交或回滾。MySQL 8.0 中新增了原子 DDL 支援。如需更多資訊，請參閱 第 15.1.1 節，「原子資料定義語句支援」。

另請參閱 二進位日誌、資料字典、DDL、儲存引擎。

CPU 提供的特殊指令，用於確保重要的底層操作不會被中斷。

在 Kerberos 中，一種提供初始票證的服務，該票證用於取得票證授權票證 (TGT)，而票證授權票證 (TGT) 是從票證授權伺服器 (TGS) 取得其他票證所必需的。認證伺服器 (AS) 與 TGS 結合構成金鑰分配中心 (KDC)。

另請參閱 金鑰分配中心 (key distribution center)、票證授權伺服器 (ticket-granting server)。

資料表欄位的一個屬性（由 AUTO_INCREMENT 關鍵字指定），該屬性會自動在欄位中新增一個遞增的數值序列。

它可以為開發人員節省工作量，而無需在插入新列時產生新的唯一值。它為查詢最佳化工具提供了有用的資訊，因為已知該欄位不為 null 且具有唯一值。此類欄位的值可以用作各種環境中的查找鍵，並且由於它們是自動產生的，因此沒有理由更改它們；因此，主鍵欄位通常被指定為自動遞增。

自動遞增欄位在基於語句的複寫中可能會出現問題，因為在複寫上重新執行語句可能不會產生與來源上相同的一組欄位值，這是由於時序問題。當您有一個自動遞增的主鍵時，您只能使用設定 innodb_autoinc_lock_mode=1 來使用基於語句的複寫。如果您有 innodb_autoinc_lock_mode=2，允許更高的插入操作並行性，請使用基於列的複寫而不是基於語句的複寫。除非出於相容性目的，否則不應使用設定 innodb_autoinc_lock_mode=0。

連續鎖定模式 (innodb_autoinc_lock_mode=1) 是 MySQL 8.0.3 之前的預設設定。從 MySQL 8.0.3 開始，交錯鎖定模式 (innodb_autoinc_lock_mode=2) 是預設值，這反映了從基於語句的複寫變更為基於列的複寫作為預設複寫類型。

另請參閱 自動遞增鎖定、innodb_autoinc_lock_mode、主鍵、基於列的複寫、基於語句的複寫。

自動遞增主鍵的便利性涉及與並行性的一些權衡。在最簡單的情況下，如果一個交易正在將值插入到資料表中，則任何其他交易都必須等待才能將它們自己的插入操作插入到該資料表中，以便第一個交易插入的列收到連續的主鍵值。InnoDB 包括最佳化和 innodb_autoinc_lock_mode 選項，以便您可以配置自動遞增值的可預測順序與插入操作的最大並行性之間的最佳平衡。

另請參閱 自動遞增、並行性 (concurrency)、innodb_autoinc_lock_mode。

一個設定，會導致在每個 SQL 語句之後執行 提交 操作。不建議在處理跨越多個語句的 交易 時，使用此模式處理 InnoDB 資料表。它可以幫助提高 InnoDB 資料表上唯讀交易的效能，它可以最大限度地減少 鎖定 和產生復原資料的額外負荷，尤其是在 MySQL 5.6.4 及更高版本中。它也適用於處理 MyISAM 資料表，其中交易不適用。

另請參閱 提交 (commit)、鎖定 (locking)、唯讀交易 (read-only transaction)、SQL、交易 (transaction)、復原 (undo)。

應對主機上的故障（包括 MySQL、作業系統或硬體的故障）並在必要時從故障中復原的能力，以及可能導致停機的維護活動。通常與可擴展性配對，作為大規模部署的關鍵方面。

另請參閱 可擴展性 (scalability)。

一種樹狀資料結構，廣泛用於資料庫索引中。該結構始終保持排序，可快速查找完全匹配項（等於運算符）和範圍（例如，大於、小於和 BETWEEN 運算符）。此類索引適用於大多數儲存引擎，例如 InnoDB 和 MyISAM。

由於 B 樹節點可以有很多子節點，因此 B 樹與每個節點僅限於 2 個子節點的二元樹不同。

與雜湊索引形成對比，雜湊索引僅在 MEMORY 儲存引擎中可用。MEMORY 儲存引擎也可以使用 B 樹索引，如果某些查詢使用範圍運算符，則應為 MEMORY 資料表選擇 B 樹索引。

這裡使用 B 樹（B-tree）一詞，意在指稱索引設計的一般類別。MySQL 儲存引擎使用的 B 樹結構可以視為變體，因為它們具有經典 B 樹設計中沒有的複雜功能。有關相關資訊，請參閱InnoDB 頁面結構的MySQL 內部手冊中的「檔案標頭」章節。

另請參閱雜湊索引（hash index）。

如果 MySQL SQL 陳述式中的識別符號包含特殊字元或保留字，則必須使用反引號字元 (`) 將其引起來。例如，若要參照名為 FOO#BAR 的資料表或名為 SELECT 的欄位，則應將識別符號指定為 `FOO#BAR` 和 `SELECT`。由於反引號提供額外的安全層級，因此它們廣泛用於程式產生的 SQL 陳述式中，因為識別符號名稱可能無法事先得知。

許多其他資料庫系統在這些特殊名稱周圍使用雙引號 (")。為了可攜性，您可以在 MySQL 中啟用 ANSI_QUOTES 模式，並使用雙引號而不是反引號來限定識別符號名稱。

另請參閱SQL。

從 MySQL 執行個體複製部分或全部資料表資料和中繼資料，以作安全保存的過程。也可以指複製的檔案集。這是 DBA 的一項關鍵任務。此過程的反向操作是還原（restore）操作。

在 MySQL 中，實體備份（physical backups）由 MySQL Enterprise Backup 產品執行，而邏輯備份（logical backups）由 mysqldump 命令執行。這些技術在備份資料的大小和表示形式以及速度（尤其是還原操作的速度）方面具有不同的特性。

根據備份對正常資料庫操作的干擾程度，備份進一步分為熱（hot）備份、溫（warm）備份或冷（cold）備份。（熱備份的干擾最少，冷備份的干擾最多。）

另請參閱冷備份（cold backup）、熱備份（hot backup）、邏輯備份（logical backup）、MySQL Enterprise Backup、mysqldump、實體備份（physical backup）、溫備份（warm backup）。

儲存產生的欄位或虛擬產生的欄位所依據的非產生資料表欄位。換句話說，基底欄位是產生的欄位定義中一部分的非產生資料表欄位。

另請參閱產生欄位（generated column）、儲存產生的欄位（stored generated column）、虛擬產生的欄位（virtual generated column）。

軟體產品生命週期中的早期階段，此時產品僅供評估，通常沒有明確的版本號碼或版本號碼小於 1。InnoDB 不使用 beta 指定，而是偏好早期採用者（early adopter）階段，該階段可以延伸到數個點版本，最終產生GA版本。

另請參閱早期採用者（early adopter）、GA。

包含所有嘗試變更資料表資料的陳述式或列變更記錄的檔案。可以重新播放二進位記錄檔的內容，以在複製（replication）案例中將複本更新，或在從備份還原資料表資料後將資料庫更新。可以開啟和關閉二進位記錄功能，但如果您使用複製或執行備份，Oracle 建議始終啟用此功能。

您可以使用mysqlbinlog 命令檢查二進位記錄檔的內容，或在複製或還原期間重新播放。有關二進位記錄檔的完整資訊，請參閱第 7.4.4 節「二進位記錄檔」。有關與二進位記錄檔相關的 MySQL 組態選項，請參閱第 19.1.6.4 節「二進位記錄選項和變數」。

對於 MySQL Enterprise Backup 產品，二進位記錄檔的檔名和檔案內的目前位置是很重要的詳細資料。若要在複製內容中進行備份時記錄來源的此資訊，您可以指定 --slave-info 選項。

在 MySQL 5.0 之前，提供類似的功能，稱為更新記錄檔。在 MySQL 5.0 和更高版本中，二進位記錄檔會取代更新記錄檔。

另請參閱binlog、MySQL Enterprise Backup、複製（replication）。

二進位記錄檔（binary log）的非正式名稱。例如，您可能會在電子郵件訊息或論壇討論中看到此縮寫。

另請參閱二進位記錄檔（binary log）。

由 WITH QUERY EXPANSION 子句啟用的全文搜尋（full-text search）的特殊模式。它會執行兩次搜尋，其中第二次搜尋的搜尋詞組是原始搜尋詞組，並與第一次搜尋中幾個最相關的文件串連。此技術主要適用於簡短的搜尋詞組，可能只有單個字。它可以發現精確搜尋詞彙未出現在文件中的相關相符項。

另請參閱全文搜尋（full-text search）。

用於包含任何種類的任意大小二進位資料的 SQL 資料類型（TINYBLOB、BLOB、MEDIUMBLOB 和 LONGBLOB）。用於儲存文件、影像、聲音檔案，以及其他無法輕易分解為 MySQL 資料表內列和欄的資訊。在 MySQL 應用程式中處理 BLOB 的技術會隨著每個連接器（Connector）和API 而有所不同。MySQL Connector/ODBC 將 BLOB 值定義為 LONGVARBINARY。對於大型、自由形式的字元資料集合，業界術語是 CLOB，由 MySQL TEXT 資料類型表示。

另請參閱API、CLOB、連接器（connector）、Connector/ODBC。

系統中大小或容量受限的部分，會限制整體輸送量。例如，記憶體區域可能比必要的小；存取單個所需資源可能會阻止多個 CPU 核心同時執行；或者等待磁碟 I/O 完成可能會阻止 CPU 以全速執行。移除瓶頸往往可以改善並行性（concurrency）。例如，當多個工作階段同時從緩衝集區讀取和寫入時，擁有多個 InnoDB 緩衝集區（buffer pool）執行個體的能力可以減少競爭。

另請參閱緩衝集區（buffer pool）、並行性（concurrency）。

關閉（shutdown）操作後立即重新啟動。理想情況下，應該有相對較短的暖機（warmup）期間，以便效能和輸送量能夠快速恢復到較高的水準。

另請參閱關閉（shutdown）。

用於管理 InnoDB 緩衝集區（buffer pool）中不同大小頁面（pages）的機制。

另請參閱緩衝集區（buffer pool）、頁面（page）、頁面大小（page size）。

用於暫時儲存的記憶體或磁碟區域。資料緩衝在記憶體中，以便可以有效地寫入磁碟，進行幾次大型 I/O 操作，而不是許多小型 I/O 操作。資料緩衝在磁碟上以提高可靠性，以便即使在最糟糕的時間發生損毀（crash）或其他失敗時也可以恢復。InnoDB 使用的主要緩衝區類型是緩衝集區（buffer pool）、雙寫入緩衝區（doublewrite buffer）和變更緩衝區（change buffer）。

另請參閱緩衝集區（buffer pool）、變更緩衝區（change buffer）、損毀（crash）、雙寫入緩衝區（doublewrite buffer）。

存放快取 InnoDB 資料（包括表格與索引）的記憶體區域。為了提高大量讀取操作的效率，緩衝池被劃分為可以容納多個資料列的頁面 (page)。為了提高快取管理效率，緩衝池以頁面的連結串列形式實現；不常使用的資料會使用LRU演算法的變體從快取中移出。在具有大型記憶體的系統上，您可以將緩衝池劃分為多個緩衝池實例 (buffer pool instance)來提高並行性。

多個 InnoDB 狀態變數、INFORMATION_SCHEMA 表格和 performance_schema 表格有助於監控緩衝池的內部運作。從 MySQL 5.6 開始，您可以透過在伺服器關閉時儲存緩衝池狀態，並在伺服器啟動時將緩衝池還原到相同狀態，來避免重新啟動伺服器後漫長的預熱期，尤其對於具有大型緩衝池的實例。請參閱第 17.8.3.6 節，「儲存和還原緩衝池狀態」。

另請參閱 緩衝池實例 (buffer pool instance)、LRU、頁面 (page)、預熱 (warm up)。

緩衝池 (buffer pool)可以劃分成的多個區域中的任何一個，由 innodb_buffer_pool_instances 組態選項控制。innodb_buffer_pool_size 指定的總記憶體大小將分配給所有緩衝池實例。通常，對於分配給 InnoDB 緩衝池數 GB 記憶體的系統，且每個實例為 1GB 或更大時，使用多個緩衝池實例是適當的。在許多並行連線從緩衝池載入或尋找大量資料的系統上，使用多個緩衝池實例可以減少對管理緩衝池的資料結構進行獨佔存取的爭用。

另請參閱 緩衝池 (buffer pool)。

MySQL 內建的 InnoDB 儲存引擎是該儲存引擎的原始發行形式。與InnoDB 外掛程式 (InnoDB Plugin)形成對比。從 MySQL 5.5 開始，InnoDB 外掛程式已合併回 MySQL 程式碼庫，成為內建的 InnoDB 儲存引擎（稱為 InnoDB 1.1）。

這個區別在 MySQL 5.1 中尤其重要，因為某個功能或錯誤修正可能適用於 InnoDB 外掛程式，但不適用於內建的 InnoDB，反之亦然。

另請參閱 InnoDB。

構成商業軟體基礎的關係和動作順序，用於營運商業公司。有時這些規則由法律規定，有時由公司政策規定。仔細規劃可確保資料庫編碼和強制執行的關係，以及透過應用程式邏輯執行的動作，準確反映公司的實際政策並能處理現實生活中的情況。

例如，員工離職可能會觸發人力資源部門的一系列動作。人力資源資料庫可能也需要具有彈性，能夠表示有關已受僱但尚未開始工作的人員的資料。關閉線上服務的帳戶可能會導致資料從資料庫中移除，或者資料可能會被移動或標記，以便在重新開啟帳戶時可以復原。一家公司可能會建立關於薪資上限、下限和調整的政策，此外還會建立基本的健全性檢查，例如薪資不得為負數。零售資料庫可能不允許具有相同序號的購買項目退貨多次，或者不允許超過特定價值的信用卡購買，而用於偵測詐欺的資料庫可能會允許這些情況。

另請參閱 關聯式 (relational)。

與 InnoDB 可傳輸表空間 (transportable tablespace) 功能搭配使用的中繼資料檔案。它是由命令 FLUSH TABLES ... FOR EXPORT 產生，將一個或多個表格置於一致的狀態，可以複製到另一個伺服器。.cfg 檔案會與對應的 .ibd 檔案一起複製，並用於在 ALTER TABLE ... IMPORT TABLESPACE 步驟期間，調整 .ibd 檔案的內部值，例如空間 ID (space ID)。

另請參閱 .ibd 檔案、空間 ID (space ID)、可傳輸表空間 (transportable tablespace)。

一種兼具可攜性、效能以及存取低階硬體功能的程式語言，使其成為撰寫作業系統、驅動程式和其他種類的系統軟體的熱門選擇。許多複雜的應用程式、語言和可重複使用的模組都具有以 C 撰寫的部分，並與以其他語言撰寫的高階元件連結在一起。其核心語法對 C++、Java 和 C# 開發人員來說很熟悉。

另請參閱 C API、C++、C#、Java。

C API 程式碼與 MySQL 一起發佈。它包含在 libmysqlclient 程式庫中，並允許 C 程式存取資料庫。

另請參閱 API、C、libmysqlclient。

一種結合強型別和物件導向功能的程式語言，在 Microsoft .NET 框架或其開放原始碼對應項目 Mono 中執行。通常用於使用 ASP.net 框架建立應用程式。其語法對 C、C++ 和 Java 開發人員來說很熟悉。

另請參閱 .NET、ASP.net、C、Connector/NET、C++、Java、Mono。

一種程式語言，其核心語法對 C 開發人員來說很熟悉。提供對低階操作的存取以獲得效能，並結合更高階的資料類型、物件導向功能和垃圾回收。若要為 MySQL 撰寫 C++ 應用程式，您可以使用 Connector/C++ 元件。

另請參閱 C、Connector/C++。

用於儲存資料副本以便頻繁或高速檢索的任何記憶體區域的通用術語。在 InnoDB 中，主要類型的快取結構是緩衝池 (buffer pool)。

另請參閱 緩衝區 (buffer)、緩衝池 (buffer pool)。

表格資料行 (column)中不同值的數量。當查詢參考具有關聯索引 (index)的資料行時，每個資料行的基數會影響哪種存取方法最有效率。例如，對於具有唯一約束 (unique constraint)的資料行，不同值的數量等於表格中的資料列數。如果表格有一百萬個資料列，但特定資料行只有 10 個不同的值，則每個值（平均）會出現 100,000 次。因此，諸如 SELECT c1 FROM t1 WHERE c1 = 50; 的查詢可能會傳回 1 個資料列或大量的資料列，而資料庫伺服器可能會根據 c1 的基數以不同的方式處理查詢。

如果資料行中的值分佈非常不均勻，則基數可能不是判斷最佳查詢計畫的好方法。例如，當 x=50 時，SELECT c1 FROM t1 WHERE c1 = x; 可能會傳回 1 個資料列，而當 x=30 時，可能會傳回一百萬個資料列。在這種情況下，您可能需要使用索引提示 (index hint)來傳遞有關哪種查詢方法對於特定查詢更有效率的建議。

基數也適用於多個資料行中存在的不同值數量，如在複合索引 (composite index)中所示。

另請參閱 資料行 (column)、複合索引 (composite index)、索引 (index)、索引提示 (index hint)、持續性統計資料 (persistent statistics)、隨機跳躍 (random dive)、選擇性 (selectivity)、唯一約束 (unique constraint)。

一種特殊的資料結構，用於記錄對次級索引中頁面的變更。這些值可能來自 SQL 的 INSERT、UPDATE 或 DELETE 語句 (DML)。涉及變更緩衝區的功能統稱為變更緩衝 (change buffering)，其中包含插入緩衝 (insert buffering)、刪除緩衝 (delete buffering) 和 清除緩衝 (purge buffering)。

只有當次級索引的相關頁面不在緩衝池中時，變更才會記錄在變更緩衝區中。當相關索引頁面被帶入緩衝池，而相關變更仍在變更緩衝區中時，該頁面的變更會使用變更緩衝區中的資料在緩衝池中進行套用 (合併 (merged))。系統在閒置時或在緩慢關閉期間，會定期執行清除 (purge)操作，將新的索引頁面寫入磁碟。與立即將每個值寫入磁碟相比，清除操作可以更有效率地寫入一系列索引值的磁碟區塊。

實際上，變更緩衝區是系統表空間的一部分，因此索引變更會在資料庫重新啟動時保持緩衝。只有當頁面因為其他讀取操作而被帶入緩衝池時，變更才會被套用 (合併)。

變更緩衝區中儲存的資料種類和數量受 innodb_change_buffering 和 innodb_change_buffer_max_size 設定選項的控制。若要查看變更緩衝區中目前的資料資訊，請執行 SHOW ENGINE INNODB STATUS 命令。

以前稱為插入緩衝區 (insert buffer)。

另請參閱 緩衝池 (buffer pool)、變更緩衝 (change buffering)、刪除緩衝 (delete buffering)、DML、插入緩衝區 (insert buffer)、插入緩衝 (insert buffering)、合併 (merge)、頁面 (page)、清除 (purge)、清除緩衝 (purge buffering)、次級索引 (secondary index)、系統表空間 (system tablespace)。

涉及變更緩衝區的功能的通用術語，包含插入緩衝、刪除緩衝和清除緩衝。SQL 語句產生的索引變更通常會涉及隨機 I/O 操作，這些變更會被延後，並由背景執行緒定期執行。與立即將每個值寫入磁碟相比，此操作順序可以更有效率地寫入一系列索引值的磁碟區塊。由 innodb_change_buffering 和 innodb_change_buffer_max_size 設定選項控制。

另請參閱 變更緩衝區 (change buffer)、刪除緩衝 (delete buffering)、插入緩衝 (insert buffering)、清除緩衝 (purge buffering)。

當對快取在緩衝池中的資料頁面進行變更時，這些變更會在稍後寫入資料檔案，這個過程稱為刷新 (flushing)。檢查點是成功寫入資料檔案的最新變更記錄（由LSN值表示）。

另請參閱 緩衝池 (buffer pool)、資料檔案 (data files)、刷新 (flush)、模糊檢查點 (fuzzy checkpointing)、LSN。

在 InnoDB 中，一種驗證機制，用於檢測將表空間中的頁面從磁碟讀取到 InnoDB 緩衝池時是否發生損壞。此功能由 MySQL 5.5 中的 innodb_checksums 設定選項控制。innodb_checksums 在 MySQL 5.6.3 中已被棄用，並由 innodb_checksum_algorithm 取代。

innochecksum 命令藉由在 MySQL 伺服器關閉時測試指定表空間檔案的校驗和值，來協助診斷損壞問題。

MySQL 也使用校驗和進行複製。如需詳細資訊，請參閱設定選項 binlog_checksum、source_verify_checksum 或 master_verify_checksum，以及 replica_sql_verify_checksum 或 slave_sql_verify_checksum。

另請參閱 緩衝池 (buffer pool)、頁面 (page)、表空間 (tablespace)。

在外部索引鍵關係中，子資料表是指其資料列參照（或指向）另一個資料表中具有特定欄位相同值的資料列。這是包含 FOREIGN KEY ... REFERENCES 子句以及可選的 ON UPDATE 和 ON DELETE 子句的資料表。必須先存在父資料表中的對應資料列，才能在子資料表中建立資料列。子資料表中的值可以防止對父資料表執行刪除或更新操作，或者根據建立外部索引鍵時使用的 ON CASCADE 選項，導致子資料表中自動刪除或更新。

另請參閱 外部索引鍵 (foreign key)、父資料表 (parent table)。

InnoDB 緩衝池中的頁面，其中記憶體中進行的所有變更也已寫入 (刷新) 到 資料檔案。與髒頁面 (dirty page)相反。

另請參閱 緩衝池 (buffer pool)、資料檔案 (data files)、髒頁面 (dirty page)、刷新 (flush)、頁面 (page)。

一種關機方式，可以在沒有錯誤的情況下完成，並在完成之前將所有變更套用至 InnoDB 資料表，與崩潰 (crash)或快速關機 (fast shutdown)相反。與慢速關機 (slow shutdown)同義。

另請參閱 崩潰 (crash)、快速關機 (fast shutdown)、關機 (shutdown)、慢速關機 (slow shutdown)。

在資料庫伺服器外部執行的程式，透過連接器 (Connector)或透過用戶端程式庫 (client libraries)提供的API傳送請求，與資料庫進行通訊。它可以與資料庫伺服器在同一部實體機器上執行，也可以在透過網路連線的遠端機器上執行。它可以是專用的資料庫應用程式，也可以是像 mysql 命令列處理器之類的通用程式。

另請參閱 API、用戶端程式庫 (client libraries)、連接器 (connector)、mysql、伺服器 (server)。

包含用於處理資料庫的函式集合的檔案。透過使用這些程式庫編譯程式，或將它們安裝在應用程式所在的同一系統上，您可以在未安裝 MySQL 伺服器的機器上執行資料庫應用程式（稱為用戶端）；應用程式透過網路存取資料庫。使用 MySQL 時，您可以使用 MySQL 伺服器本身的libmysqlclient 程式庫。

另請參閱 用戶端 (client)、libmysqlclient。

一種預處理語句類型，其中快取和重複使用在本地進行管理，模擬伺服器端預處理語句 (server-side prepared statements)的功能。在過去，一些Connector/J、Connector/ODBC 和 Connector/PHP 開發人員使用此方法來解決伺服器端預存程序的問題。對於現代 MySQL 伺服器版本，建議使用伺服器端預處理語句以獲得效能、可擴展性和記憶體效率。

另請參閱 Connector/J、Connector/ODBC、Connector/PHP、預處理語句 (prepared statement)。

一種 SQL 資料類型 ( TINYTEXT、 TEXT、 MEDIUMTEXT 或 LONGTEXT )，用於儲存任何種類、任意大小的字元資料。用於儲存基於文字的文件，並帶有相關的字元集和定序順序。在 MySQL 應用程式中處理 CLOB 的技術因各個連接器 (Connector)和 API 而異。MySQL Connector/ODBC 將 TEXT 值定義為 LONGVARCHAR。對於儲存二進位資料，等效的類型是 BLOB 類型。

另請參閱 API、 BLOB、 連接器 (connector)、 Connector/ODBC。

InnoDB 中主鍵 (primary key)索引的術語。InnoDB 表格儲存基於主鍵欄位的值來組織，以加速涉及主鍵欄位的查詢和排序。為了獲得最佳效能，請根據效能最關鍵的查詢仔細選擇主鍵欄位。由於修改叢集索引的欄位是一項昂貴的操作，因此請選擇很少或從不更新的主鍵欄位。

在 Oracle Database 產品中，這種類型的表格稱為索引組織表格 (index-organized table)。

另請參閱 索引 (index)、 主鍵 (primary key)、 次要索引 (secondary index)。

在資料庫關閉時進行的備份 (backup)。對於繁忙的應用程式和網站，這可能不太實用，您可能更喜歡暖備份 (warm backup) 或 熱備份 (hot backup)。

另請參閱 備份 (backup)、 熱備份 (hot backup)、 暖備份 (warm backup)。

列 (row)中的一個資料項目，其儲存和語意由資料類型定義。每個 表格 (table) 和索引 (index)主要由其包含的欄位集定義。

每個欄位都有一個基數 (cardinality)值。欄位可以是其表格的主鍵 (primary key)，或是主鍵的一部分。欄位可能會受到唯一約束 (unique constraint)、NOT NULL 約束或兩者約束。不同欄位中的值，即使跨越不同表格，也可以通過外鍵 (foreign key)關係連結。

在討論 MySQL 內部操作時，有時會使用欄位 (field)作為同義詞。

另請參閱 基數 (cardinality)、 外鍵 (foreign key)、 索引 (index)、 NOT NULL 約束、 主鍵 (primary key)、 列 (row)、 表格 (table)、 唯一約束 (unique constraint)。

單一欄位的索引 (index)。

另請參閱 複合索引 (composite index)、 索引 (index)。

當使用長度規範建立索引 (index)時，例如 CREATE INDEX idx ON t1 (c1(N))，只有欄位值的前 N 個字元會儲存在索引中。保持索引前綴小巧可以使索引緊湊，並且節省記憶體和磁碟 I/O 有助於效能。(雖然使索引前綴太小可能會妨礙查詢最佳化，因為這樣會使具有不同值的列對查詢最佳化工具顯示為重複的列。)

對於包含二進位值或長文字字串的欄位，其中排序不是主要考量，並且將整個值儲存在索引中會浪費空間，索引會自動使用值的前 N 個 (通常為 768 個) 字元來進行查找和排序。

另請參閱 索引 (index)。

陳述式攔截器 (statement interceptor)的同義詞。攔截器 (interceptor)設計模式的一個方面，適用於 Connector/NET 和 Connector/J。Connector/NET 稱之為命令 (command)，而 Connector/J 稱之為陳述式 (statement)。與例外狀況攔截器 (exception interceptor)進行比較。

另請參閱 Connector/J、 Connector/NET、 例外狀況攔截器 (exception interceptor)、 攔截器 (interceptor)、 陳述式攔截器 (statement interceptor)。

一個 SQL 陳述式，結束一個交易 (transaction)，使交易做出的任何變更成為永久性。它是回滾 (rollback)的反義詞，回滾會撤銷在交易中所做的任何變更。

InnoDB 使用一種樂觀 (optimistic)的提交機制，以便可以在實際提交發生之前將變更寫入資料檔案。這種技術使提交本身更快，代價是在回滾的情況下需要做更多的工作。

預設情況下，MySQL 使用自動提交 (autocommit)設定，該設定會在每個 SQL 陳述式之後自動發出提交。

另請參閱 自動提交 (autocommit)、 樂觀 (optimistic)、 回滾 (rollback)、 SQL、 交易 (transaction)。

InnoDB 表格的列格式 (row format)。它是從 MySQL 5.0.3 到 MySQL 5.7.8 的預設列格式。在 MySQL 8.0 中，預設的列格式由 innodb_default_row_format 組態選項定義，該選項的預設設定為 DYNAMIC。COMPACT 列格式為 null 值和可變長度欄位提供了比 REDUNDANT 列格式更緊湊的表示形式。

有關 InnoDB COMPACT 列格式的更多資訊，請參閱 第 17.10 節 「InnoDB 列格式」。

另請參閱 動態列格式 (dynamic row format)、 檔案格式 (file format)、 冗餘列格式 (redundant row format)、 列格式 (row format)。

包含多個欄位的索引 (index)。

另請參閱 索引 (index)。

MySQL Enterprise Backup 產品的壓縮功能會建立每個表格空間的壓縮副本，並將副檔名從 .ibd 變更為 .ibz。壓縮備份資料可讓您保留更多備份，並縮短將備份傳輸到不同伺服器的時間。資料會在還原操作期間解壓縮。當壓縮備份操作處理已壓縮的表格時，它會跳過該表格的壓縮步驟，因為再次壓縮將幾乎無法節省空間。

由 MySQL Enterprise Backup 產品產生的一組檔案，其中每個表格空間 (tablespace)都會壓縮。壓縮檔案會以 .ibz 檔案副檔名重新命名。

在備份過程開始時應用壓縮 (compression)有助於避免在壓縮過程中的儲存開銷，並避免在將備份檔案傳輸到另一部伺服器時產生網路開銷。套用 (apply)二進位日誌 (binary log)的過程需要更長的時間，並且需要解壓縮備份檔案。

另請參閱 套用 (apply)、 二進位日誌 (binary log)、 壓縮 (compression)、 熱備份 (hot backup)、 MySQL Enterprise Backup、 表格空間 (tablespace)。

一種列格式 (row format)，可為 InnoDB 表格啟用資料和索引壓縮 (compression)。大型欄位會存儲在遠離保存其餘列資料的頁面，就像在動態列格式 (dynamic row format)中一樣。索引頁面和大型欄位都會被壓縮，從而節省記憶體和磁碟空間。根據資料的結構，記憶體和磁碟使用量的減少可能或者可能不超過解壓縮使用資料時的效能開銷。有關使用詳細資訊，請參閱 第 17.9 節 「InnoDB 表格和頁面壓縮」。

關於 InnoDB COMPRESSED 列格式的額外資訊，請參閱DYNAMIC 列格式。

另請參閱 壓縮 (compression)、動態列格式 (dynamic row format)、列格式 (row format)。

一種資料以壓縮形式儲存的資料表。對於 InnoDB 而言，它是以 ROW_FORMAT=COMPRESSED 建立的資料表。如需更多資訊，請參閱第 17.9 節，「InnoDB 資料表與頁面壓縮」。

另請參閱 壓縮列格式 (compressed row format)、壓縮 (compression)。

一項具有廣泛優點的功能，包括使用較少的磁碟空間、執行較少的 I/O，以及使用較少的記憶體進行快取。

InnoDB 支援資料表層級和頁面層級的壓縮。InnoDB 頁面壓縮也稱為透明頁面壓縮 (transparent page compression)。如需有關 InnoDB 壓縮的更多資訊，請參閱第 17.9 節，「InnoDB 資料表與頁面壓縮」。

另一種壓縮類型是 MySQL Enterprise Backup 產品的壓縮備份 (compressed backup) 功能。

另請參閱 緩衝池 (buffer pool)、壓縮備份 (compressed backup)、壓縮列格式 (compressed row format)、DML、透明頁面壓縮 (transparent page compression)。

實際上並非錯誤，而是將壓縮 (compression) 與 DML 作業結合使用時可能發生的昂貴操作。當以下情況發生時會發生這種情況：對壓縮頁面 (page) 的更新溢出了頁面上保留用於記錄修改的區域；頁面再次壓縮，所有變更都應用於資料表資料；重新壓縮的資料不符合原始頁面，需要 MySQL 將資料分割成兩個新頁面並分別壓縮每個頁面。若要檢查此情況的頻率，請查詢 INFORMATION_SCHEMA.INNODB_CMP 資料表，並檢查 COMPRESS_OPS 欄的值超出 COMPRESS_OPS_OK 欄的值多少。理想情況下，壓縮失敗不常發生；當它們發生時，您可以調整 innodb_compression_level、innodb_compression_failure_threshold_pct 和 innodb_compression_pad_pct_max 組態選項。

另請參閱 壓縮 (compression)、DML、頁面 (page)。

多個操作（在資料庫術語中，為交易 (transactions)）同時執行而不互相干擾的能力。並行也與效能有關，因為理想情況下，多個同時交易的保護會以最小的效能開銷運作，使用有效率的鎖定 (locking)機制。

另請參閱 ACID、鎖定 (locking)、交易 (transaction)。

保存 MySQL 啟動時使用的 選項 (option) 值的檔案。傳統上，在 Linux 和 Unix 上，此檔案命名為 my.cnf，在 Windows 上，則命名為 my.ini。您可以在檔案的 [mysqld] 區段下設定許多與 InnoDB 相關的選項。

如需 MySQL 在何處搜尋組態檔的資訊，請參閱第 6.2.2.2 節，「使用選項檔案」。

當您使用MySQL Enterprise Backup 產品時，通常會使用兩個組態檔：一個指定資料的來源位置和結構方式（可能是伺服器的原始組態檔），另一個是精簡的版本，僅包含一小組選項，用於指定備份資料的放置位置和結構方式。與 MySQL Enterprise Backup 產品一起使用的組態檔必須包含通常會從一般組態檔中排除的某些選項，因此您可能需要將選項新增到現有的組態檔中，以便與 MySQL Enterprise Backup 一起使用。

另請參閱 my.cnf、MySQL Enterprise Backup、選項 (option)、選項檔案 (option file)。

應用程式和 MySQL 伺服器之間的通訊管道。資料庫應用程式的效能和延展性會受到資料庫連線建立速度、可以同時建立多少個連線以及它們持續時間長短的影響。諸如 主機 (host)、連接埠 (port) 等參數在 Connector/NET 中以連線字串 (connection string) 表示，在 Connector/ODBC 中則以 DSN 表示。高流量系統會使用稱為連線集區 (connection pool) 的最佳化。

另請參閱 連線集區 (connection pool)、連線字串 (connection string)、Connector/NET、Connector/ODBC、DSN、主機 (host)、連接埠 (port)。

一個快取區域，允許在同一個應用程式中或跨不同應用程式重複使用資料庫連線 (connections)，而不是為每個資料庫操作設定和關閉新的連線。此技術在J2EE應用程式伺服器中很常見。使用 Connector/J 的Java 應用程式可以使用 Tomcat 和其他應用程式伺服器的連線集區功能。重複使用對應用程式是透明的；應用程式仍會像往常一樣開啟和關閉連線。

另請參閱 連線 (connection)、Connector/J、J2EE、Tomcat。

以字串常值編碼的資料庫連線 (connection)參數的表示方式，以便可以在程式碼中使用。字串的各部分代表連線參數，例如主機 (host) 和連接埠 (port)。連線字串包含數個以分號分隔的鍵值對。每個鍵值對都以等號連接。經常與 Connector/NET 應用程式一起使用；有關詳細資訊，請參閱建立 Connector/NET 連線字串。

另請參閱 連線 (connection)、Connector/NET、主機 (host)、連接埠 (port)。

MySQL 連接器為 用戶端 (client) 程式提供與 MySQL 伺服器的連線能力。多種程式設計語言和架構各自都有其相關的連接器。與 API 提供的較低層級存取權限形成對比。

另請參閱 API、用戶端 (client)、Connector/C++、Connector/J、Connector/NET、Connector/ODBC。

Connector/C++ 8.0 可用於存取實作文件儲存 (document store)的 MySQL 伺服器，或以傳統方式使用 SQL 查詢。它可以使用 X DevAPI 啟用 C++ 應用程式的開發，或使用 C 的 X DevAPI 來啟用純 C 應用程式的開發。它也可以啟用使用 Connector/C++ 1.1 的舊版 JDBC 型 API 的 C++ 應用程式開發。如需更多資訊，請參閱MySQL Connector/C++ 9.0 開發人員指南。

另請參閱 用戶端 (client)、連接器 (connector)、JDBC。

一個 JDBC 驅動程式，為以Java 程式設計語言開發的用戶端 (client) 應用程式提供連線能力。MySQL Connector/J 是 JDBC Type 4 驅動程式：MySQL 通訊協定的純 Java 實作，不依賴 MySQL 用戶端程式庫 (client libraries)。如需完整詳細資料，請參閱MySQL Connector/J 開發人員指南。

另請參閱 用戶端 (client)、用戶端程式庫 (client libraries)、連接器 (connector)、Java、JDBC。

一個 MySQL 連接器 (connector)，適用於使用諸如 C#、.NET、Mono、Visual Studio、ASP.net 和 ADO.net 等語言、技術和架構編寫應用程式的開發人員。

另請參閱 ADO.NET、ASP.net、連接器 (connector)、C#、Mono、Visual Studio。

提供使用業界標準開放資料庫連接 (Open Database Connectivity，ODBC) API 存取 MySQL 資料庫的 MySQL ODBC 驅動程式系列。先前稱為 MyODBC 驅動程式。如需完整詳細資訊，請參閱MySQL Connector/ODBC 開發人員指南。

另請參閱connector、ODBC。

針對 Windows 作業系統優化的 PHP 的 mysql 和 mysqli API 版本。

另請參閱connector、PHP、PHP API。

一種讀取操作，使用快照資訊呈現基於時間點的查詢結果，而不論同時執行的其他交易進行了哪些變更。如果查詢的資料已由另一個交易變更，則會根據還原日誌的內容重建原始資料。此技術可避免某些鎖定問題，這些問題可能會藉由強迫交易等待其他交易完成來降低並行處理能力。

使用 REPEATABLE READ 隔離層級時，快照是基於執行第一個讀取操作的時間。使用 READ COMMITTED 隔離層級時，快照會重設為每次一致性讀取操作的時間。

一致性讀取是 InnoDB 在 READ COMMITTED 和 REPEATABLE READ 隔離層級中處理 SELECT 陳述式的預設模式。由於一致性讀取不會在其存取的表格上設定任何鎖定，因此其他工作階段可以自由修改這些表格，同時在該表格上執行一致性讀取。

如需有關適用隔離層級的技術詳細資訊，請參閱第 17.7.2.3 節「一致性非鎖定讀取」。

另請參閱並行、隔離層級、鎖定、READ COMMITTED、REPEATABLE READ、快照、交易、還原日誌。

一種自動測試，可以阻止資料庫變更以防止資料不一致。（在電腦科學術語中，是一種與不變條件相關的斷言。）約束是 ACID 哲學的重要組成部分，以維持資料一致性。MySQL 支援的約束包括FOREIGN KEY 約束和唯一約束。

另請參閱ACID、foreign key、unique constraint。

一個由特定類型的 InnoDB 操作遞增的值。可用於測量伺服器的忙碌程度、疑難排解效能問題的來源，以及測試變更（例如，對組態設定或查詢使用的索引進行變更）是否具有所需的低階效果。不同的計數器類型可透過效能結構描述表格和INFORMATION_SCHEMA表格取得，特別是 INFORMATION_SCHEMA.INNODB_METRICS。

另請參閱INFORMATION_SCHEMA、metrics counter、Performance Schema。

一個索引，包含查詢擷取的所有欄。查詢不會使用索引值作為尋找完整表格列的指標，而是從索引結構傳回值，節省磁碟 I/O。InnoDB 可以將此最佳化技術應用於比 MyISAM 更多的索引，因為 InnoDB 次要索引也包含主要索引鍵欄。InnoDB 無法將此技術應用於針對交易修改的表格進行的查詢，直到該交易結束。

任何欄索引或複合索引在給定正確的查詢下，都可以充當涵蓋索引。請設計索引和查詢，以盡可能利用此最佳化技術。

另請參閱欄索引、複合索引、索引、主要索引鍵、次要索引。

一種工作負載類型，其主要瓶頸是記憶體中的 CPU 作業。通常涉及讀取密集型操作，其中結果都可以快取在緩衝池中。

另請參閱瓶頸、緩衝池、工作負載。

MySQL 使用術語「“當機”」來泛指任何無法執行正常清除的意外關機操作。例如，當機可能是由於資料庫伺服器電腦或儲存裝置上的硬體故障；斷電；可能導致 MySQL 伺服器停止的潛在資料不符；由 DBA 啟動的快速關機；或許多其他原因。InnoDB 表格的穩健自動當機復原可確保在伺服器重新啟動時資料保持一致，而無需 DBA 進行任何額外工作。

另請參閱當機復原、快速關機、InnoDB、關機。

在當機後重新啟動 MySQL 時發生的清除活動。對於 InnoDB 表格，將使用來自重做日誌的資料重播來自未完成交易的變更。在當機之前提交，但尚未寫入資料檔案的變更，將從雙寫緩衝區重建。當資料庫正常關機時，此類型的活動會在關機期間由清除操作執行。

在正常操作期間，已提交的資料可以儲存在變更緩衝區中一段時間，然後再寫入資料檔案。在保持資料檔案最新（這會在正常操作期間引入效能額外負荷）和緩衝資料（這會使關機和當機復原花費更長的時間）之間，始終存在取捨。

另請參閱變更緩衝區、提交、當機、資料檔案、雙寫緩衝區、InnoDB、清除、重做日誌。

「“建立、讀取、更新、刪除”」的縮寫，資料庫應用程式中常見的操作順序。通常表示一類具有相對簡單資料庫使用方式（DDL、DML 和 SQL 中的查詢陳述式）的應用程式，這些應用程式可以使用任何語言快速實作。

另請參閱DDL、DML、查詢、SQL。

一種內部 MySQL 資料結構，表示 SQL 陳述式的結果集。通常與預備陳述式和動態 SQL 一起使用。它的運作方式類似於其他高階語言中的迭代器，根據要求從結果集中產生每個值。

雖然 SQL 通常會為您處理游標，但在處理效能關鍵程式碼時，您可能會深入研究其內部運作方式。

另請參閱動態 SQL、預備陳述式、查詢。

追蹤資料庫物件（例如表格、索引和表格欄）的中繼資料。對於 MySQL 8.0 中引入的 MySQL 資料字典，中繼資料實際位於 mysql 資料庫目錄中的 InnoDB 單表空間表格檔案中。對於 InnoDB 資料字典，中繼資料實際位於 InnoDB 系統表空間中。

由於 MySQL Enterprise Backup 產品始終會備份 InnoDB 系統表空間，因此所有備份都包含 InnoDB 資料字典的內容。

另請參閱欄、單表空間、.frm 檔案、索引、MySQL Enterprise Backup、系統表空間、表格。

每個 MySQL 執行個體保留 InnoDB 的資料檔案和代表個別資料庫的目錄所在的目錄。由 datadir 組態選項控制。

另請參閱 資料檔案、執行個體。

實際包含資料表和索引資料的檔案。

InnoDB 系統表空間，用於保存 InnoDB 資料字典，並能夠保存多個 InnoDB 資料表的資料，它由一個或多個 .ibdata 資料檔案表示。

每個資料表一個檔案的表空間，用於保存單個 InnoDB 資料表的資料，它由一個 .ibd 資料檔案表示。

通用表空間（在 MySQL 5.7.6 中引入），可以保存多個 InnoDB 資料表的資料，也由一個 .ibd 資料檔案表示。

另請參閱 資料字典、每個資料表一個檔案、通用表空間、.ibd 檔案、ibdata 檔案、索引、系統表空間、資料表、表空間。

主要執行大型查詢的資料庫系統或應用程式。為了提高查詢效率，唯讀或主要為唯讀的資料可能以反正規化的形式組織。可以從 MySQL 5.6 及更高版本中針對唯讀交易的優化中獲益。與 OLTP 對比。

另請參閱 反正規化、OLTP、查詢、唯讀交易。

在 MySQL 資料目錄中，每個資料庫都由一個單獨的目錄表示。InnoDB 系統表空間，可以保存 MySQL 執行個體中多個資料庫的資料表資料，它保存在位於各個資料庫目錄之外的資料檔案中。當啟用每個資料表一個檔案模式時，除非使用 DATA DIRECTORY 子句在其他位置建立，否則表示個別 InnoDB 資料表的 .ibd 檔案會儲存在資料庫目錄內。在 MySQL 5.7.6 中引入的通用表空間也將資料表資料保存在 .ibd 檔案中。與每個資料表一個檔案的 .ibd 檔案不同，通用表空間的 .ibd 檔案可以保存 MySQL 執行個體中多個資料庫的資料表資料，並且可以指定到相對於或獨立於 MySQL 資料目錄的目錄中。

對於使用 MySQL 很久的使用者而言，資料庫是一個熟悉的概念。來自 Oracle Database 背景的使用者可能會發現，MySQL 中資料庫的含義更接近 Oracle Database 中稱為結構描述的內容。

另請參閱 資料檔案、每個資料表一個檔案、.ibd 檔案、執行個體、結構描述、系統表空間。

資料控制語言，一組用於管理權限的 SQL 陳述式。在 MySQL 中，包含 GRANT 和 REVOKE 陳述式。與 DDL 和 DML 對比。

另請參閱 DDL、DML、SQL。

一項功能，可讓您使用 Visual Studio 中的資料設計工具來操作 MySQL 資料庫中的結構描述和物件。對於使用 Connector/NET 的 MySQL 應用程式，MySQL Visual Studio 外掛程式充當 MySQL 5.0 及更高版本的 DDEX 提供者。

另請參閱 Visual Studio。

資料定義語言，一組用於操作資料庫本身而非個別資料表列的 SQL 陳述式。包括 CREATE、ALTER 和 DROP 陳述式的所有形式。也包括 TRUNCATE 陳述式，因為它的工作方式與 DELETE FROM table_name 陳述式不同，即使最終效果相似。

DDL 陳述式會自動提交目前的交易；它們無法回滾。

InnoDB 線上 DDL 功能增強了 CREATE INDEX、DROP INDEX 和許多類型的 ALTER TABLE 操作的效能。如需詳細資訊，請參閱第 17.12 節，〈InnoDB 和線上 DDL〉。此外，InnoDB 每個資料表一個檔案設定會影響 DROP TABLE 和 TRUNCATE TABLE 操作的行為。

與 DML 和 DCL 對比。

另請參閱 提交、DCL、DML、每個資料表一個檔案、回滾、SQL、交易。

不同交易無法繼續進行的情況，因為每個交易都持有另一個交易需要的鎖定。因為兩個交易都在等待資源可用，所以沒有一個會釋放它持有的鎖定。

當交易以相反的順序鎖定多個資料表中的列（透過 UPDATE 或 SELECT ... FOR UPDATE 等陳述式）時，可能會發生死結。當這些陳述式鎖定索引記錄和間隙範圍時，也可能發生死結，其中每個交易由於時間問題而取得一些鎖定但沒有其他鎖定。

如需關於如何自動偵測和處理死結的背景資訊，請參閱第 17.7.5.2 節，〈死結偵測〉。如需關於避免和從死結狀況復原的提示，請參閱第 17.7.5.3 節，〈如何將死結減至最少並加以處理〉。

另請參閱 間隙、鎖定、交易。

一種自動偵測何時發生死結的機制，並自動回滾其中一個相關的交易（受害者）。可以使用 innodb_deadlock_detect 設定選項停用死結偵測。

另請參閱 死結、回滾、交易、受害者。

當 InnoDB 處理 DELETE 陳述式時，列會立即被標記為刪除，且不再由查詢傳回。儲存會在稍後，在稱為清除操作的定期垃圾收集期間回收。若要移除大量資料，效能特性相關的操作為TRUNCATE 和 DROP。

另請參閱 捨棄、清除、截斷。

將次要索引頁面的變更（由 DELETE 操作導致）儲存在變更緩衝區中，而不是立即寫入變更，以便執行實體寫入以盡量減少隨機 I/O 的技術。（因為刪除操作是兩步驟程序，所以此操作會緩衝通常會將索引記錄標記為刪除的寫入。）它是變更緩衝的類型之一；其他類型為插入緩衝和清除緩衝。

另請參閱 變更緩衝區、變更緩衝、插入緩衝區、插入緩衝、清除緩衝。

一種資料儲存策略，將資料複製到不同的資料表中，而不是使用外鍵和join查詢來連結資料表。這種策略通常用於資料倉儲應用程式中，在資料載入後不會再更新。在這種應用程式中，查詢效能比在更新期間保持資料一致性更重要。與正規化形成對比。

另請參閱 資料倉儲、外鍵、join、正規化。

一種索引類型，其索引儲存經過最佳化，可處理 ORDER BY column DESC 子句。

另請參閱 索引 (index)。

字典物件快取會在記憶體中儲存先前存取的資料字典物件，以啟用物件重複使用並減少磁碟 I/O。使用基於 LRU 的逐出策略，從記憶體中逐出最近最少使用的物件。快取由多個分割區組成，這些分割區儲存不同的物件類型。

有關詳細資訊，請參閱第 16.4 節「字典物件快取」。

另請參閱 資料字典、LRU。

在 InnoDB 緩衝池中已在記憶體中更新的頁面，這些變更尚未寫入（刷新）到資料檔案。與乾淨頁相反。

另請參閱 緩衝池、乾淨頁、資料檔案、刷新、頁面。

一種擷取不可靠資料的操作，這些資料是由另一個交易更新但尚未提交的資料。它只在使用稱為讀取未提交的隔離等級時才有可能發生。

這種操作不符合資料庫設計的 ACID 原則。它被認為是非常危險的，因為資料可能會被回滾，或者在提交之前進一步更新；然後，執行髒讀的交易將使用從未確認為準確的資料。

與之相反的是一致讀取，其中 InnoDB 確保交易不會讀取由另一個交易更新的資訊，即使另一個交易在此期間提交。

另請參閱 ACID、提交、一致讀取、隔離等級、READ UNCOMMITTED、回滾。

一種主要在磁碟儲存（硬碟或等效裝置）上組織資料的資料庫。資料在磁碟和記憶體之間來回傳輸以進行操作。它與記憶體資料庫相反。儘管 InnoDB 是基於磁碟的，但它也包含諸如緩衝池、多個緩衝池執行個體和自我調整雜湊索引等功能，這些功能允許某些類型的工作負載主要在記憶體中執行。

另請參閱 自我調整雜湊索引、緩衝池、記憶體資料庫。

一種主要瓶頸是磁碟 I/O 的工作負載類型。（也稱為I/O 限制。）通常涉及頻繁的磁碟寫入，或隨機讀取比緩衝池可容納的更多資料。

另請參閱瓶頸、緩衝池、工作負載。

資料操作語言，一組用於執行 INSERT、UPDATE 和 DELETE 操作的 SQL 陳述式。 SELECT 陳述式有時被視為 DML 陳述式，因為 SELECT ... FOR UPDATE 形式的鎖定考量與 INSERT、UPDATE 和 DELETE 相同。

用於 InnoDB 資料表的 DML 陳述式在交易的內容中運作，因此其效果可以作為單一單元進行提交或回滾。

與DDL 和 DCL 形成對比。

另請參閱 提交、DCL、DDL、鎖定、回滾、SQL、交易。

在 InnoDB 全文檢索功能中，資料表中包含FULLTEXT 索引的特殊欄位，用於唯一識別與每個 ilist 值關聯的文件。其名稱為 FTS_DOC_ID（必須大寫）。該欄位本身必須是 BIGINT UNSIGNED NOT NULL 類型，並具有一個名為 FTS_DOC_ID_INDEX 的唯一索引。最好在建立資料表時定義此欄位。如果 InnoDB 必須在建立 FULLTEXT 索引時將欄位新增至資料表，則索引操作的成本會高出許多。

另請參閱 全文檢索、FULLTEXT 索引、ilist。

InnoDB 使用稱為雙寫的檔案刷新技術。在將頁面寫入資料檔案之前，InnoDB 會先將它們寫入稱為雙寫緩衝區的儲存區域。只有在寫入並刷新到雙寫緩衝區後，InnoDB 才會將頁面寫入其在資料檔案中的正確位置。如果在頁面寫入過程中發生作業系統、儲存子系統或 mysqld 處理程序崩潰，InnoDB 可以在損毀復原期間從雙寫緩衝區中找到頁面的良好副本。

儘管資料始終寫入兩次，但雙寫緩衝區不需要兩倍的 I/O 額外負擔或兩倍的 I/O 操作。資料是以大型循序區塊的形式寫入緩衝區本身的，並使用單個 fsync() 呼叫至作業系統。

另請參閱 損毀復原、資料檔案、頁面、清除。

一種 DDL 操作，透過諸如 DROP TABLE 或 DROP INDEX 之類的陳述式來移除結構描述物件。它在內部對應到 ALTER TABLE 陳述式。從 InnoDB 的角度來看，此類操作的效能考量包括鎖定資料字典以確保所有相關物件都已更新的時間，以及更新諸如緩衝池等記憶體結構的時間。對於資料表，刪除操作的特性與截斷操作（TRUNCATE TABLE 陳述式）略有不同。

另請參閱 緩衝池、資料字典、DDL、資料表、截斷。

「資料庫來源名稱」的縮寫。它是 Connector/ODBC 中連線資訊的編碼。有關完整詳細資訊，請參閱 在 Windows 上設定 Connector/ODBC DSN。它相當於 Connector/NET 使用的連線字串。

另請參閱 連線、連線字串、Connector/NET、Connector/ODBC。

一種由 ODBC 支援的游標類型，當重新讀取資料列時，可以獲取新的和已變更的結果。變更對游標的可見程度以及速度取決於所涉及的表格類型（交易式或非交易式）以及交易式表格的隔離層級。對動態游標的支援必須明確啟用。

參閱 游標、ODBC。

一種 InnoDB 資料列格式。由於較長的變動長度資料欄值儲存在包含資料列資料的頁面之外，因此對於包含大型物件的資料列來說非常有效率。由於通常不會存取大型欄位來評估查詢條件，因此它們不會經常被帶入 緩衝池，從而減少 I/O 操作並更好地利用快取記憶體。

從 MySQL 5.7.9 開始，預設資料列格式由 innodb_default_row_format 定義，其預設值為 DYNAMIC。

有關 InnoDB DYNAMIC 資料列格式的其他資訊，請參閱 DYNAMIC 資料列格式。

參閱 緩衝池、檔案格式、資料列格式。

一種功能，可讓您使用更穩健、安全且有效率的方法來建立和執行 預處理語句，以替換參數值，而不是使用將語句部分串連到字串變數中的簡單技術。

參閱 預處理語句。

通過動態 SQL建立和執行的預處理語句。

參閱 動態 SQL、預處理語句。

一個與 beta 相似的階段，通常在非關鍵任務設定中評估軟體產品的效能、功能和相容性。

參閱 beta。

一種程式語言，包含許多物件導向功能。它的一些概念對於 Java 和 C# 開發人員來說很熟悉。有關 MySQL 的開源 Eiffel API，請參閱 第 31.13 節「MySQL Eiffel 包裝器」。

參閱 API、C#、Java。

嵌入式 MySQL 伺服器程式庫 (libmysqld) 使得在客戶端應用程式內執行功能齊全的 MySQL 伺服器成為可能。主要優點是提高了嵌入式應用程式的速度和簡化了管理。

參閱 客戶端、libmysqld。

一種記錄類型，顯示有關 MySQL 啟動和重大執行階段錯誤以及當機資訊的資訊。有關詳細資訊，請參閱 第 7.4.2 節「錯誤記錄」。

參閱 當機、記錄。

從快取或其他臨時儲存區域（例如 InnoDB 緩衝池）中移除項目的過程。通常（但不總是）使用 LRU 演算法來決定要移除哪個項目。當髒頁被逐出時，其內容會被刷新到磁碟，並且任何髒的相鄰頁也可能會被刷新。

參閱 緩衝池、髒頁、刷新、LRU、相鄰頁。

一種攔截器類型，用於追蹤、偵錯或增強資料庫應用程式遇到的 SQL 錯誤。例如，攔截器程式碼可以發出 SHOW WARNINGS 語句以檢索其他資訊，並新增描述性文字，甚至變更傳回給應用程式的例外類型。由於攔截器程式碼僅在 SQL 語句傳回錯誤時才會被呼叫，因此它不會在正常（無錯誤）操作期間對應用程式造成任何效能損失。

在使用 Connector/J 的 Java 應用程式中，設定此類型的攔截器包括實作 com.mysql.jdbc.ExceptionInterceptor 介面，並將 exceptionInterceptors 屬性新增到連線字串。

在使用 Connector/NET 的 Visual Studio 應用程式中，設定此類型的攔截器包括定義一個從 BaseExceptionInterceptor 類別繼承的類別，並將該類別名稱指定為連線字串的一部分。

參閱 Connector/J、Connector/NET、攔截器、Java、Visual Studio。

一種鎖定，可防止任何其他交易鎖定同一資料列。根據交易隔離層級，這種鎖定可能會阻止其他交易寫入同一資料列，或者也可能會阻止其他交易讀取同一資料列。預設 InnoDB 隔離層級 可重複讀取，透過允許交易讀取具有獨佔鎖定的資料列來啟用更高的並行性，這種技術稱為一致讀取。

參閱 並行性、一致讀取、隔離層級、鎖定、可重複讀取、共用鎖定、交易。

表空間內的一組頁面。對於 16KB 的預設頁面大小，一個區塊包含 64 個頁面。在 MySQL 5.6 中，InnoDB 執行個體的頁面大小可以是 4KB、8KB 或 16KB，由 innodb_page_size 設定選項控制。對於 4KB、8KB 和 16KB 頁面大小，區塊大小始終為 1MB（或 1048576 位元組）。

MySQL 5.7.6 中新增了對 32KB 和 64KB InnoDB 頁面大小的支援。對於 32KB 頁面大小，區塊大小為 2MB。對於 64KB 頁面大小，區塊大小為 4MB。

InnoDB 功能（例如區段、預讀請求和雙寫緩衝區）使用一次讀取、寫入、配置或釋放一個區塊資料的 I/O 操作。

參閱 雙寫緩衝區、頁面、頁面大小、預讀、區段、表空間。

一個包含 MySQL 表的元資料（例如表格定義）的檔案。.frm 檔案在 MySQL 8.0 中已移除，但在較早版本的 MySQL 中仍在使用。在 MySQL 8.0 中，先前儲存在 .frm 檔案中的資料儲存在資料字典表格中。

參閱 資料字典、MySQL Enterprise Backup、系統表空間。

在發生故障時自動切換到備用伺服器的能力。在 MySQL 環境中，容錯移轉涉及備用資料庫伺服器。通常由應用程式伺服器或框架在 J2EE 環境中支援。

參閱 Connector/J、J2EE。

首先在 InnoDB 外掛程式中引入的功能，現在是 5.5 及更高版本 MySQL 的一部分，透過避免完全重寫相關表格來加速建立 InnoDB 次要索引。此加速也適用於捨棄次要索引。

由於索引維護可能會給許多資料傳輸操作增加效能負擔，因此請考慮在沒有任何次要索引的情況下執行諸如 ALTER TABLE ... ENGINE=INNODB 或 INSERT INTO ... SELECT * FROM ... 之類的操作，然後再建立索引。

在 MySQL 5.6 中，此功能變得更加通用。您可以在建立索引的同時讀取和寫入資料表，而且更多種類的 ALTER TABLE 操作可以在不複製資料表、不阻擋 DML 操作或兩者兼具的情況下執行。因此，在 MySQL 5.6 及更高版本中，這組功能被稱為 線上 DDL，而不是快速索引建立。

有關相關資訊，請參閱第 17.12 節，「InnoDB 和線上 DDL」。

另請參閱 DML、索引、線上 DDL、次要索引。

InnoDB 的預設關閉程序，基於組態設定 innodb_fast_shutdown=1。為了節省時間，某些 flush 操作會被跳過。這種關閉類型在正常使用期間是安全的，因為 flush 操作會在下次啟動期間執行，使用與當機復原相同的機制。如果資料庫因升級或降級而關閉，請改為執行慢速關閉，以確保在關閉期間將所有相關變更套用至資料檔案。

另請參閱 當機復原、資料檔案、flush、關閉、慢速關閉。

InnoDB 資料表的檔案格式。

另請參閱 每個資料表一個檔案、.ibd 檔案、ibdata 檔案、資料列格式。

由 innodb_file_per_table 選項控制的設定的通用名稱，這是一個重要的組態選項，會影響 InnoDB 檔案儲存、功能可用性及 I/O 特性的各方面。自 MySQL 5.6.7 起，預設會啟用 innodb_file_per_table。

啟用 innodb_file_per_table 選項後，您可以在自己的 .ibd 檔案中建立資料表，而不是在 系統表格空間的共用 ibdata 檔案中建立。當資料表資料儲存在個別的 .ibd 檔案中時，您可以更彈性地選擇資料壓縮等功能所需的資料列格式。TRUNCATE TABLE 操作也更快，且回收的空間可以由作業系統使用，而不是保留給 InnoDB。

MySQL Enterprise Backup 產品對於位於自己檔案中的資料表更具彈性。例如，資料表可以從備份中排除，但前提是它們位於不同的檔案中。因此，此設定適用於不常備份或以不同排程備份的資料表。

另請參閱 壓縮的資料列格式、壓縮、檔案格式、.ibd 檔案、ibdata 檔案、innodb_file_per_table、MySQL Enterprise Backup、資料列格式、系統表格空間。

在 InnoDB 索引中，頁面在分割之前被索引資料佔用的比例。當索引資料首次在頁面之間分割時，未使用的空間允許更新具有較長字串值的資料列，而不需要耗費成本的索引維護操作。如果填滿因素太低，索引會消耗比所需更多的空間，導致讀取索引時產生額外的 I/O 負擔。如果填滿因素太高，任何增加資料行值長度的更新都可能導致額外的索引維護 I/O 負擔。如需更多資訊，請參閱第 17.6.2.2 節，「InnoDB 索引的實體結構」。

另請參閱 索引、頁面。

此資料列格式由 MyISAM 儲存引擎使用，而非 InnoDB 使用。如果您在 MySQL 5.7.6 或更早版本中建立具有選項 ROW_FORMAT=FIXED 的 InnoDB 資料表，InnoDB 會改為使用精簡資料列格式，即使 FIXED 值可能仍會顯示在 SHOW TABLE STATUS 報告等輸出中。自 MySQL 5.7.7 起，如果指定 ROW_FORMAT=FIXED，InnoDB 會傳回錯誤。

另請參閱 精簡資料列格式、資料列格式。

將變更寫入至已緩衝在記憶體區域或暫時磁碟儲存區域中的資料庫檔案。InnoDB 定期刷新的儲存結構包括重做日誌、復原日誌和緩衝池。

刷新可能會發生，因為記憶體區域已滿且系統需要釋放一些空間，因為 commit 操作表示可以完成交易中的變更，或者因為慢速關閉操作表示應完成所有未完成的工作。當並非必須一次刷新所有緩衝資料時，InnoDB 可以使用一種稱為模糊檢查點的技術來刷新小批量的頁面，以分散 I/O 負擔。

另請參閱 緩衝池、commit、模糊檢查點、重做日誌、慢速關閉、復原日誌。

一個內部 InnoDB 資料結構，用於追蹤緩衝池中的髒頁，也就是已變更且需要寫回磁碟的頁面。此資料結構會由 InnoDB 內部迷你交易頻繁更新，因此受到其自身的互斥鎖保護，以允許同時存取緩衝池。

另請參閱 緩衝池、髒頁、LRU、迷你交易、互斥鎖、頁面、頁面清除器。

單獨 InnoDB 資料表中的資料列之間的一種類型指標關係。外來鍵關係是在父資料表和子資料表的其中一個資料行上定義。

除了啟用快速查詢相關資訊外，外來鍵還有助於強制執行參考完整性，防止這些指標在資料插入、更新和刪除時失效。這種強制執行機制是一種限制。如果相關聯的外來鍵值不存在於另一個資料表中，則無法插入指向另一個資料表的資料列。如果刪除某個資料列或其外來鍵值變更，且另一個資料表中的資料列指向該外來鍵值，則可以設定外來鍵以防止刪除、使另一個資料表中的對應資料行值變成 null，或自動刪除另一個資料表中的對應資料列。

設計標準化資料庫的其中一個階段是識別重複的資料，將該資料分離到新的資料表中，並設定外來鍵關係，以便可以使用 join 操作像查詢單一資料表一樣查詢多個資料表。

另請參閱 子資料表、外來鍵限制、join、標準化、NULL、父資料表、參考完整性、關聯。

透過外來鍵關係維護資料庫一致性的限制類型。與其他類型的限制一樣，如果資料變得不一致，則可以防止資料插入或更新；在這種情況下，要防止的不一致是多個資料表中的資料之間的不一致。或者，當執行 DML 操作時，FOREIGN KEY 限制可能會導致子資料列中的資料根據建立外來鍵時指定的 ON CASCADE 選項而刪除、變更為不同的值或設定為 null。

另請參閱 子資料表、限制、DML、外來鍵、NULL。

在大多數情況下，是全文檢索的縮寫。有時在效能討論中，是完整資料表掃描的縮寫。

另請參閱 完整資料表掃描、全文檢索。

一種備份，其中包含每個 MySQL 資料庫中的所有資料表，以及 MySQL 執行個體中的所有資料庫。與部分備份對比。

參見 備份 (backup)、資料庫 (database)、執行個體 (instance)、部分備份 (partial backup)、表格 (table)。

一種操作，需要讀取整個表格的內容，而不是僅使用索引 (index)選擇的部分。通常在小型查詢表格中執行，或是在資料倉儲環境中，針對大型表格進行所有可用資料的彙總與分析時執行。這些操作發生的頻率，以及表格相對於可用記憶體的大小，會影響查詢最佳化和管理緩衝池 (buffer pool)所使用的演算法。

索引的目的是允許在大型表格中查詢特定值或值範圍，從而在實際情況中避免全表格掃描。

參見 緩衝池 (buffer pool)、索引 (index)。

MySQL 的功能，用於在表格資料中尋找單字、片語、單字的布林組合等，其速度比使用 SQL LIKE 運算子或撰寫您自己的應用程式層級搜尋演算法更快、更方便、更彈性。它使用 SQL 函式 MATCH() 和 FULLTEXT 索引 (FULLTEXT indexes)。

參見 FULLTEXT 索引 (FULLTEXT index)。

一種特殊的索引 (index)，在 MySQL 全文搜尋 (full-text search)機制中保留搜尋索引 (search index)。代表欄位值中的單字，省略任何指定為停用字 (stopwords)的單字。最初，僅適用於 MyISAM 表格。從 MySQL 5.6.4 開始，也適用於 InnoDB 表格。

參見 全文搜尋 (full-text search)、索引 (index)、InnoDB、搜尋索引 (search index)、停用字 (stopword)。

一種技術，從緩衝池 (buffer pool)中刷新 (flushes)小批量的髒頁 (dirty pages)，而不是一次刷新所有髒頁，這樣會中斷資料庫處理。

參見 緩衝池 (buffer pool)、髒頁 (dirty page)、刷新 (flush)。

「正式發布 (Generally available)」，指軟體產品離開測試版 (beta)，可以銷售、提供官方支援和生產使用的階段。

參閱 beta。

「全域組件快取 (Global Assembly Cache)」的縮寫。用於在 .NET 系統上儲存程式庫（組件 (assemblies)）的中心區域。實際由巢狀資料夾組成，.NET CLR 將其視為單一虛擬資料夾。

參見 .NET、組件 (assembly)。

在 InnoDB 索引 (index) 資料結構中，可以插入新值的位置。當您使用諸如 SELECT ... FOR UPDATE 之類的語句鎖定一組列時，InnoDB 可以建立適用於間隙以及索引中實際值的鎖定。例如，如果您選擇所有大於 10 的值進行更新，則間隙鎖定會阻止另一個交易插入大於 10 的新值。至上記錄 (supremum record)和至下記錄 (infimum record)代表包含所有大於或小於所有目前索引值的間隙。

參見 並行 (concurrency)、間隙鎖定 (gap lock)、索引 (index)、至下記錄 (infimum record)、隔離層級 (isolation level)、至上記錄 (supremum record)。

對索引記錄之間的間隙 (gap)的鎖定 (lock)，或對第一個索引記錄之前或最後一個索引記錄之後的間隙的鎖定。例如，SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE; 會防止其他交易在欄位 t.c1 中插入值 15，無論該欄位中是否已存在任何此類值，因為該範圍中所有現有值之間的間隙都已鎖定。與記錄鎖定 (record lock)和下鍵鎖定 (next-key lock)對比。

間隙鎖定是效能和並行 (concurrency)之間的折衷方案的一部分，並且在某些交易隔離層級 (isolation levels)中使用，而在其他交易隔離層級中則不使用。

參見 間隙 (gap)、至下記錄 (infimum record)、鎖定 (lock)、下鍵鎖定 (next-key lock)、記錄鎖定 (record lock)、至上記錄 (supremum record)。

一種記錄 (log)類型，用於診斷和疑難排解 MySQL 伺服器處理的 SQL 陳述式。可以儲存在檔案中或資料庫表格中。您必須透過 general_log 組態選項啟用此功能才能使用它。您可以透過 sql_log_off 組態選項停用特定連線的此功能。

記錄的查詢範圍比慢速查詢記錄 (slow query log)更廣泛。與用於複寫的二進位記錄 (binary log)不同，一般查詢記錄包含 SELECT 陳述式，且不維護嚴格的排序。如需更多資訊，請參閱第 7.4.3 節，「一般查詢記錄」。

參見 二進位記錄 (binary log)、記錄 (log)、慢速查詢記錄 (slow query log)。

使用 CREATE TABLESPACE 語法建立的共享 InnoDB 表格空間 (tablespace)。一般表格空間可以在 MySQL 資料目錄之外建立，能夠容納多個表格 (tables)，並支援所有列格式的表格。一般表格空間在 MySQL 5.7.6 中引入。

使用 CREATE TABLE tbl_name ... TABLESPACE [=] tablespace_name 或 ALTER TABLE tbl_name TABLESPACE [=] tablespace_name 語法將表格新增至一般表格空間。

與系統表格空間 (system tablespace)和每表格檔案 (file-per-table)表格空間對比。

如需更多資訊，請參閱第 17.6.3.3 節，「一般表格空間」。

參見 每表格檔案 (file-per-table)、系統表格空間 (system tablespace)、表格 (table)、表格空間 (tablespace)。

欄位的值是從包含在欄位定義中的運算式計算而來。產生式欄位可以是虛擬 (virtual)的或儲存 (stored)的。

參見 基本欄位 (base column)、儲存產生式欄位 (stored generated column)、虛擬產生式欄位 (virtual generated column)。

參見 J2EE。

一個暫時表格空間 (temporary tablespace)，用於儲存使用者建立的暫時表格的變更回滾區段 (rollback segments)。

參見 暫時表格空間 (temporary tablespace)。

一種參與XA作業的交易 (transaction)類型。它由數個交易動作組成，這些動作本身具有交易性質，但都必須以群組形式成功完成，或以群組形式全部回滾。本質上，這將ACID屬性「提升一個層級」，以便多個 ACID 交易可以協同執行，作為也具有 ACID 屬性的全域作業的元件。

參見 ACID、交易 (transaction)、XA。

一種 InnoDB 最佳化，會針對一組提交 (commit)作業執行一次低階 I/O 作業（寫入記錄），而不是針對每個提交分別刷新和同步。

參見 二進位記錄 (binary log)、提交 (commit)。

「全域唯一識別碼」（globally unique identifier）的縮寫，此 ID 值可用於將不同資料庫、語言、作業系統等之間的資料建立關聯。（作為使用循序整數的替代方案，因為相同的值可能會出現在不同的表格、資料庫等等，並指向不同的資料。）舊版的 MySQL 將其表示為 BINARY(16)。目前，它表示為 CHAR(36)。MySQL 有一個 UUID() 函數，會以字元格式傳回 GUID 值，還有一個 UUID_SHORT() 函數，會以整數格式傳回 GUID 值。因為連續的 GUID 值不一定會依遞增順序排序，所以將其作為大型 InnoDB 表格的主索引鍵並不是有效率的做法。

一種 索引類型，適用於使用等號運算子（而非大於或 BETWEEN 等範圍運算子）的查詢。它適用於 MEMORY 表格。雖然雜湊索引由於歷史因素是 MEMORY 表格的預設索引，但該儲存引擎也支援 B 樹索引，通常是通用查詢的更好選擇。

MySQL 包含此索引類型的變體，即自適應雜湊索引，如果根據執行階段條件需要，會自動為 InnoDB 表格建構此索引。

另請參閱 自適應雜湊索引、B 樹、索引、InnoDB。

「硬碟機」（hard disk drive）的縮寫。通常在與 SSD 比較和對照時，指的是使用旋轉碟片的儲存媒體。其效能特性會影響磁碟型工作負載的輸送量。

另請參閱 磁碟型、SSD。

定期傳送的訊息，表示系統運作正常。在複製內容中，如果來源停止傳送這類訊息，其中一個複本可以取代其位置。叢集環境中的伺服器之間可以使用類似的技術，以確認所有伺服器都運作正常。

另請參閱 複製、來源。

表示上限的值，可能是執行階段不應超過的硬性限制，或是實際達到的最大值的記錄。與低水位線相反。

另請參閱 低水位線。

一份交易的清單，其中包含已標記刪除的記錄，這些記錄會由 InnoDB 清除作業排定處理。記錄在復原日誌中。歷程記錄清單的長度會由 SHOW ENGINE INNODB STATUS 命令回報。如果歷程記錄清單的長度超過 innodb_max_purge_lag 組態選項的值，則每個 DML 作業都會稍微延遲，以允許清除作業完成刷新已刪除的記錄。

也稱為清除延遲。

另請參閱 DML、刷新、清除、清除延遲、回滾區段、交易、復原日誌。

從頁面釋放空的區塊。InnoDB 透明頁面壓縮功能依賴於空洞穿孔支援。如需詳細資訊，請參閱 第 17.9.2 節，〈InnoDB 頁面壓縮〉。

另請參閱 稀疏檔案、透明頁面壓縮。

資料庫伺服器的網路名稱，用於建立連線。通常會與連接埠一起指定。在某些情況下，對於存取與應用程式位於同一伺服器上的資料庫，IP 位址 127.0.0.1 比特殊名稱 localhost 更有效。

另請參閱 連線、localhost、連接埠。

當某個資料列、表格或內部資料結構被頻繁存取，需要某種形式的鎖定或互斥，進而導致效能或延展性問題的情況。

雖然「熱門」通常表示不良狀況，但熱備份是偏好的備份類型。

另請參閱 熱備份。

在資料庫執行且應用程式正在讀取和寫入資料庫時進行的備份。備份不僅僅是複製資料檔案：它必須包含備份過程中插入或更新的任何資料；它必須排除備份過程中刪除的任何資料；而且它必須忽略任何未提交的變更。

執行熱備份（尤其是 InnoDB 表格，但也包含 MyISAM 和其他儲存引擎的表格）的 Oracle 產品稱為MySQL Enterprise Backup。

熱備份程序包含兩個階段。資料檔案的初始複製會產生原始備份。套用步驟會併入備份執行時對資料庫所做的任何變更。套用變更會產生已準備的備份；這些檔案隨時都可還原。

另請參閱 套用、MySQL Enterprise Backup、已準備的備份、原始備份。

每個表格獨立檔案表格空間和一般表格空間的資料檔案。每個表格獨立檔案表格空間 .ibd 檔案包含單一表格和關聯的索引資料。一般表格空間 .ibd 檔案可能包含多個表格的表格和索引資料。

.ibd 檔案擴充功能不適用於系統表格空間，它由一個或多個ibdata 檔案組成。

如果使用 DATA DIRECTORY = 子句建立每個表格獨立檔案表格空間或一般表格空間，則 .ibd 檔案會位於指定的路徑，也就是在一般資料目錄之外。

當 .ibd 檔案包含在 MySQL Enterprise Backup 產品的壓縮備份中時，壓縮後的等效檔案為 .ibz 檔案。

另請參閱 資料庫、每個表格獨立檔案、一般表格空間、ibdata 檔案、.ibz 檔案、innodb_file_per_table、MySQL Enterprise Backup、系統表格空間。

當 MySQL Enterprise Backup 產品執行壓縮備份時，它會將使用每個表格獨立檔案設定建立的每個表格空間檔案從 .ibd 擴充功能轉換為 .ibz 擴充功能。

在備份期間套用的壓縮與壓縮資料列格式不同，後者會讓表格資料在正常作業期間保持壓縮狀態。壓縮備份作業會跳過已經採用壓縮資料列格式的表格空間的壓縮步驟，因為第二次壓縮會減慢備份速度，但幾乎不會節省任何空間。

另請參閱 壓縮備份、壓縮資料列格式、每個表格獨立檔案、.ibd 檔案、MySQL Enterprise Backup、表格空間。

由 InnoDB 在 MySQL 資料庫中管理的檔案集合：系統表空間、單表單檔表空間檔案，以及重做日誌檔案。根據 MySQL 版本和 InnoDB 設定，可能還包括通用表空間、暫存表空間和復原表空間檔案。在詳細討論 InnoDB 檔案結構和格式時，有時會使用此術語來指代 InnoDB 在 MySQL 資料庫中管理的一組檔案。

另請參閱 資料庫、單表單檔、通用表空間、重做日誌、系統表空間、暫存表空間、復原表空間。

在 MySQL Enterprise Backup 產品執行熱備份操作期間建立的補充備份檔案。它包含有關備份執行期間發生的任何資料變更的資訊。初始備份檔案（包括 ibbackup_logfile）稱為原始備份，因為備份操作期間發生的變更尚未納入。在您對原始備份檔案執行套用步驟後，產生的檔案確實會包含那些最終資料變更，並稱為已準備備份。在這個階段，ibbackup_logfile 檔案已不再需要。

另請參閱 套用、熱備份、MySQL Enterprise Backup、已準備備份、原始備份。

一組名稱類似 ibdata1、ibdata2 等的檔案，這些檔案構成 InnoDB 系統表空間。如需有關系統表空間 ibdata 檔案中的結構和資料的資訊，請參閱 第 17.6.3.1 節，「系統表空間」。

ibdata 檔案的增長受到 innodb_autoextend_increment 設定選項的影響。

另請參閱 變更緩衝區、資料字典、雙寫緩衝區、單表單檔、.ibd 檔案、innodb_file_per_table、系統表空間、復原日誌。

用於未壓縮 InnoDB 暫存表和相關物件的 InnoDB 暫存表空間資料檔案。設定檔案選項 innodb_temp_data_file_path 允許使用者定義暫存表空間資料檔案的相對路徑。如果未指定 innodb_temp_data_file_path，則預設行為是在資料目錄中建立一個自動擴充的 12MB 資料檔案，名為 ibtmp1，與 ibdata1 並列。

另請參閱 資料檔案、暫存表、暫存表空間。

一組檔案，通常命名為 ib_logfile0 和 ib_logfile1，構成重做日誌。有時也稱為日誌群組。這些檔案會記錄嘗試變更 InnoDB 表格中資料的陳述式。這些陳述式會在崩潰後的啟動時自動重播，以修正不完整交易寫入的資料。

此資料不能用於手動復原；對於這種類型的操作，請使用二進位日誌。

另請參閱 二進位日誌、日誌群組、重做日誌。

在 InnoDB 全文索引中，由文件 ID 和符記（即特定單字）的位置資訊組成的資料結構。

參見 FULLTEXT 索引 (FULLTEXT index)。

InnoDB 為確保一致性而取得的資料列鎖定，無需您明確請求。

另請參閱 資料列鎖定。

一種將資料保存在記憶體中的資料庫系統，以避免因磁碟 I/O 以及磁碟區塊和記憶體區域之間的轉換而產生的額外負荷。某些記憶體內資料庫會犧牲耐用性（ACID 設計理念中的 「D」），並且容易受到硬體、電源和其他類型故障的影響，使其更適合唯讀操作。其他記憶體內資料庫確實會使用耐用性機制，例如將變更記錄到磁碟或使用非揮發性記憶體。

解決相同類型記憶體密集處理的 MySQL 功能包括 InnoDB 緩衝池、自適性雜湊索引和唯讀交易最佳化、MEMORY 儲存引擎、MyISAM 金鑰快取和 MySQL 查詢快取。

另請參閱 ACID、自適性雜湊索引、緩衝池、磁碟式、唯讀交易。

由 MySQL Enterprise Backup 產品執行的一種熱備份，僅儲存自某個時間點以來變更的資料。擁有完整備份和一系列增量備份可讓您在較長的時間內重建備份資料，而不會產生手邊保留多個完整備份的儲存額外負荷。您可以還原完整備份，然後依序套用每個增量備份，或者您可以透過將每個增量備份套用至完整備份來保持其為最新狀態，然後執行單一還原操作。

變更資料的細微度是在頁面層級。一個頁面實際上可能涵蓋多個資料列。每個變更的頁面都會包含在備份中。

另請參閱 熱備份、MySQL Enterprise Backup、頁面。

一種資料結構，可為表格的資料列提供快速查閱功能，通常透過形成樹狀結構 (B 樹) 來表示特定欄或一組欄的所有值。

InnoDB 表格一律具有代表主鍵的叢集索引。它們也可以有一個或多個在一個或多個欄上定義的次要索引。根據其結構，次要索引可以分類為部分、欄或複合索引。

索引是查詢效能的關鍵要素。資料庫架構師設計表格、查詢和索引，以便能夠快速查閱應用程式所需的資料。理想的資料庫設計在可行時使用涵蓋索引；查詢結果完全從索引計算得出，而無需讀取實際表格資料。每個外鍵約束也需要一個索引，以有效檢查父表格和子表格中是否存在值。

雖然 B 樹索引是最常見的，但另一種資料結構用於雜湊索引，如在 MEMORY 儲存引擎和 InnoDB 自適性雜湊索引中。 R 樹索引用於多維資訊的空間索引。

另請參閱 自適性雜湊索引、B 樹、子表格、叢集索引、欄索引、複合索引、涵蓋索引、外鍵、雜湊索引、父表格、部分索引、主鍵、查詢、R 樹、資料列、次要索引、表格。

一個記憶體區域，用於儲存 InnoDB 全文搜尋的符記資料。它會緩衝資料，以在插入或更新屬於全文索引一部分的欄中的資料時，盡量減少磁碟 I/O。當索引快取已滿時，符記資料會寫入磁碟。每個 InnoDB FULLTEXT 索引都有自己的單獨索引快取，其大小由設定選項 innodb_ft_cache_size 控制。

另請參閱 全文搜尋、全文索引。

索引條件下推（Index Condition Pushdown，ICP）是一種最佳化技術，它會將 WHERE 條件的部分下推至儲存引擎，如果條件的某些部分可以使用索引中的欄位進行評估。 ICP 可以減少儲存引擎必須存取基底資料表的次數，以及 MySQL 伺服器必須存取儲存引擎的次數。如需更多資訊，請參閱第 10.2.1.6 節「索引條件下推最佳化」。

另請參閱 index（索引）、storage engine（儲存引擎）。

擴展的 SQL 語法，用於覆寫最佳化工具建議的索引。例如，FORCE INDEX、USE INDEX 和 IGNORE INDEX 子句。通常在索引的欄位值分佈不均勻，導致基數 (cardinality)估計不準確時使用。

另請參閱 cardinality（基數）、index（索引）。

在適用於多個欄位的索引（稱為複合索引）中，索引的初始或前導欄位。 即使查詢未參考索引中的所有欄位，參考複合索引的前 1、2、3 等欄位的查詢也可以使用該索引。

另請參閱 複合索引 (composite index)、 索引 (index)。

索引中的虛擬記錄，代表該索引中最小值以下的間隙。如果交易執行類似 SELECT ... FROM ... WHERE col < 10 FOR UPDATE; 的語句，且該欄位中的最小值為 5，則對下限記錄的鎖定可防止其他交易插入更小的值，例如 0、-10 等。

另請參閱 gap（間隙）、index（索引）、pseudo-record（虛擬記錄）、supremum record（上限記錄）。

提供 MySQL 資料字典查詢介面的資料庫名稱。（此名稱由 ANSI SQL 標準定義。）要檢查有關資料庫的資訊（中繼資料），您可以查詢 INFORMATION_SCHEMA.TABLES 和 INFORMATION_SCHEMA.COLUMNS 等表格，而不是使用產生非結構化輸出的 SHOW 命令。

INFORMATION_SCHEMA 資料庫也包含特定於 InnoDB 的表格，這些表格提供了 InnoDB 資料字典的查詢介面。您可以使用這些表格來取得關於 InnoDB 資料表運作的即時資訊，而不是查看資料庫的結構，以協助進行效能監控、調整和疑難排解。

另請參閱 data dictionary（資料字典）、database（資料庫）、InnoDB。

一種 MySQL 元件，它結合了高效能和交易功能，以實現可靠性、穩健性和並行存取。它體現了 ACID 設計理念。以儲存引擎的形式呈現；它處理使用 ENGINE=INNODB 子句建立或變更的資料表。 有關架構詳細資訊和管理程序，請參閱第 17 章「InnoDB 儲存引擎」，有關效能建議，請參閱第 10.5 節「最佳化 InnoDB 資料表」。

在 MySQL 5.5 及更高版本中，InnoDB 是新資料表的預設儲存引擎，並且不需要 ENGINE=INNODB 子句。

InnoDB 資料表非常適合用於熱備份。 有關MySQL Enterprise Backup產品的資訊，請參閱第 32.1 節「MySQL Enterprise Backup 概觀」，該產品用於備份 MySQL 伺服器而不會中斷正常處理。

另請參閱 ACID、hot backup（熱備份）、MySQL Enterprise Backup、storage engine（儲存引擎）、transaction（交易）。

innodb_autoinc_lock_mode 選項控制用於自動遞增鎖定的演算法。 當您具有自動遞增的主索引鍵時，只能將innodb_autoinc_lock_mode=1設定用於以陳述式為基礎的複寫。此設定稱為連續鎖定模式，因為交易內的多列插入會接收連續的自動遞增值。 如果您具有 innodb_autoinc_lock_mode=2，這允許更高的插入作業並行性，請使用以列為基礎的複寫，而不是以陳述式為基礎的複寫。此設定稱為交錯鎖定模式，因為同時執行的多個多列插入陳述式可以接收自動遞增的交錯值。innodb_autoinc_lock_mode=0 設定僅應用於相容性目的，不應使用。

連續鎖定模式 (innodb_autoinc_lock_mode=1) 是 MySQL 8.0.3 之前的預設設定。從 MySQL 8.0.3 開始，交錯鎖定模式 (innodb_autoinc_lock_mode=2) 是預設值，這反映了從基於語句的複寫變更為基於列的複寫作為預設複寫類型。

另請參閱 auto-increment（自動遞增）、auto-increment locking（自動遞增鎖定）、mixed-mode insert（混合模式插入）、primary key（主索引鍵）。

一個重要的組態選項，會影響 InnoDB 檔案儲存、功能可用性和 I/O 特性的許多方面。 在 MySQL 5.6.7 及更高版本中，預設啟用此選項。innodb_file_per_table 選項會開啟每個資料表一個檔案模式。啟用此模式後，新建立的 InnoDB 資料表和相關索引可以儲存在.ibd 檔案（每個資料表一個檔案）中，位於系統資料表空間之外。

此選項會影響許多 SQL 陳述式的效能和儲存考量，例如DROP TABLE 和 TRUNCATE TABLE。

啟用 innodb_file_per_table 選項可讓您利用某些功能，例如在MySQL Enterprise Backup 中的資料表壓縮和已命名資料表備份。

如需更多資訊，請參閱 innodb_file_per_table 和 第 17.6.3.2 節「每個資料表一個檔案的資料表空間」。

另請參閱 compression（壓縮）、file-per-table（每個資料表一個檔案）、.ibd file（.ibd 檔案）、MySQL Enterprise Backup、system tablespace（系統資料表空間）。

innodb_lock_wait_timeout 選項設定在等待共用資源可供使用，或放棄並處理錯誤、重試或在您的應用程式中進行替代處理之間取得平衡。 會回溯任何等待超過指定時間才能取得鎖定的 InnoDB 交易。 如果由不同儲存引擎控制的多個資料表更新導致死鎖，則尤其有用；此類死鎖不會自動偵測到。

另請參閱 deadlock（死鎖）、deadlock detection（死鎖偵測）、lock（鎖定）、wait（等待）。

innodb_strict_mode 選項控制 InnoDB 是否在嚴格模式下運作，在嚴格模式下，通常被視為警告的情況會導致錯誤（且基礎陳述式會失敗）。

另請參閱 strict mode（嚴格模式）。

具有相同主要版本的創新版本構成一個創新系列。 例如，MySQL 8.1 到 8.3 構成 MySQL 8 創新系列。

另請參閱 LTS Series（LTS 系列）。

SQL 中的主要 DML 作業之一。插入的效能是將數百萬列載入資料表的資料倉儲系統的關鍵因素，也是許多並行連線可能以任意順序將列插入同一資料表的 OLTP 系統的關鍵因素。 如果插入效能對您很重要，您應該了解 InnoDB 的功能，例如用於變更緩衝的插入緩衝區和自動遞增欄位。

另請參閱 auto-increment（自動遞增）、change buffering（變更緩衝）、data warehouse（資料倉儲）、DML、InnoDB、insert buffer（插入緩衝區）、OLTP、SQL。

變更緩衝區的舊名稱。 在 MySQL 5.5 中，新增了對 DELETE 和 UPDATE 作業的次要索引頁面變更進行緩衝的支援。 先前，僅對 INSERT 作業產生的變更進行緩衝。 現在的首選術語是變更緩衝區。

另請參閱 change buffer（變更緩衝區）、change buffering（變更緩衝）。

將 INSERT 操作導致的次要索引頁面變更，儲存在變更緩衝區中，而不是立即寫入變更，以便執行實體寫入以最小化隨機 I/O 的技術。它是變更緩衝的其中一種；其他種類有刪除緩衝和清除緩衝。

如果次要索引是唯一的，則不使用插入緩衝，因為在寫出新條目之前無法驗證新值的唯一性。其他種類的變更緩衝適用於唯一索引。

另請參閱 變更緩衝區、變更緩衝、刪除緩衝、插入緩衝區、清除緩衝、唯一索引。

一種間隙鎖定，由INSERT 操作在插入列之前設定。這種類型的鎖定表示在間隙中插入的意圖，如果多個交易並非在間隙中的同一位置插入，則它們不必互相等待。如需更多資訊，請參閱 第 17.7.1 節，「InnoDB 鎖定」。

另請參閱 間隙鎖定、鎖定、下一個鍵鎖定。

單一 mysqld 精靈管理一個資料目錄，該目錄代表一個或多個資料庫和一組表格。在開發、測試和某些複寫情境中，常見於在同一伺服器機器上有多個實例，每個實例管理自己的資料目錄並監聽自己的連接埠或通訊端。在一個實例執行磁碟限制工作負載時，伺服器可能仍有額外的 CPU 和記憶體容量來執行其他實例。

另請參閱 資料目錄、資料庫、磁碟限制、mysqld、複寫、伺服器、表格。

在原始碼層級進行修改以收集效能資料，用於調整和偵錯。在 MySQL 中，檢測收集的資料會透過使用 INFORMATION_SCHEMA 和 PERFORMANCE_SCHEMA 資料庫的 SQL 介面公開。

另請參閱 INFORMATION_SCHEMA、效能結構描述。

一種適用於表格的鎖定，用於指示交易打算在表格中的列上取得的鎖定種類。不同的交易可以在同一個表格上取得不同種類的意向鎖定，但第一個在表格上取得意向獨佔 (IX) 鎖定的交易，會阻止其他交易在表格上取得任何 S 或 X 鎖定。相反地，第一個在表格上取得意向共用 (IS) 鎖定的交易，會阻止其他交易在表格上取得任何 X 鎖定。雙階段程序允許依序解決鎖定請求，而不會封鎖相容的鎖定和對應的作業。如需關於此鎖定機制的更多資訊，請參閱 第 17.7.1 節，「InnoDB 鎖定」。

另請參閱 鎖定、鎖定模式、鎖定、交易。

用於檢測或偵錯應用程式某些方面的程式碼，無需重新編譯或變更應用程式本身的來源即可啟用。

另請參閱 命令攔截器、Connector/J、Connector/NET、例外狀況攔截器。

由最佳化工具使用的最佳化內部 InnoDB 暫時表格。

另請參閱 最佳化工具。

一種針對文件檢索系統進行最佳化的資料結構，用於實作 InnoDB 全文檢索。InnoDB FULLTEXT 索引會實作為反向索引，並記錄文件中每個字詞的位置，而不是表格列的位置。單一資料行值 (儲存為文字字串的文件) 由反向索引中的多個條目表示。

另請參閱 全文檢索、FULLTEXT 索引、ilist。

每秒 I/O 作業次數的縮寫。忙碌系統，特別是OLTP應用程式的常見測量。如果此值接近儲存裝置可處理的最大值，則應用程式可能會變成磁碟限制，這會限制擴充性。

另請參閱 磁碟限制、OLTP、擴充性。

資料庫處理的基礎之一。隔離是 ACID 縮寫中的 I；隔離層級是一個設定，可微調當多個交易同時進行變更和執行查詢時，效能與可靠性、一致性和結果重現性之間的平衡。

從最高的一致性和保護到最低的一致性和保護，InnoDB 支援的隔離層級為：SERIALIZABLE、REPEATABLE READ、READ COMMITTED 和 READ UNCOMMITTED。

使用 InnoDB 表格時，許多使用者可以對所有作業保留預設隔離層級 (REPEATABLE READ)。專家使用者可能會選擇 READ COMMITTED 層級，因為他們使用 OLTP 處理推動擴充性的界限，或者在資料倉儲作業期間，輕微的不一致性不會影響大量資料的彙總結果。邊緣層級 (SERIALIZABLE 和 READ UNCOMMITTED) 會大幅變更處理行為，因此很少使用。

另請參閱 ACID、OLTP、READ COMMITTED、READ UNCOMMITTED、REPEATABLE READ、SERIALIZABLE、交易。

Java Platform, Enterprise Edition：Oracle 的企業 Java 平台。它由企業級 Java 應用程式的 API 和執行階段環境組成。如需完整詳細資訊，請參閱 http://www.oracle.com/technetwork/java/javaee/overview/index.html。對於 MySQL 應用程式，您通常會使用 Connector/J 進行資料庫存取，並使用應用程式伺服器 (例如 Tomcat 或 JBoss) 來處理中介層工作，並可選用 Spring 之類的架構。J2EE 堆疊中經常提供的資料庫相關功能包括連線集區和容錯移轉支援。

另請參閱 連線集區、Connector/J、容錯移轉、Java、JBoss、Spring、Tomcat。

一種程式語言，結合了高效能、豐富的內建功能和資料類型、物件導向機制、廣泛的標準程式庫和各種可重複使用的第三方模組。許多架構、應用程式伺服器和其他技術都支援企業開發。其大部分語法都與 C 和 C++ 開發人員熟悉。若要使用 MySQL 撰寫 Java 應用程式，您會使用稱為 Connector/J 的 JDBC 驅動程式。

另請參閱 C、Connector/J、C++、JDBC。

參見 J2EE。

「Java Database Connectivity」 的縮寫，這是一種適用於 Java 應用程式進行資料庫存取的 API。撰寫 MySQL 應用程式的 Java 開發人員會使用 Connector/J 元件作為其 JDBC 驅動程式。

另請參閱 API、Connector/J、J2EE、Java。

另請參閱 Java。

一個查詢 (query)，透過參照表格中具有相同值的欄位，從多個表格中擷取資料。理想情況下，這些欄位是 InnoDB 外鍵 (foreign key) 關係的一部分，以確保參考完整性 (referential integrity)，並且聯結欄位具有索引 (indexed)。通常用於在正規化 (normalized)的資料設計中，透過將重複的字串替換為數字 ID 來節省空間並提高查詢效能。

另請參閱 外鍵 (foreign key)、索引 (index)、正規化 (normalized)、查詢 (query)、參考完整性 (referential integrity)。

在 Kerberos 中，金鑰分發中心包含身份驗證伺服器 (AS) 和票證授予伺服器 (TGS)。

另請參閱 身份驗證伺服器 (authentication server)、票證授予票證 (ticket-granting ticket)。

另請參閱 SSL。

一個選項，用於指定使用壓縮列格式 (compressed row format)的 InnoDB 資料表中的資料頁大小。預設值為 8 KB。較低的值可能會遇到內部限制，該限制取決於列大小和壓縮百分比的組合。

對於 MyISAM 資料表，KEY_BLOCK_SIZE 可選地指定用於索引金鑰區塊的大小（以位元組為單位）。該值被視為提示；如有必要，可以使用不同的大小。為個別索引定義指定的 KEY_BLOCK_SIZE 值會覆蓋資料表層級的 KEY_BLOCK_SIZE 值。

另請參閱 壓縮列格式 (compressed row format)。

InnoDB 用於為其內部記憶體結構實作鎖定 (lock)的輕量級結構，通常以毫秒或微秒為單位短暫持有。一個通用術語，包括互斥鎖 (mutexes) (用於獨佔存取) 和讀寫鎖 (rw-locks) (用於共享存取)。某些閂鎖是 InnoDB 效能調校的重點。效能架構 (Performance Schema)介面可提供有關閂鎖使用和爭用的統計資料。

另請參閱 鎖定 (lock)、鎖定 (locking)、互斥鎖 (mutex)、效能架構 (Performance Schema)、讀寫鎖 (rw-lock)。

libmysqlclient 程式庫的非正式名稱。

另請參閱 libmysqlclient。

程式庫檔案，名為 libmysqlclient.a 或 libmysqlclient.so，通常會連結到以 C 編寫的用戶端 (client)程式中。 有時非正式地稱為libmysql 或 mysqlclient 程式庫。

另請參閱 用戶端 (client)、libmysql、mysqlclient。

這個嵌入式 (embedded) MySQL 伺服器程式庫可讓您在用戶端 (client)應用程式內執行功能齊全的 MySQL 伺服器。主要優點是提高嵌入式應用程式的速度和簡化管理。您會連結 libmysqld 程式庫，而不是 libmysqlclient。所有這三個程式庫之間的 API 是相同的。

另請參閱 用戶端 (client)、嵌入式 (embedded)、libmysql、libmysqlclient。

一種由 Connector/J 支援的攔截器 (interceptor)類型。它涉及實作介面 com.mysql.jdbc.ConnectionLifecycleInterceptor。

另請參閱 Connector/J、攔截器 (interceptor)。

InnoDB 緩衝池 (buffer pool)表示為記憶體頁面 (pages)的列表。當存取新頁面並進入緩衝池時、當再次存取緩衝池內的頁面並將其視為較新時，以及當長時間未存取的頁面從緩衝池中逐出 (evicted)時，會重新排序該列表。緩衝池分為子列表 (sublists)，替換策略是熟悉的LRU技術的變體。

另請參閱 緩衝池 (buffer pool)、逐出 (eviction)、LRU、頁面 (page)、子列表 (sublist)。

一種用於透過將查詢請求傳送到複寫或叢集組態中的不同從屬伺服器來調整唯讀連線的技術。使用 Connector/J，透過 com.mysql.jdbc.ReplicationDriver 類別啟用負載平衡，並由組態屬性 loadBalanceStrategy 控制。

參閱 Connector/J、J2EE。

另請參閱 連線 (connection)。

一個高階概念，指的是一個控制對資源（例如資料表、列或內部資料結構）的存取的物件，作為鎖定 (locking)策略的一部分。對於密集的效能調校，您可能會深入研究實作鎖定的實際結構，例如互斥鎖 (mutexes)和閂鎖 (latches)。

另請參閱 閂鎖 (latch)、鎖定模式 (lock mode)、鎖定 (locking)、互斥鎖 (mutex)。

某些資料庫系統中使用的一種操作，會將許多列鎖定 (row locks)轉換為單一資料表鎖定 (table lock)，從而節省記憶體空間，但會減少對資料表的並行存取。InnoDB 對於列鎖定使用節省空間的表示法，因此不需要鎖定 (lock)升級。

另請參閱 鎖定 (locking)、列鎖定 (row lock)、資料表鎖定 (table lock)。

共享 (S) 鎖定 (lock)允許交易 (transaction)讀取列。多個交易可以同時在同一列上取得 S 鎖定。

獨佔 (X) 鎖定允許交易更新或刪除列。沒有其他交易可以同時在同一列上取得任何類型的鎖定。

意圖鎖定 (intention locks)適用於資料表，用於指示交易打算在資料表中的列上取得哪種類型的鎖定。不同的交易可以在同一資料表上取得不同類型的意圖鎖定，但是第一個在資料表上取得意圖獨佔 (IX) 鎖定的交易會阻止其他交易在資料表上取得任何 S 或 X 鎖定。相反地，第一個在資料表上取得意圖共享 (IS) 鎖定的交易會阻止其他交易在資料表上取得任何 X 鎖定。雙階段程序允許依序解析鎖定請求，而不會封鎖相容的鎖定和對應的操作。

另請參閱 意圖鎖定 (intention lock)、鎖定 (lock)、鎖定 (locking)、交易 (transaction)。

保護交易 (transaction)不查看或變更正在被其他交易查詢或變更的資料的系統。 鎖定 (locking)策略必須在資料庫操作的可靠性和一致性（ACID 原則）與良好並行性 (concurrency)所需的效能之間取得平衡。 微調鎖定策略通常涉及選擇隔離層級 (isolation level)，並確保您的所有資料庫操作對於該隔離層級都是安全且可靠的。

另請參閱 ACID、並行性 (concurrency)、隔離層級 (isolation level)、鎖定 (locking)、交易 (transaction)。

一個也對 InnoDB 資料表執行鎖定 (locking)操作的 SELECT 陳述式。使用 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE。它有可能產生死鎖 (deadlock)，具體取決於交易的隔離層級 (isolation level)。與非鎖定讀取 (non-locking read)相反。不允許用於唯讀交易 (read-only transaction)中的全域資料表。

SELECT ... FOR SHARE 在 MySQL 8.0.1 中取代 SELECT ... LOCK IN SHARE MODE，但 LOCK IN SHARE MODE 仍可向後相容。

請參閱 第 17.7.2.4 節， 「鎖定讀取」。

另請參閱 死鎖 (deadlock)、隔離層級 (isolation level)、鎖定 (locking)、非鎖定讀取 (non-locking read)、唯讀交易 (read-only transaction)。

在 InnoDB 環境中，「日誌」或「日誌檔案」通常指的是由 ib_logfileN 檔案表示的重做日誌。另一種 InnoDB 日誌是還原日誌，它是一個儲存區域，用於保存活動交易修改的資料副本。

在 MySQL 中，其他重要的日誌類型包括錯誤日誌 (用於診斷啟動和執行時問題)、二進位日誌 (用於處理複寫和執行時間點還原)、一般查詢日誌 (用於診斷應用程式問題) 和慢查詢日誌 (用於診斷效能問題)。

另請參閱 二進位日誌、錯誤日誌、一般查詢日誌、ib_logfile、重做日誌、慢查詢日誌、還原日誌。

記憶體區域，用於保存要寫入組成重做日誌的日誌檔案的資料。它由 innodb_log_buffer_size 設定選項控制。

另請參閱 日誌檔案、重做日誌。

組成重做日誌的ib_logfileN 檔案之一。資料從日誌緩衝區記憶體區域寫入這些檔案。

另請參閱 ib_logfile、日誌緩衝區、重做日誌。

組成重做日誌的檔案集合，通常命名為 ib_logfile0 和 ib_logfile1。(因此，有時統稱為 ib_logfile。)

另請參閱 ib_logfile、重做日誌。

一種涉及高階、抽象方面的操作類型，例如表格、查詢、索引和其他 SQL 概念。通常，邏輯方面對於方便和可用資料庫管理和應用程式開發至關重要。與實體 (physical)相對。

另請參閱 邏輯備份、實體。

一種備份，可以重現表格結構和資料，而無需複製實際資料檔案。例如，mysqldump 命令會產生邏輯備份，因為它的輸出包含諸如 CREATE TABLE 和 INSERT 之類的語句，這些語句可以重新建立資料。與實體備份 (physical backup)相對。邏輯備份具有彈性 (例如，您可以在還原之前編輯表格定義或插入語句)，但還原 (restore)所需的時間可能比實體備份長得多。

另請參閱 備份、mysqldump、實體備份、還原。

在伺服器啟動 (startup)後新增至 InnoDB 設定選項的前綴，因此目前 MySQL 層級無法辨識的任何新設定選項都不會導致啟動失敗。MySQL 處理以這個前綴開頭的設定選項，但如果前綴後面的部分不是可辨識的選項，則會發出警告而不是失敗。

另請參閱 啟動。

代表下限的值，通常是開始或變得更積極地執行某些修正措施的臨界值。與高水位線 (high-water mark)相對。

另請參閱 高水位線。

「最近最少使用 (least recently used)」的縮寫，這是一種常見的儲存區域管理方法。當需要空間來快取較新的項目時，最近未使用的項目會被逐出 (evicted)。InnoDB 預設會使用 LRU 機制來管理緩衝池 (buffer pool)內的頁面 (pages)，但在某些情況下會例外，例如在完整表格掃描 (full table scan)期間可能只會讀取一次頁面。LRU 演算法的這種變體稱為中點插入策略 (midpoint insertion strategy)。如需詳細資訊，請參閱 第 17.5.1 節「緩衝池」。

另請參閱 緩衝池、逐出、完整表格掃描、中點插入策略、頁面。

「日誌序列號碼 (log sequence number)」的縮寫。這個任意、不斷增加的值代表重做日誌中記錄的操作所對應的時間點。(這個時間點與交易 (transaction)邊界無關；它可能會落在一個或多個交易的中間。) 它由 InnoDB 在當機復原 (crash recovery)期間和用於管理緩衝池時在內部使用。

在 MySQL 5.6.3 之前，LSN 是 4 位元組的無號整數。當重做日誌檔案大小限制從 4GB 增加到 512GB 時，LSN 在 MySQL 5.6.3 中變成了 8 位元組的無號整數，因為需要額外的位元組來儲存額外的大小資訊。在 MySQL 5.6.3 或更高版本上建立的應用程式，如果使用 LSN 值，應使用 64 位元而不是 32 位元變數來儲存和比較 LSN 值。

在 MySQL Enterprise Backup 產品中，您可以指定一個 LSN，以代表從中進行增量備份 (incremental backup)的時間點。相關的 LSN 會顯示在 mysqlbackup 命令的輸出中。一旦您擁有與完整備份時間對應的 LSN，您就可以指定該值來進行後續的增量備份，其輸出包含另一個 LSN，用於下一個增量備份。

另請參閱 緩衝池、當機復原、增量備份、MySQL Enterprise Backup、重做日誌、交易。

具有相同主要版本號碼的 LTS 版本組成一個 LTS 系列。例如，所有 MySQL 8.4.x 版本構成 MySQL 8.4 LTS 系列。

注意：MySQL 8.0 是錯誤修正系列，它早於 LTS 發行模型。

另請參閱 創新系列 (Innovation Series)。

包含對其他表格的參照，由 MERGE 儲存引擎使用的檔案。具有此副檔名的檔案始終包含在 MySQL Enterprise Backup 產品的 mysqlbackup 命令產生的備份中。

另請參閱 MySQL Enterprise Backup、mysqlbackup 命令。

MySQL 用於儲存 MyISAM 表格資料的檔案。

另請參閱 .MYI 檔案、MySQL Enterprise Backup、mysqlbackup 命令。

MySQL 用於儲存 MyISAM 表格索引的檔案。

另請參閱 .MYD 檔案、MySQL Enterprise Backup、mysqlbackup 命令。

一個 InnoDB 執行緒 (thread)，可在背景中執行各種任務。其中大多數任務與 I/O 相關，例如將 變更緩衝區 (change buffer) 中的變更寫入適當的次要索引。

為了提高並行性 (concurrency)，有時會將動作從主執行緒移到單獨的背景執行緒。例如，在 MySQL 5.6 和更高版本中，髒頁 (dirty pages) 由頁面清理器 (page cleaner)執行緒從緩衝池中刷新 (flushed)，而不是由主執行緒。

另請參閱 緩衝池（buffer pool）、變更緩衝區（change buffer）、並行（concurrency）、髒頁（dirty page）、刷新（flush）、頁面清理器（page cleaner）、執行緒（thread）。

「metadata lock（中繼資料鎖定）」的縮寫。

另請參閱 中繼資料鎖定（metadata lock）。

與部分信任（partial trust）同義。由於信任設定的範圍非常廣泛，因此偏好使用「部分信任（partial trust）」，以避免暗示只有三個等級（低、中和完整）。

另請參閱 Connector/NET、部分信任（partial trust）。

許多 MySQL 和 NoSQL 軟體堆疊中常見的元件，允許快速讀寫單一值，並將結果完全快取在記憶體中。傳統上，應用程式需要額外的邏輯將相同的資料寫入 MySQL 資料庫以進行永久儲存，或在記憶體中尚未快取資料時，從 MySQL 資料庫讀取資料。現在，應用程式可以使用簡單的 memcached 通訊協定（許多語言的用戶端函式庫都支援此協定），使用 NDB 資料表直接與 MySQL 伺服器通訊。這些 MySQL 資料表的 NoSQL 介面允許應用程式實現比直接發出 SQL 陳述式更高的讀寫效能，並且可以簡化已納入 memcached 進行記憶體快取的系統之應用程式邏輯和部署組態。

另請參閱 NoSQL。

將變更套用至快取在記憶體中的資料，例如當頁面載入緩衝池（buffer pool）時，以及將記錄在變更緩衝區（change buffer）中的任何適用變更併入緩衝池中的頁面。更新後的資料最終會由刷新（flush）機制寫入表空間（tablespace）。

另請參閱 緩衝池（buffer pool）、變更緩衝區（change buffer）、刷新（flush）、表空間（tablespace）。

一種鎖定（lock）類型，可防止在另一個交易（transaction）同時使用的資料表上執行DDL作業。如需詳細資訊，請參閱第 10.11.4 節〈中繼資料鎖定〉。

對線上（online）作業的增強功能（尤其是在 MySQL 5.6 和更高版本中）著重於減少中繼資料鎖定的數量。目標是讓不會變更資料表結構的 DDL 作業（例如 CREATE INDEX 和 DROP INDEX，適用於 InnoDB 資料表）在其他交易查詢、更新資料表時繼續進行。

另請參閱 DDL、鎖定（lock）、線上（online）、交易（transaction）。

由 MySQL 5.6 和更高版本中的 INFORMATION_SCHEMA 中的 INNODB_METRICS 資料表實作的功能。您可以查詢低階 InnoDB 作業的計數（counts）和總計，並將結果與效能架構（Performance Schema）的資料結合使用，以進行效能調整。

另請參閱 計數器（counter）、INFORMATION_SCHEMA、效能架構（Performance Schema）。

最初將頁面（pages）載入 InnoDB 緩衝池（buffer pool）的技術，不是在清單的「最新」端，而是在中間的某個位置。此點的確切位置可能會根據 innodb_old_blocks_pct 選項的設定而有所不同。其用意是，僅讀取一次的頁面（例如在全表掃描（full table scan）期間），可以比使用嚴格的LRU演算法更快地從緩衝池中淘汰。如需更多資訊，請參閱第 17.5.1 節〈緩衝池〉。

另請參閱 緩衝池（buffer pool）、全表掃描（full table scan）、LRU、頁面（page）。

在DML作業期間，以實體（physical）層級變更內部資料結構時，InnoDB 處理的內部階段。迷你交易（mtr）沒有回滾（rollback）的概念；單一交易（transaction）中可能發生多個迷你交易。迷你交易會將資訊寫入重做記錄（redo log），該記錄會在當機復原（crash recovery）期間使用。迷你交易也可能發生在常規交易的內容之外，例如在背景執行緒執行清除（purge）處理期間。

另請參閱 提交（commit）、當機復原（crash recovery）、DML、實體（physical）、清除（purge）、重做記錄（redo log）、回滾（rollback）、交易（transaction）。

INSERT 陳述式，其中為某些（但不是全部）新列指定自動遞增（auto-increment）值。例如，多值 INSERT 可能會在某些情況下為自動遞增欄指定值，而在其他情況下指定 NULL。InnoDB 會為欄值指定為 NULL 的列產生自動遞增值。另一個範例是 INSERT ... ON DUPLICATE KEY UPDATE 陳述式，其中可能會產生自動遞增值但不會使用，適用於任何作為 UPDATE 而不是 INSERT 陳述式處理的重複列。

可能會在來源（source）和複本（replica）伺服器之間導致複寫（replication）組態中的一致性問題。可能需要調整 innodb_autoinc_lock_mode 組態選項的值。

另請參閱 自動遞增（auto-increment）、innodb_autoinc_lock_mode、複本（replica）、複寫（replication）、來源（source）。

較舊的 MySQL JDBC 驅動程式，與 MySQL 產品整合後演變為 Connector/J。

另請參閱 Connector/J。

Novell 開發的開放原始碼架構，可在 Linux 平台上與 Connector/NET 和 C# 應用程式搭配使用。

另請參閱 Connector/NET、C#。

可以利用多執行緒程式（例如 MySQL 伺服器）的處理器類型。

「互斥變數（mutex variable）」的非正式縮寫。（互斥本身是 「互斥（mutual exclusion）」的縮寫。）InnoDB 用來表示和強制內部記憶體資料結構的獨佔存取鎖定（locks）的低階物件。取得鎖定後，任何其他程序、執行緒等都無法取得相同的鎖定。與 InnoDB 用來表示和強制內部記憶體資料結構的共用存取鎖定（locks）的 rw-locks 形成對比。互斥和 rw-locks 統稱為鎖存器（latches）。

另請參閱 鎖存器（latch）、鎖定（lock）、效能架構（Performance Schema）、Pthreads、rw-lock。

「多版本並行控制」（multiversion concurrency control）的縮寫。此技術讓 InnoDB 在某些隔離等級下，交易執行一致性讀取操作；也就是說，查詢正在被其他交易更新的資料列時，可以看到更新發生前的數值。這項強大的技術藉由允許查詢繼續執行而無需等待其他交易持有的鎖定，來提高並行性。

此技術在資料庫領域並非通用。某些其他資料庫產品，以及某些其他的 MySQL 儲存引擎，並不支援此技術。

另請參閱 ACID、並行性、一致性讀取、隔離等級、鎖定、交易。

在 Unix 或 Linux 系統上，MySQL 選項檔案的名稱。

另請參閱 my.ini、選項檔案。

在 Windows 系統上，MySQL 選項檔案的名稱。

另請參閱 my.cnf、選項檔案。

Connector/ODBC 的過時名稱。

另請參閱 Connector/ODBC。

mysql 程式是 MySQL 資料庫的命令列解譯器。它會處理 SQL 陳述式，以及 MySQL 特有的命令，例如 SHOW TABLES，方法是將請求傳遞至 mysqld 精靈程式。

另請參閱 mysqld、SQL。

執行 MySQL 資料庫熱備份的授權產品。在備份 InnoDB 資料表時，它提供最高的效率和彈性，但也可以備份 MyISAM 和其他類型的資料表。

另請參閱 熱備份、InnoDB。

MySQL Enterprise Backup 產品的命令列工具。它會針對 InnoDB 資料表執行熱備份操作，並針對 MyISAM 和其他類型的資料表執行暖備份。如需此命令的詳細資訊，請參閱第 32.1 節「MySQL Enterprise Backup 概述」。

另請參閱 熱備份、MySQL Enterprise Backup、暖備份。

由檔案 libmysqlclient 實作的程式庫的非正式名稱，其副檔名為 .a 或 .so。

另請參閱 libmysqlclient。

mysqld，又稱 MySQL 伺服器，是單一的多執行緒程式，在 MySQL 安裝中執行大部分的工作。它不會產生其他處理序。MySQL 伺服器會管理對 MySQL 資料目錄的存取，其中包含資料庫、資料表，以及其他資訊，例如記錄檔和狀態檔。

mysqld 以 Unix 精靈程式或 Windows 服務的形式執行，不斷等待請求並在背景執行維護工作。

另請參閱 執行個體、mysql。

構成 MySQL Python API 基礎的開放原始碼 Python 模組名稱。

另請參閱 Python、Python API。

執行資料庫、資料表和資料表資料的某種組合邏輯備份的命令。結果是重現原始結構描述物件、資料或兩者的 SQL 陳述式。對於大量資料，MySQL Enterprise Backup 等實體備份解決方案速度更快，尤其是還原操作。

另請參閱 邏輯備份、MySQL Enterprise Backup、實體備份、還原。

另請參閱 ADO.NET、ASP.net、Connector/NET、Mono、Visual Studio。

libmysqlclient 的同義詞。

另請參閱 libmysql。

已編製索引的資料行，通常是主索引鍵，其值具有某些現實意義。通常不建議使用，因為

因此，通常最好使用任意數值來形成合成鍵，例如使用自動遞增資料行。

另請參閱 自動遞增、叢集索引、主索引鍵、次要索引、合成鍵。

與特定頁面位於相同區段中的任何頁面。當選取要清除的頁面時，通常也會清除任何已變更的相鄰頁面，作為傳統硬碟的 I/O 優化。在 MySQL 5.6 及更新版本中，此行為可由組態變數 innodb_flush_neighbors 控制；您可以針對 SSD 硬碟關閉該設定，因為它們在隨機位置寫入較小批次的資料時，沒有相同的額外負荷。

另請參閱 已變更頁面、區段、清除、頁面。

索引記錄上的記錄鎖定和索引記錄之前間隙上的間隙鎖定的組合。

另請參閱 間隙鎖定、鎖定、記錄鎖定。

未使用 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 子句的查詢。唯讀交易中允許用於全域資料表的唯一查詢類型。與鎖定讀取相反。請參閱第 17.7.2.3 節「一致性非鎖定讀取」。

SELECT ... FOR SHARE 在 MySQL 8.0.1 中取代 SELECT ... LOCK IN SHARE MODE，但 LOCK IN SHARE MODE 仍可向後相容。

另請參閱 鎖定讀取、查詢、唯讀交易。

當查詢擷取資料，且相同交易中的後續查詢擷取應該是相同的資料，但查詢傳回不同的結果（同時由另一個交易認可變更）時的情況。

這種操作違反資料庫設計的 ACID 原則。在交易中，資料應該一致，且具有可預測和穩定的關係。

在不同的隔離等級中，可序列化讀取和可重複讀取等級會防止不可重複讀取，而一致性讀取和讀取未認可等級則允許不可重複讀取。

另請參閱 ACID、一致性讀取、隔離等級、READ UNCOMMITTED、REPEATABLE READ、SERIALIZABLE、交易。

與非同步 I/O 相同的業界術語。

另請參閱 非同步 I/O。

一種資料庫設計策略，將資料分割成多個表格，並將重複的值濃縮成以 ID 表示的單一行，以避免儲存、查詢和更新冗餘或冗長的值。它通常用於 OLTP 應用程式中。

例如，地址可能會被賦予一個唯一的 ID，這樣人口普查資料庫就可以透過將該 ID 與每個家庭成員關聯，來表示居住在這個地址的關係，而不是儲存多個複雜的值副本，例如 美國 Anytown 市 Main Street 123 號。

另一個例子是，雖然簡單的通訊錄應用程式可能會將每個電話號碼與人員的姓名和地址儲存在同一個表格中，但電話公司資料庫可能會為每個電話號碼賦予一個特殊的 ID，並將號碼和 ID 儲存在單獨的表格中。當區碼被拆分時，這種正規化的表示方式可以簡化大規模的更新。

正規化並非總是建議的做法。主要用於查詢，且僅透過完全刪除和重新載入來更新的資料，通常會保留在較少、較大的表格中，並帶有重複值的冗餘副本。這種資料表示方式稱為非正規化，並且經常在資料倉儲應用程式中發現。

另請參閱 非正規化、外部索引鍵、OLTP、關聯式。

一個廣泛的術語，指稱一系列不使用 SQL 語言作為其主要資料讀寫機制的資料存取技術。某些 NoSQL 技術充當鍵值儲存，僅接受單值讀寫；有些放寬了 ACID 方法的限制；還有一些不需要預先規劃的綱要。MySQL 使用者可以透過使用 memcached API 直接存取某些類型的 MySQL 表格，將 NoSQL 風格的處理方式用於速度和簡便性，並將 SQL 操作用於彈性和便利性。

另請參閱 ACID、memcached、綱要、SQL。

一種約束類型，指定欄位不能包含任何 NULL 值。它有助於保持參考完整性，因為資料庫伺服器可以識別具有錯誤遺失值的資料。它也有助於查詢最佳化中涉及的算術運算，允許最佳化工具預測該欄位索引中的項目數量。

另請參閱 欄位、約束、NULL、主索引鍵、參考完整性。

SQL 中的特殊值，表示缺少資料。任何涉及 NULL 值的算術運算或相等性測試，反過來都會產生 NULL 結果。（因此，它類似於 IEEE 浮點數的 NaN 概念，“非數字”。）任何彙總計算（例如 AVG()）在決定除以多少列時，都會忽略具有 NULL 值的列。唯一可與 NULL 值搭配使用的測試會使用 SQL 慣用語 IS NULL 或 IS NOT NULL。

NULL 值在索引操作中扮演著一個角色，因為為了效能，資料庫必須盡量減少追蹤遺失資料值的額外負荷。通常，NULL 值不會儲存在索引中，因為使用標準比較運算子測試索引欄位的查詢永遠無法比對該欄位具有 NULL 值的列。基於相同原因，唯一索引不會阻止 NULL 值；這些值只是不會在索引中表示。在欄位上宣告 NOT NULL 約束可以確保索引中沒有遺漏的列，從而實現更好的查詢最佳化（精確計算列數以及估計是否使用索引）。

因為主索引鍵必須能夠唯一識別表格中的每一列，所以單欄主索引鍵不能包含任何 NULL 值，而多欄主索引鍵不能包含在所有欄位中都具有 NULL 值的列。

雖然 Oracle 資料庫允許將 NULL 值與字串串連，但 InnoDB 會將此類運算的結果視為 NULL。

另請參閱 索引、主索引鍵、SQL。

包含資料庫設定資訊的檔案。此延伸檔名的檔案包含在 MySQL Enterprise Backup 產品的 mysqlbackup 命令產生的備份中。

另請參閱 MySQL Enterprise Backup、mysqlbackup 命令。

開放資料庫連線能力的縮寫，一種產業標準 API。通常與基於 Windows 的伺服器或需要 ODBC 與 MySQL 通訊的應用程式搭配使用。MySQL ODBC 驅動程式稱為 Connector/ODBC。

另請參閱 Connector/ODBC。

一個包含可變長度資料（例如 BLOB 和 VARCHAR）的欄位，其長度太長而無法容納在B 樹頁面上。這些資料儲存在溢位頁面中。DYNAMIC 列格式比舊的 COMPACT 列格式更有效率地用於此類儲存。

另請參閱 B 樹、COMPACT 列格式、DYNAMIC 列格式、溢位頁面。

「線上交易處理」的縮寫。一種資料庫系統或資料庫應用程式，執行大量 交易 的工作負載，通常會同時進行頻繁的寫入和讀取，而且一次通常會影響少量資料。例如，航空預訂系統或處理銀行存款的應用程式。資料可能會以正規化形式組織，以便在DML（插入/更新/刪除）效率和查詢效率之間取得平衡。與 資料倉儲 形成對比。

憑藉其列層級鎖定和交易功能，InnoDB 是 OLTP 應用程式中使用的 MySQL 表格的理想儲存引擎。

另請參閱 資料倉儲、DML、InnoDB、查詢、列鎖定、交易。

一種不涉及資料庫停機、封鎖或限制操作的作業類型。通常應用於 DDL。縮短限制操作期間的操作（例如快速索引建立），已演變成 MySQL 5.6 中更廣泛的線上 DDL 操作集。

在備份的背景下，熱備份是一種線上操作，而暖備份則部分是一種線上操作。

另請參閱 DDL、快速索引建立、熱備份、線上 DDL、暖備份。

一種功能，可提高 InnoDB 表格在 DDL（主要是 ALTER TABLE）操作期間的效能、並行性和可用性。如需詳細資訊，請參閱 第 17.12 節「InnoDB 和線上 DDL」。

詳細資訊會因作業類型而異。在某些情況下，表格可以在 ALTER TABLE 進行時同時修改。可以執行作業，而無需表格複製，或使用特別最佳化的表格複製類型。就地操作的 DML 日誌空間使用量由 innodb_online_alter_log_max_size 設定選項控制。

此功能是 MySQL 5.5 中快速索引建立功能的增強功能。

另請參閱 DDL、快速索引建立、線上。

一種指導關聯式資料庫系統低階實作決策的方法。關聯式資料庫在效能和並行性方面的需求，意味著操作必須快速啟動或派送。在一致性和參考完整性方面的需求，意味著任何操作都可能失敗：交易可能會回滾、DML 操作可能會違反約束、鎖定請求可能會導致死鎖、網路錯誤可能會導致逾時。樂觀策略是一種假設大多數請求或嘗試都會成功，因此相對較少的工作用於為失敗情況做準備的策略。當這個假設成立時，資料庫會做很少的不必要工作；當請求確實失敗時，則必須做額外的工作來清理和撤銷變更。

InnoDB 對於諸如鎖定和提交等操作採用樂觀策略。例如，交易變更的資料可以在提交發生之前寫入資料檔案，使得提交本身非常快速，但如果交易回滾，則需要更多的工作來撤銷變更。

樂觀策略的相反是悲觀策略，系統會針對不可靠且經常不成功的操作進行優化。這種方法在資料庫系統中很少見，因為在選擇可靠的硬體、網路和演算法時已經非常謹慎。

另請參閱 commit（提交）、concurrency（並行性）、DML、locking（鎖定）、pessimistic（悲觀）、referential integrity（參考完整性）。

MySQL 元件，根據相關資料表的特性和資料分佈，決定要用於查詢的最佳索引和聯結順序。

另請參閱 index（索引）、join（聯結）、query（查詢）、table（資料表）。

MySQL 的組態參數，可以儲存在選項檔案中或在命令列中傳遞。

對於適用於 InnoDB 資料表的選項，每個選項名稱都以字首 innodb_ 開頭。

另請參閱 InnoDB、option（選項）、option file（選項檔案）。

儲存 MySQL 實例組態選項的檔案。傳統上，在 Linux 和 Unix 上，此檔案名為 my.cnf，而在 Windows 上則為 my.ini。

另請參閱 configuration file（組態檔案）、my.cnf、my.ini、option（選項）。

單獨配置的磁碟頁面，用於保存變長欄位（例如 BLOB 和 VARCHAR），這些欄位太長而無法放入B 樹頁面。相關的欄位稱為頁外欄位。

另請參閱 B-tree（B 樹）、off-page column（頁外欄位）、page（頁面）。

包含分割區定義的檔案。具有此副檔名的檔案包含在 MySQL Enterprise Backup 產品的 mysqlbackup 命令所產生的備份中。

隨著 MySQL 5.7.6 中引入了對 InnoDB 資料表的原生分割區支援，不再為分割區的 InnoDB 資料表建立 .par 檔案。在 MySQL 5.7 中，分割區的 MyISAM 資料表會繼續使用 .par 檔案。在 MySQL 8.0 中，分割區支援僅由 InnoDB 儲存引擎提供。因此，從 MySQL 8.0 開始，不再使用 .par 檔案。

另請參閱 MySQL Enterprise Backup、mysqlbackup 命令。

代表 InnoDB 在磁碟（資料檔案）和記憶體（緩衝池）之間一次傳輸多少資料的單位。一個頁面可以包含一個或多個資料列，具體取決於每個資料列中的資料量。如果資料列無法完全放入單一頁面，InnoDB 會設定額外的指標式資料結構，以便將有關資料列的資訊儲存在一個頁面中。

在每個頁面中放入更多資料的一種方法是使用壓縮資料列格式。對於使用 BLOB 或大型文字欄位的資料表，精簡資料列格式允許將這些大型欄位與資料列的其餘部分分開儲存，從而減少不參考這些欄位的查詢的 I/O 額外負荷和記憶體使用量。

當 InnoDB 以批次讀取或寫入多組頁面以提高 I/O 吞吐量時，它會一次讀取或寫入一個範圍。

MySQL 實例中的所有 InnoDB 磁碟資料結構都共用相同的頁面大小。

另請參閱 buffer pool（緩衝池）、compact row format（精簡資料列格式）、compressed row format（壓縮資料列格式）、data files（資料檔案）、extent（範圍）、page size（頁面大小）、row（資料列）。

InnoDB 背景執行緒，用於從緩衝池清除髒頁。在 MySQL 5.6 之前，此活動由主執行緒執行。頁面清除器執行緒的數量由 innodb_page_cleaners 組態選項控制，此選項是在 MySQL 5.7.4 中引入的。

另請參閱 buffer pool（緩衝池）、dirty page（髒頁）、flush（清除）、master thread（主執行緒）、thread（執行緒）。

對於包括 MySQL 5.5 在內的版本，每個 InnoDB 頁面的大小固定為 16 KB。此值代表一個平衡點：大小足以容納大多數資料列的資料，但又小到足以最大限度地減少將不需要的資料傳輸到記憶體的效能額外負荷。不測試或支援其他值。

從 MySQL 5.6 開始，InnoDB 實例的頁面大小可以是 4KB、8KB 或 16KB，由 innodb_page_size 組態選項控制。從 MySQL 5.7.6 開始，InnoDB 也支援 32KB 和 64KB 的頁面大小。對於 32KB 和 64KB 的頁面大小，不支援 ROW_FORMAT=COMPRESSED，且最大記錄大小為 16KB。

頁面大小是在建立 MySQL 實例時設定的，之後保持不變。相同的頁面大小適用於所有 InnoDB 表空間，包括系統表空間、每個資料表一個檔案的表空間和一般表空間。

較小的頁面大小可以幫助使用小區塊大小的儲存裝置提高效能，特別是對於磁碟受限工作負載（例如OLTP應用程式）中的SSD裝置。當單個資料列更新時，複製到記憶體、寫入磁碟、重新組織、鎖定等等的資料會更少。

另請參閱 disk-bound（磁碟受限）、file-per-table（每個資料表一個檔案）、general tablespace（一般表空間）、instance（實例）、OLTP、page（頁面）、SSD、system tablespace（系統表空間）、tablespace（表空間）。

外鍵關聯中的資料表，該資料表保存從子資料表指向的初始欄位值。刪除或更新父資料表中的資料列的後果取決於外鍵定義中的 ON UPDATE 和 ON DELETE 子句。子資料表中具有對應值的資料列可能會自動被刪除或更新，或者這些欄位可能會設定為 NULL，或者可能會阻止該操作。

另請參閱 child table（子資料表）、foreign key（外鍵）。

包含 MySQL 資料庫中的某些資料表，或 MySQL 實例中的某些資料庫的備份。與完整備份形成對比。

另請參閱 backup（備份）、full backup（完整備份）、table（資料表）。

一個索引，僅代表欄位值的一部分，通常是長 VARCHAR 值的前 N 個字元（即前綴）。

另請參閱 索引、索引前綴。

通常由託管服務供應商使用的執行環境，在此環境中，應用程式擁有某些權限，但沒有其他權限。例如，應用程式可能能夠透過網路存取資料庫伺服器，但在讀取和寫入本機檔案方面會被「沙箱化」。

另請參閱 Connector/NET。

在 MySQL 5.5 及更高版本中，performance_schema 綱要提供了一組資料表，您可以查詢這些資料表，以取得有關 MySQL 伺服器許多內部零件的效能特性的詳細資訊。請參閱 第 29 章，MySQL 效能綱要。

另請參閱 INFORMATION_SCHEMA、閂鎖 (latch)、互斥鎖 (mutex)、讀寫鎖 (rw-lock)。

一種程式設計語言，其根源於 Unix 指令碼和報表產生。它結合了高效能的正規表示式和檔案 I/O。透過 CPAN 等儲存庫，可以使用大量的可重複使用模組。

另請參閱 Perl API。

用 Perl 語言編寫的 MySQL 應用程式的開放原始碼 API。透過 DBI 和 DBD::mysql 模組實作。如需詳細資訊，請參閱 第 31.9 節，「MySQL Perl API」。

另請參閱 API、Perl。

一種將 InnoDB 資料表的索引統計資料儲存在磁碟上的功能，為查詢提供更好的計畫穩定性。如需詳細資訊，請參閱 第 17.8.10.1 節，「設定持久最佳化工具統計資料參數」。

另請參閱 索引、最佳化工具 (optimizer)、計畫穩定性、查詢、資料表。

一種犧牲效能或並行性以換取安全性的方法。如果很高比例的要求或嘗試可能會失敗，或者失敗的要求後果很嚴重，則適合採用此方法。InnoDB 使用所謂的悲觀式鎖定策略，以最大限度地減少死結的機會。在應用程式層級，您可以透過在交易開始時就取得交易所需的所有鎖定，來避免死結。

許多內建的資料庫機制都使用相反的樂觀式方法。

另請參閱 死結、鎖定、樂觀式。

查詢結果集中出現的資料列，但在先前的查詢結果集中並未出現。例如，如果在交易中執行查詢兩次，並且在此期間，另一個交易在插入新資料列或更新資料列使其符合查詢的 WHERE 子句後提交。

此事件稱為幻讀。它比不可重複讀取更難以防範，因為鎖定第一個查詢結果集中的所有資料列並不會阻止導致幻讀發生的變更。

在不同的隔離層級中，幻讀會由可序列化讀取層級阻止，並且允許可重複讀取、一致讀取和讀取未提交層級。

另請參閱 一致讀取、隔離層級、不可重複讀取、READ UNCOMMITTED、REPEATABLE READ、SERIALIZABLE、交易。

一種源自 Web 應用程式的程式設計語言。程式碼通常會以區塊的形式嵌入網頁的原始碼中，並在 Web 伺服器傳輸網頁時將輸出取代到網頁中。這與 CGI 指令碼等以整個網頁的形式列印輸出的應用程式形成對比。PHP 的程式碼樣式適用於高度互動式和動態的網頁。現代的 PHP 程式也可以作為命令列或 GUI 應用程式執行。

MySQL 應用程式是使用PHP API之一編寫的。可重複使用的模組可以使用 C 編寫，並從 PHP 呼叫。

使用 MySQL 編寫伺服器端網頁的另一項技術是 ASP.net。

另請參閱 ASP.net、C、PHP API。

有多個 API 可用於以 PHP 語言編寫 MySQL 應用程式：原始的 MySQL API (Mysql)、MySQL Improved Extension (Mysqli)、MySQL Native Driver (Mysqlnd)、MySQL 函式 (PDO_MYSQL) 和 Connector/PHP。如需詳細資訊，請參閱 MySQL 和 PHP。

另請參閱 API、PHP。

一種涉及硬體相關層面的作業類型，例如磁碟區塊、記憶體頁面、檔案、位元、磁碟讀取等。通常，實體層面在專家級效能調校和問題診斷期間很重要。與邏輯相反。

另請參閱 邏輯、實體備份。

一種複製實際資料檔案的備份。例如，MySQL Enterprise Backup 產品的 mysqlbackup 命令會產生實體備份，因為其輸出包含可由 mysqld 伺服器直接使用的資料檔案，從而加快還原作業。與邏輯備份相反。

另請參閱 備份、邏輯備份、MySQL Enterprise Backup、還原。

時間點復原的縮寫。

另請參閱 時間點復原。

一個查詢執行計畫的屬性，其中最佳化工具每次針對給定的查詢做出相同的選擇，以便效能一致且可預測。

另請參閱 查詢、查詢執行計畫。

將備份還原以重新建立資料庫在特定日期和時間的狀態的過程。通常縮寫為「PITR」。由於指定的時間不太可能與備份的時間完全對應，因此此技術通常需要實體備份和邏輯備份的組合。例如，使用 MySQL Enterprise Backup 產品，您會還原在指定時間點之前進行的最後一個備份，然後重播從備份時間到 PITR 時間之間的二進位日誌中的變更。

另請參閱 備份、二進位日誌、邏輯備份、MySQL Enterprise Backup、實體備份。

資料庫伺服器接聽的 TCP/IP 通訊端編號，用於建立連線。通常與主機一起指定。根據您對網路加密的使用情況，可能有一個用於未加密流量的連接埠，以及另一個用於 SSL 連線的連接埠。

另請參閱 連線、主機、SSL。

由 MySQL Enterprise Backup 產品產生的一組備份檔案，在應用所有階段的 二進位日誌和增量備份之後。產生的檔案已準備好還原。在套用步驟之前，這些檔案稱為原始備份。

另請參閱 二進位日誌、熱備份、增量備份、MySQL Enterprise Backup、原始備份、還原。

事先分析以決定有效率的執行計畫的 SQL 陳述式。它可以執行多次，而無需每次都進行剖析和分析的負擔。每次可以透過使用預留位置，將不同的值替換為 WHERE 子句中的常值。此取代技術可提高安全性，防止某些類型的 SQL 注入攻擊。您還可以減少將傳回值轉換和複製到程式變數的負擔。

雖然您可以透過 SQL 語法直接使用預備陳述式，但各種連接器具有操作預備陳述式的程式設計介面，而且這些 API 比使用 SQL 更有效率。

另請參閱 用戶端預備陳述式、連接器、伺服器端預備陳述式。

一組欄位（及其隱含的基於這組欄位的索引），可以唯一識別資料表中的每一列。因此，它必須是一個不包含任何 NULL 值的唯一索引。

InnoDB 要求每個資料表都有這樣一個索引（也稱為叢集索引（clustered index）或群集索引（cluster index）），並根據主鍵的欄位值來組織資料表的儲存。

在選擇主鍵值時，請考慮使用任意值（合成鍵（synthetic key）），而不是依賴於從其他來源取得的值（自然鍵（natural key））。

參見：叢集索引（clustered index）、索引（index）、自然鍵（natural key）、合成鍵（synthetic key）。

Kerberos 用於表示具名實體（例如使用者或伺服器）的術語。

參見：服務主體名稱（service principal name）、使用者主體名稱（user principal name）。

一個執行中程式的實例。作業系統會在多個執行中的行程之間切換，以實現一定程度的並行性（concurrency）。在大多數作業系統上，行程可以包含多個共享資源的執行執行緒（thread）。執行緒之間的內容切換比行程之間的等效切換更快。

參見：並行性（concurrency）、執行緒（thread）。

索引中的人工記錄，用於鎖定（locking）目前不存在的索引鍵值或範圍。

參見：下限記錄（infimum record）、鎖定（locking）、上限記錄（supremum record）。

POSIX 執行緒標準，定義了 Unix 和 Linux 系統上執行緒和鎖定操作的 API。InnoDB 在 Unix 和 Linux 系統上使用此實作來處理互斥鎖（mutexes）。

參見：互斥鎖（mutex）。

一種由一個或多個獨立背景執行緒（由 innodb_purge_threads 控制）定期執行的垃圾回收類型。清除會解析和處理來自歷史列表（history list）的復原日誌（undo log）頁面，目的是移除標記為刪除（由先前的 DELETE 陳述式）且不再需要用於多版本並行控制（MVCC）或回滾（rollback）的叢集和次要索引記錄。清除會在處理後從歷史列表中釋放復原日誌頁面。

參見：歷史列表（history list）、MVCC、回滾（rollback）、復原日誌（undo log）。

將 DELETE 操作產生的次要索引頁面變更儲存在變更緩衝區（change buffer）中，而不是立即寫入變更的技術，以便執行實體寫入以最大程度地減少隨機 I/O。（由於刪除操作是兩步驟過程，因此此操作會緩衝通常會清除先前標記為刪除的索引記錄的寫入。）它是變更緩衝（change buffering）的類型之一；其他類型是插入緩衝（insert buffering）和刪除緩衝（delete buffering）。

參見：變更緩衝區（change buffer）、變更緩衝（change buffering）、刪除緩衝（delete buffering）、插入緩衝區（insert buffer）、插入緩衝（insert buffering）。

InnoDB 歷史列表（history list）的另一個名稱。與 innodb_max_purge_lag 設定選項相關。

參見：歷史列表（history list）、清除（purge）。

InnoDB 行程中專用於執行定期清除（purge）操作的執行緒（thread）。在 MySQL 5.6 及更高版本中，innodb_purge_threads 設定選項會啟用多個清除執行緒。

參見：清除（purge）、執行緒（thread）。

一種廣泛應用於從 Unix 指令碼到大型應用程式等領域的程式設計語言。包含執行階段輸入、內建高階資料類型、物件導向功能和廣泛的標準函式庫。通常用作以其他語言撰寫的元件之間的「黏合」語言。MySQL Python API 是開源 MySQLdb 模組。

參見：MySQLdb、Python API。

參見：API、Python。

在 SQL 中，從一個或多個資料表（table）讀取資訊的操作。根據資料的組織方式和查詢參數，可以透過查詢索引（index）來最佳化查詢。如果涉及多個資料表，則查詢稱為聯結（join）。

由於歷史原因，有時對於陳述式內部處理的討論會在更廣泛的意義上使用「查詢」，包括其他類型的 MySQL 陳述式，例如 DDL 和 DML 陳述式。

參見：DDL、DML、索引（index）、聯結（join）、SQL、資料表（table）。

最佳化工具關於如何最有效率地執行查詢（query）所做出的一組決策，包括要使用的索引（index）或索引，以及聯結（join）資料表的順序。計畫穩定性（Plan stability）涉及針對給定查詢一致地做出相同的選擇。

參見：索引（index）、聯結（join）、計畫穩定性（plan stability）、查詢（query）。

為了減少資料庫活動，通常是為了準備諸如 ALTER TABLE、備份（backup）或關機（shutdown）等操作。可能會或可能不會盡可能多地進行刷新（flushing），以便InnoDB 不會繼續執行背景 I/O。

在 MySQL 5.6 及更高版本中，語法 FLUSH TABLES ... FOR EXPORT 會將某些資料寫入磁碟，以簡化透過複製資料檔案來備份 InnoDB 資料表。

參見：備份（backup）、刷新（flush）、InnoDB、關機（shutdown）。

一種樹狀資料結構，用於多維資料（例如地理座標、矩形或多邊形）的空間索引。

參見：B 樹（B-tree）。

「Redundant Array of Inexpensive Drives（廉價磁碟冗餘陣列）」的縮寫。將 I/O 操作分散到多個磁碟機上，可以在硬體層級實現更高的並行性（concurrency），並提高原本依序執行的低階寫入操作的效率。

參見：並行性（concurrency）。

一種快速估計欄位中不同值的數量（欄位的基數（cardinality））的技術。InnoDB 從索引中隨機取樣頁面，並使用該資料來估計不同值的數量。

參見：基數（cardinality）。

由 MySQL Enterprise Backup 產品產生的初始備份檔案集，在套用二進位日誌（binary log）中反映的變更和任何增量備份（incremental backups）之前。在此階段，檔案尚未準備好還原（restore）。在套用這些變更後，這些檔案稱為準備好的備份（prepared backup）。

參見：二進位日誌（binary log）、熱備份（hot backup）、ibbackup_logfile、增量備份（incremental backup）、MySQL Enterprise Backup、準備好的備份（prepared backup）、還原（restore）。

一種隔離等級（isolation level），使用鎖定（locking）策略，為了效能而放寬了交易（transaction）之間的部分保護。交易無法看到其他交易的未提交資料，但可以看到目前交易開始後由其他交易提交的資料。因此，交易永遠不會看到任何錯誤資料，但它看到的資料在一定程度上可能取決於其他交易的時序。

當具有此隔離等級的交易執行 UPDATE ... WHERE 或 DELETE ... WHERE 操作時，其他交易可能必須等待。該交易可以執行 SELECT ... FOR UPDATE 和 LOCK IN SHARE MODE 操作，而不會讓其他交易等待。

SELECT ... FOR SHARE 在 MySQL 8.0.1 中取代 SELECT ... LOCK IN SHARE MODE，但 LOCK IN SHARE MODE 仍可向後相容。

參見：ACID、隔離等級（isolation level）、鎖定（locking）、REPEATABLE READ、SERIALIZABLE、交易（transaction）。

當一個交易讀取到另一個交易修改過的資料時，可能會發生的現象，例如髒讀（dirty reads）、不可重複讀取（non-repeatable reads）和幻讀（phantom reads）。

另請參閱 髒讀（dirty read）、不可重複讀取（non-repeatable read）、幻讀（phantom）。

提供交易之間最少保護的隔離級別（isolation level）。查詢採用一種鎖定（locking）策略，允許它們在通常會等待其他交易的情況下繼續進行。然而，這種額外的效能是以較低的結果可靠性為代價的，包括被其他交易更改但尚未提交的資料（稱為髒讀（dirty read））。使用此隔離級別時請格外小心，並注意結果可能不一致或不可重現，具體取決於其他交易同時在做什麼。通常，具有此隔離級別的交易僅執行查詢，而不執行插入、更新或刪除操作。

另請參閱 ACID、髒讀（dirty read）、隔離級別（isolation level）、鎖定（locking）、交易（transaction）。

由 InnoDB 的 MVCC 機制使用的內部快照。某些交易（transactions），根據其隔離級別（isolation level），看到的是交易（或在某些情況下是語句）開始時的資料值。使用讀取視圖的隔離級別包括可重複讀取（REPEATABLE READ）、讀取已提交（READ COMMITTED）和讀取未提交（READ UNCOMMITTED）。

另請參閱 隔離級別（isolation level）、MVCC、讀取已提交（READ COMMITTED）、讀取未提交（READ UNCOMMITTED）、可重複讀取（REPEATABLE READ）、交易（transaction）。

一種 I/O 請求類型，它會將一組頁面（pages）（整個區塊（extent））非同步預取到緩衝池（buffer pool）中，以防這些頁面很快被需要。線性預讀技術會根據先前區塊中頁面的存取模式預取一個區塊的所有頁面。隨機預讀技術會將一個區塊的所有頁面預取到緩衝池中，一旦緩衝池中存在來自同一區塊的一定數量的頁面。隨機預讀並非 MySQL 5.5 的一部分，但在 MySQL 5.6 中重新引入，並由 innodb_random_read_ahead 設定選項控制。

另請參閱 緩衝池（buffer pool）、區塊（extent）、頁面（page）。

一種交易（transaction）類型，可以通過消除每次交易建立讀取視圖（read view）所涉及的一些簿記工作來針對 InnoDB 表格進行最佳化。只能執行非鎖定讀取（non-locking read）查詢。它可以通過語法 START TRANSACTION READ ONLY 顯式啟動，或者在某些條件下自動啟動。有關詳細資訊，請參閱 第 10.5.3 節「最佳化 InnoDB 唯讀交易」。

另請參閱 非鎖定讀取（non-locking read）、讀取視圖（read view）、交易（transaction）。

索引記錄上的鎖定（lock）。例如，SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; 會阻止任何其他交易插入、更新或刪除 t.c1 值為 10 的列。與間隙鎖（gap lock）和下一個鍵鎖（next-key lock）對比。

另請參閱 間隙鎖定、鎖定、下一個鍵鎖定。

當 DML 語句變更 InnoDB 表格時，以記錄單位記錄在重做日誌（redo log）中的資料。它在當機復原（crash recovery）期間用於修正由不完整的交易（transactions）寫入的資料。不斷增加的LSN值表示已通過重做日誌的累積重做資料量。

另請參閱 當機復原（crash recovery）、DML、LSN、重做日誌（redo log）、交易（transaction）。

在當機復原（crash recovery）期間使用的基於磁碟的資料結構，用於修正由不完整的交易（transactions）寫入的資料。在正常操作期間，它會編碼更改 InnoDB 表格資料的請求，這些請求是由 SQL 語句或低階 API 呼叫產生的。在意外關機（shutdown）之前未完成更新資料檔案（data files）的修改會自動重播。

重做日誌在磁碟上以一組重做日誌檔案的型式實際呈現。重做日誌資料以受影響的記錄進行編碼；此資料統稱為重做（redo）。資料通過重做日誌的過程由不斷增加的LSN值表示。

如需詳細資訊，請參閱第 17.6.5 節「重做日誌」

另請參閱 當機復原（crash recovery）、資料檔案（data files）、ib_logfile、日誌緩衝區（log buffer）、LSN、重做（redo）、關機（shutdown）、交易（transaction）。

一種 InnoDB 功能，啟用時，它會循序將重做日誌記錄寫入歸檔檔案，以避免在備份操作進行時，備份工具無法跟上重做日誌產生速度而導致的潛在資料遺失。有關詳細資訊，請參閱重做日誌歸檔。

另請參閱 重做日誌（redo log）。

最舊的 InnoDB 列格式（row format）。在 MySQL 5.0.3 之前，它是 InnoDB 中唯一可用的列格式。從 MySQL 5.0.3 到 MySQL 5.7.8，預設的列格式為 COMPACT。從 MySQL 5.7.9 開始，預設的列格式由 innodb_default_row_format 設定選項定義，其預設設定為 DYNAMIC。您仍然可以指定 REDUNDANT 列格式，以便與較舊的 InnoDB 表格相容。

如需詳細資訊，請參閱第 17.10 節「InnoDB 列格式」。

另請參閱 精簡列格式（compact row format）、動態列格式（dynamic row format）、列格式（row format）。

保持資料始終以一致格式呈現的技術，是 ACID 原則的一部分。特別是，通過使用外鍵約束（foreign key constraints）來保持不同表格中的資料一致，這可以防止變更發生或自動將這些變更傳播到所有相關表格。相關機制包括唯一約束（unique constraint），它可以防止錯誤地插入重複值，以及NOT NULL 約束（NOT NULL constraint），它可以防止錯誤地插入空白值。

另請參閱 ACID、外鍵約束（FOREIGN KEY constraint）、NOT NULL 約束（NOT NULL constraint）、唯一約束（unique constraint）。

現代資料庫系統的一個重要方面。資料庫伺服器會編碼並強制執行一對一、一對多、多對一和唯一性等關係。例如，在地址資料庫中，一個人可能沒有、有一個或多個電話號碼；一個電話號碼可能與多個家庭成員相關聯。在財務資料庫中，一個人可能需要恰好一個納稅人 ID，並且任何納稅人 ID 都只能與一個人相關聯。

資料庫伺服器可以使用這些關係來防止插入錯誤的資料，並找到有效查詢資訊的方法。例如，如果將某個值宣告為唯一的，則伺服器可以在找到第一個匹配項後立即停止搜索，並且它可以拒絕插入同一個值的第二個副本的嘗試。

在資料庫層級，這些關係通過 SQL 功能表達，例如表格中的欄位（columns）、唯一和 NOT NULL 約束（constraints）、外鍵（foreign keys）和不同類型的聯結操作。複雜的關係通常涉及在多個表格之間分割的資料。通常，資料會被正規化（normalized），以便在一對多關係中重複的值僅儲存一次。

在數學背景下，資料庫中的關係源自集合論。例如，WHERE 子句的 OR 和 AND 運算符表示聯集和交集的概念。

另請參閱 ACID、欄位（column）、約束（constraint）、外鍵（foreign key）、正規化（normalized）。

在全文檢索功能中，會顯示一個數值，表示搜尋字串與FULLTEXT 索引中資料的相似程度。例如，當您搜尋單一字詞時，該字詞在文字中出現多次的列，通常比僅出現一次的列更為相關。

另請參閱 全文搜尋、全文索引。

InnoDB 的預設隔離等級。它會防止任何已查詢的列被其他交易變更，因此會阻擋不可重複讀取，但不會阻擋幻讀。它使用中等嚴格的鎖定策略，使交易中的所有查詢都能看到來自同一快照的資料，也就是交易開始時的資料狀態。

當使用此隔離等級的交易執行 UPDATE ... WHERE、DELETE ... WHERE、SELECT ... FOR UPDATE 和 LOCK IN SHARE MODE 操作時，其他交易可能必須等待。

SELECT ... FOR SHARE 在 MySQL 8.0.1 中取代 SELECT ... LOCK IN SHARE MODE，但 LOCK IN SHARE MODE 仍可向後相容。

另請參閱 ACID、一致讀取、隔離等級、鎖定、幻讀、交易。

字符集範圍是應用於字符集的術語。字符集範圍是指該集合中的字符集合。請參閱第 12.2.1 節「字符集範圍」。

在複寫拓樸中，接收來自另一個伺服器（來源）變更並套用這些相同變更的資料庫伺服器機器。因此，它會維護與來源相同的內容，儘管可能會略有延遲。

在 MySQL 中，副本通常用於災難復原，以取代故障的來源。它們也常用於測試軟體升級和新設定，以確保資料庫組態變更不會導致效能或可靠性問題。

副本通常具有高工作負載，因為它們會處理從來源中繼的所有 DML（寫入）操作，以及使用者查詢。為了確保副本可以足夠快速地套用來源的變更，它們通常具有快速的 I/O 裝置以及足夠的 CPU 和記憶體，以便在同一伺服器上執行多個資料庫執行個體。例如，來源可以使用硬碟儲存，而副本則使用 SSD。

另請參閱 DML、複寫、伺服器、來源、SSD。

將變更從來源傳送到一個或多個副本，使所有資料庫都具有相同資料的做法。此技術具有廣泛的用途，例如負載平衡以提高可擴展性、災難復原，以及測試軟體升級和組態變更。變更可以透過稱為以列為基礎的複寫和以陳述式為基礎的複寫的方法在資料庫之間傳送。

另請參閱 副本、以列為基礎的複寫、來源、以陳述式為基礎的複寫。

將來自 MySQL Enterprise Backup 產品的一組備份檔案放置到位，供 MySQL 使用的程序。可以執行此操作來修復損壞的資料庫、返回到較早的時間點，或（在複寫環境中）設定新的副本。在MySQL Enterprise Backup產品中，此操作是由 mysqlbackup 命令的 copy-back 選項執行的。

另請參閱 熱備份、MySQL Enterprise Backup、mysqlbackup 命令、預先準備的備份、副本、複寫。

結束交易的SQL陳述式，會取消交易進行的任何變更。它與提交相反，提交會使交易中所做的任何變更成為永久性的。

預設情況下，MySQL 使用自動提交設定，該設定會在每個 SQL 陳述式後自動發出提交。您必須變更此設定才能使用回滾技術。

另請參閱 ACID、自動提交、提交、SQL、交易。

包含復原日誌的儲存區域。傳統上，回滾區段位於系統表空間中。從 MySQL 5.6 開始，回滾區段可以位於復原表空間中。從 MySQL 5.7 開始，回滾區段也會配置給全域暫存表空間。

另請參閱 全域暫存表空間、系統表空間、復原日誌、復原表空間。

由一組欄定義的邏輯資料結構。一組列組成一個表。在 InnoDB 資料檔案中，每個頁面可以包含一個或多個列。

雖然 InnoDB 使用「列格式」這個詞彙以與 MySQL 語法保持一致，但列格式是每個表的屬性，並適用於該表中的所有列。

另請參閱 欄、資料檔案、頁面、列格式、表。

InnoDB 表的列的磁碟儲存格式。隨著 InnoDB 獲得諸如壓縮等新功能，會引入新的列格式，以支援儲存效率和效能的改進。

InnoDB 表的列格式由 ROW_FORMAT 選項或 innodb_default_row_format 組態選項 (在 MySQL 5.7.9 中引入) 指定。列格式包括 REDUNDANT、COMPACT、COMPRESSED 和 DYNAMIC。若要檢視 InnoDB 表的列格式，請發出 SHOW TABLE STATUS 陳述式，或在 INFORMATION_SCHEMA 中查詢 InnoDB 表的元資料。

另請參閱 精簡列格式、壓縮列格式、壓縮、動態列格式、多餘列格式、列、表。

一種鎖定，可防止另一個交易以不相容的方式存取列。同一表中的其他列可以由其他交易自由寫入。這是對InnoDB表執行DML操作時所使用的鎖定類型。

與 MyISAM 使用的表鎖定，或在 InnoDB 表上執行無法使用線上 DDL 完成的 DDL 操作期間使用的表鎖定進行對比；這些鎖定會阻擋同時存取該表。

另請參閱 DDL、DML、InnoDB、鎖定、鎖定、線上 DDL、表鎖定、交易。

一種複寫形式，其中事件從來源傳播，指定如何在複本上變更個別的列。對於 innodb_autoinc_lock_mode 選項的所有設定，使用此方法都是安全的。

另請參閱 自動遞增鎖定、innodb_autoinc_lock_mode、複本、複寫、來源、基於陳述式的複寫。

用於 InnoDB 表格的鎖定機制，依賴於列鎖定而不是表格鎖定。多個交易可以同時修改同一個表格。只有當兩個交易嘗試修改同一列時，其中一個交易才會等待另一個交易完成（並釋放其列鎖定）。

另請參閱 InnoDB、鎖定、列鎖定、表格鎖定、交易。

一種強調動態類型和物件導向程式設計的程式語言。一些語法對於 Perl 開發人員來說很熟悉。

另請參閱 API、Perl、Ruby API。

mysql2 基於 libmysqlclient API 函式庫，可供開發 MySQL 應用程式的 Ruby 程式設計人員使用。有關更多資訊，請參閱第 31.11 節「MySQL Ruby API」。

另請參閱 libmysql、Ruby。

InnoDB 用於表示和強制執行共享存取 鎖定 的低階物件，這些鎖定遵循某些規則來存取內部記憶體中的資料結構。與 mutexes 對比，InnoDB 使用 mutexes 來表示和強制執行對內部記憶體中資料結構的獨佔存取。Mutexes 和 rw-locks 統稱為 latches。

rw-lock 類型包括 s-locks（共享鎖定）、x-locks（獨佔鎖定）和 sx-locks（共享獨佔鎖定）。

下表總結了 rw-lock 類型的相容性。

另請參閱 latch、鎖定、互斥鎖、Performance Schema。

儲存點有助於實作巢狀交易。它們可用於為屬於較大交易一部分的表格上的操作提供範圍。例如，在預訂系統中排定行程可能涉及預訂幾個不同的航班；如果所需的航班不可用，您可以回滾預訂該段航程所涉及的變更，而不回滾先前成功預訂的航班。

另請參閱 回滾、交易。

能夠在不因超出系統容量限制而導致效能突然下降的情況下，向系統新增更多工作並發出更多同步要求。軟體架構、硬體配置、應用程式程式碼和工作負載類型都在可擴展性中發揮作用。當系統達到其最大容量時，用於提高可擴展性的常見技術是向上擴展（提高現有硬體或軟體的容量）和向外擴展（新增伺服器和更多 MySQL 執行個體）。通常與可用性配對，作為大規模部署的關鍵要素。

另請參閱 可用性、向外擴展、向上擴展。

一種透過新增伺服器和更多 MySQL 執行個體來提高可擴展性的技術。例如，設定複寫、NDB 叢集、連線集區或其他將工作分散到一組伺服器上的功能。與向上擴展對比。

另請參閱 可擴展性、向上擴展。

一種透過提高現有硬體或軟體的容量來提高可擴展性的技術。例如，增加伺服器上的記憶體，並調整與記憶體相關的參數，例如 innodb_buffer_pool_size 和 innodb_buffer_pool_instances。與向外擴展對比。

另請參閱 可擴展性、向外擴展。

從概念上講，結構描述是一組相關的資料庫物件，例如表格、表格欄、欄的資料類型、索引、外部索引鍵等等。這些物件透過 SQL 語法連接，因為欄組成表格，外部索引鍵參考表格和欄等等。理想情況下，它們在邏輯上也相互連接，作為統一應用程式或彈性架構的一部分協同工作。例如，INFORMATION_SCHEMA 和 performance_schema 資料庫在其名稱中使用「結構描述」，以強調它們所包含的表格和欄之間的密切關係。

在 MySQL 中，從物理上講，結構描述與資料庫同義。您可以在 MySQL SQL 語法中替換關鍵字 SCHEMA 而不是 DATABASE，例如使用 CREATE SCHEMA 而不是 CREATE DATABASE。

其他一些資料庫產品會區分它們。例如，在 Oracle 資料庫產品中，結構描述僅表示資料庫的一部分：由單一使用者擁有的表格和其他物件。

另請參閱 資料庫、INFORMATION_SCHEMA、Performance Schema。

「序列化字典資訊」的縮寫。

另請參閱 序列化字典資訊 (SDI)。

在 MySQL 中，全文搜尋查詢使用一種特殊類型的索引，即FULLTEXT 索引。在 MySQL 5.6.4 和更新版本中，InnoDB 和 MyISAM 表格都支援 FULLTEXT 索引；以前，這些索引僅適用於 MyISAM 表格。

另請參閱 全文搜尋、全文索引。

一種 InnoDB 索引類型，表示表格欄的子集。InnoDB 表格可以有零個、一個或多個次要索引。（與叢集索引對比，每個 InnoDB 表格都需要叢集索引，並儲存所有表格欄的資料。）

次要索引可用於滿足僅需要索引欄值的查詢。對於更複雜的查詢，它可用於識別表格中的相關列，然後透過使用叢集索引的查詢來擷取這些列。

傳統上，建立和捨棄次要索引涉及從複製 InnoDB 表格中的所有資料中產生大量的額外負荷。快速索引建立功能使 InnoDB 次要索引的 CREATE INDEX 和 DROP INDEX 陳述式都快得多。

另請參閱 叢集索引、快速索引建立、索引。

InnoDB 表空間內部的劃分。如果表空間類似於目錄，則區段類似於該目錄中的檔案。區段可以增長。可以建立新的區段。

例如，在每個表格檔案表空間中，表格資料位於一個區段中，而每個相關索引都位於其自己的區段中。系統表空間包含許多不同的區段，因為它可以保存許多表格及其相關的索引。在 MySQL 8.0 之前，系統表空間還包括一個或多個用於還原日誌的回滾區段。

區段會隨著資料的插入和刪除而增長和縮減。當區段需要更多空間時，每次會擴展一個範圍 (1 MB)。同樣地，當不再需要該範圍中的所有資料時，區段會釋放一個範圍的空間。

另請參閱 範圍、每個表格檔案、回滾區段、系統表空間、表空間、還原日誌。

資料分佈的屬性，即欄中不同值的數量（其基數）除以表格中的記錄數。高選擇性表示欄值相對唯一，並且可以透過索引有效率地擷取。如果您（或查詢最佳化工具）可以預測 WHERE 子句中的測試僅與表格中的少量（或比例）列匹配，如果先使用索引評估該測試，則整體查詢往往會很有效率。

另請參閱 基數、查詢。

一種用於 UPDATE 陳述式的讀取操作，是 READ COMMITTED 和 一致性讀取 的組合。當 UPDATE 陳述式檢查已鎖定的資料列時，InnoDB 會將最新的已提交版本回傳給 MySQL，以便 MySQL 可以判斷該資料列是否符合 UPDATE 的 WHERE 條件。如果資料列符合 (必須更新)，MySQL 會再次讀取該資料列，這次 InnoDB 要嘛會鎖定該資料列，要嘛會等待該資料列的鎖定。這種讀取操作只能在交易具有 READ COMMITTED 隔離等級 時發生。

另請參閱 一致性讀取、隔離等級、READ COMMITTED。

使用最保守鎖定策略的 隔離等級，以防止任何其他 交易 插入或變更此交易讀取的資料，直到此交易完成為止。這樣，可以在交易中重複執行相同的查詢，並確保每次檢索到相同的結果集。任何試圖變更自目前交易開始以來由另一個交易提交的資料，都會導致目前交易等待。

這是 SQL 標準指定的預設隔離等級。實際上，這種嚴格程度很少需要，因此 InnoDB 的預設隔離等級是下一個最嚴格的 REPEATABLE READ。

另請參閱 ACID、一致性讀取、隔離等級、鎖定、REPEATABLE READ、交易。

以序列化形式呈現的字典物件中繼資料。SDI 以 JSON 格式儲存。

從 MySQL 8.0.3 開始，SDI 存在於所有 InnoDB 表空間檔案中，但暫存表空間和復原表空間檔案除外。表空間檔案中存在 SDI 可提供中繼資料冗餘。例如，如果資料字典無法使用，可以使用 ibd2sdi 公用程式從表空間檔案中擷取字典物件中繼資料。

對於 MyISAM 資料表，SDI 儲存在架構目錄中的 .sdi 中繼資料檔案中。執行 IMPORT TABLE 作業需要 SDI 中繼資料檔案。

另請參閱 每個資料表一個檔案、一般表空間、系統表空間、表空間。

一種持續執行的程式類型，等待接收並處理來自另一個程式（用戶端）的請求。由於通常整個電腦專用於執行一個或多個伺服器程式 (例如資料庫伺服器、Web 伺服器、應用程式伺服器或這些程式的組合)，因此術語 伺服器 也可以指執行伺服器軟體的電腦。

另請參閱 用戶端、mysqld。

由 MySQL 伺服器管理的 預先準備的陳述式。從歷史上看，伺服器端預先準備的陳述式出現的問題導致 Connector/J 和 Connector/PHP 開發人員有時會改用 用戶端預先準備的陳述式。對於現代 MySQL 伺服器版本，建議使用伺服器端預先準備的陳述式來提高效能、可擴展性和記憶體效率。

另請參閱 用戶端預先準備的陳述式、Connector/J、Connector/PHP、預先準備的陳述式。

代表服務的 Kerberos 具名實體的名稱。

另請參閱 主體。

提供對應用程式服務 (例如 Web 或資料庫伺服器提供的服務) 存取權的 Kerberos 票證。

另請參閱 Connector/J。

一個暫存表空間，用於儲存使用者建立的暫存表，以及當 InnoDB 設定為內部暫存表的磁碟儲存引擎時，由最佳化工具建立的內部暫存表。

另請參閱 最佳化工具、暫存表、暫存表空間。

一種 鎖定，允許其他 交易 讀取鎖定的物件，並取得對該物件的其他共用鎖定，但不允許寫入該物件。獨佔鎖定 的相反。

另請參閱 獨佔鎖定、鎖定、交易。

指 系統表空間 或 一般表空間 的另一種方式。一般表空間是在 MySQL 5.7 中引入的。多個資料表可以駐留在共用表空間中。只有單個資料表可以駐留在每個資料表一個檔案的表空間中。

另請參閱 一般表空間、系統表空間。

將所有 髒 緩衝池頁面寫入磁碟的過程，這些頁面的重做項目包含在 重做記錄 的特定部分中。發生於 InnoDB 重複使用記錄檔的某一部分之前；記錄檔以循環方式使用。通常發生於寫入密集型 工作負載。

另請參閱 髒頁、清除、重做記錄、工作負載。

停止 MySQL 伺服器的過程。依預設，此過程會清除 InnoDB 資料表的操作，因此 InnoDB 的關閉速度可能會緩慢，但在稍後啟動時速度會很快。如果您跳過清除操作，則關閉速度會很快，但必須在下次重新啟動期間執行清除。

InnoDB 的關閉模式由 innodb_fast_shutdown 選項控制。

另請參閱 快速關閉、InnoDB、慢速關閉、啟動。

一種用於效能調整 MySQL 伺服器處理的 SQL 陳述式的 記錄。記錄資訊儲存在檔案中。您必須啟用此功能才能使用它。您可以控制記錄哪些類別的「慢速」SQL 陳述式。如需詳細資訊，請參閱 第 7.4.5 節， 「慢速查詢記錄」。

另請參閱 一般查詢記錄、記錄。

一種 關閉 類型，在完成之前會執行額外的 InnoDB 清除操作。也稱為 乾淨關閉。由組態參數 innodb_fast_shutdown=0 或命令 SET GLOBAL innodb_fast_shutdown=0; 指定。雖然關閉本身可能需要較長的時間，但該時間應在後續啟動時節省。

另請參閱 乾淨關閉、快速關閉、關閉。

特定時間的資料表示，即使其他 交易提交變更，該資料仍保持不變。某些 隔離等級 使用此功能來允許 一致性讀取。

另請參閱 提交、一致性讀取、隔離等級、交易。

在建立 InnoDB 索引期間用於排序資料的緩衝區。排序緩衝區大小是使用 innodb_sort_buffer_size 組態選項設定的。

複製 案例中，處理資料的初始插入、更新和刪除請求的資料庫伺服器機器。這些變更會傳播到其他稱為 複本 的伺服器並在這些伺服器上重複執行。

另請參閱 複本、複製。

用於在 MySQL 執行個體中唯一識別 InnoDB 表空間 的識別碼。系統表空間 的空間 ID 始終為零；相同的 ID 適用於系統表空間或通用表空間中的所有表。每個 單表表空間 和 通用表空間 都有其自己的空間 ID。

在 MySQL 5.6 之前，這個硬編碼的值在 MySQL 執行個體之間移動 InnoDB 表空間檔案時會出現困難。從 MySQL 5.6 開始，您可以使用涉及 FLUSH TABLES ... FOR EXPORT、ALTER TABLE ... DISCARD TABLESPACE 和 ALTER TABLE ... IMPORT TABLESPACE 語句的 可傳輸表空間 功能，在執行個體之間複製表空間檔案。調整空間 ID 所需的資訊在 .cfg 檔案 中傳達，您需將該檔案與表空間一起複製。有關詳細資訊，請參閱 第 17.6.1.3 節「匯入 InnoDB 表格」。

另請參閱 .cfg 檔案、單表表空間、通用表空間、.ibd 檔案、系統表空間、表空間、可傳輸表空間。

一種檔案類型，透過將代表空白區塊的中繼資料寫入磁碟，而不是寫入實際空白空間，更有效率地使用檔案系統空間。InnoDB 透明頁面壓縮 功能依賴於稀疏檔案支援。如需更多資訊，請參閱 第 17.9.2 節「InnoDB 頁面壓縮」。

另請參閱 空洞填補 (hole punching)、透明頁面壓縮。

一種 等待 操作，會持續測試資源是否可用。此技術用於通常只保留短時間的資源，在這種情況下，以「忙碌迴圈」的方式等待比讓執行緒休眠並執行內容切換更有效率。如果資源在短時間內未變得可用，旋轉迴圈會停止，並使用另一種等待技術。

另請參閱 閂鎖 (latch)、鎖定 (lock)、互斥鎖 (mutex)、等待 (wait)。

一個基於 Java 的應用程式框架，旨在透過提供配置元件的方式來協助應用程式設計。

參見 J2EE。

用於執行資料庫操作的標準結構化查詢語言。通常分為 DDL、DML 和 查詢 類別。MySQL 包含一些額外的語句類別，例如 複寫。有關 SQL 語法建構區塊，請參閱第 11 章「語言結構」；有關用於 MySQL 資料表欄位的資料類型，請參閱 第 13 章「資料類型」；有關 SQL 語句及其相關類別的詳細資訊，請參閱 第 15 章「SQL 語句」；有關在查詢中使用的標準和 MySQL 特定函式，請參閱第 14 章「函式和運算子」。

另請參閱 DDL、DML、查詢 (query)、複寫 (replication)。

JDBC 標準定義的錯誤代碼，用於使用 Connector/J 的應用程式進行例外處理。

另請參閱 Connector/J、JDBC。

「固態硬碟」的縮寫。一種儲存裝置，其效能特性與傳統硬碟機 (HDD) 不同：儲存容量較小、隨機讀取速度較快、沒有活動零件，且有一些考量會影響寫入效能。其效能特性可能會影響 磁碟受限 工作負載的輸送量。