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 中，一種支援字元集和其他國際化方面的替代方法。與 Unicode 對比。Connector/ODBC 3.51 是一個 ANSI 驅動程式，而 Connector/ODBC 5.1 是一個 Unicode 驅動程式。

另請參閱 Connector/ODBC、ODBC、Unicode。

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 外掛程式 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、提交、回滾、交易。

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

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

CPU 提供的特殊指令，以確保關鍵的低階操作不會被中斷。

在 Kerberos 中，一種提供取得票證授予伺服器 (TGS) 所需的其他票證所需的票證授予票證 (TGT) 的初始票證的服務。驗證伺服器 (AS) 與 TGS 結合構成金鑰分配中心 (KDC)。

另請參閱金鑰分配中心、票證授予伺服器。

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

它為開發人員省去產生新唯一值的工作，在插入新列時無須執行此動作。它為查詢最佳化器提供實用資訊，因為已知欄位不能為空值，且具有唯一值。此類欄位的值可用於各種環境中的查找鍵，並且由於它們是自動產生的，因此沒有理由永遠變更它們；因此，主索引鍵欄位通常指定為自動遞增。

自動遞增欄位在基於陳述式的複寫中可能會產生問題，因為在複本上重新執行陳述式可能不會產生與來源上相同的一組欄位值，這是因為時間問題所造成。當您具有自動遞增主索引鍵時，您只能在設定 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 選項，以便您可以針對可預測的自動遞增值序列和插入操作的最大並行性之間配置最佳平衡。

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

一種在每個 SQL 陳述式後導致 提交 操作的設定。不建議在處理跨越多個陳述式的 交易 的 InnoDB 資料表時使用此模式。它可以協助 InnoDB 資料表上 唯讀交易 的效能，在其中最大限度地減少來自鎖定和產生 復原 資料的負擔，特別是在 MySQL 5.6.4 及以上版本中。它也適用於處理不適用於交易的 MyISAM 資料表。

另請參閱提交、鎖定、唯讀交易、SQL、交易、復原。

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

另請參閱可擴展性。

一種樹狀資料結構，常用於資料庫索引中。結構會始終保持排序，從而可以快速查找完全符合的項目（等於運算子）和範圍（例如，大於、小於和 BETWEEN 運算子）。此類型的索引適用於大多數儲存引擎，例如 InnoDB 和 MyISAM。

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

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

術語 B 樹的使用意在指稱索引設計的一般類別。MySQL 儲存引擎使用的 B 樹結構可視為變體，因為其具有經典 B 樹設計中不存在的複雜性。有關相關資訊，請參閱InnoDB 的「頁面結構」檔案標頭章節，該章節位於MySQL 內部手冊中。

另請參閱：雜湊索引。

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

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

另請參閱：SQL。

從 MySQL 執行個體複製部分或全部表格資料和中繼資料以進行安全保存的程序。也可以指複製的檔案集。這是 DBA 的一項重要工作。此程序的相反操作是 還原 操作。

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

備份進一步分為 熱備份、溫備份或 冷備份，具體取決於它們對正常資料庫操作的干擾程度。（熱備份干擾最少，冷備份干擾最多。）

另請參閱：冷備份、熱備份、邏輯備份、MySQL Enterprise Backup、mysqldump、實體備份、溫備份。

儲存產生的欄位或虛擬產生的欄位所基於的非產生表格欄位。換句話說，基礎欄位是產生欄位定義一部分的非產生表格欄位。

另請參閱：產生欄位、儲存產生的欄位、虛擬產生的欄位。

軟體產品生命週期的早期階段，此時產品僅供評估，通常沒有明確的版本號碼或小於 1 的數字。InnoDB 不使用 Beta 指定，而偏好在多個點發行版本中延伸的早期採用者階段，最終進入GA 版本。

另請參閱：早期採用者、GA。

包含嘗試變更表格資料的所有陳述式或資料列變更記錄的檔案。可以重新播放二進位日誌的內容，以便在複製情境中將複本更新至最新狀態，或在從備份還原表格資料後將資料庫更新至最新狀態。雖然 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、複製。

二進位日誌檔案的非正式名稱。例如，您可能會在電子郵件訊息或論壇討論中看到此縮寫。

另請參閱：二進位日誌。

由 WITH QUERY EXPANSION 子句啟用的全文搜尋的特殊模式。它會執行兩次搜尋，其中第二次搜尋的搜尋詞組是原始搜尋詞組，加上第一次搜尋中幾個最相關的文件。此技術主要適用於簡短的搜尋詞組，或許只有單字。它可以找出精確搜尋詞組未出現在文件中的相關相符項。

另請參閱：全文搜尋。

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

另請參閱：API、CLOB、連接器、Connector/ODBC。

系統中受限於大小或容量的部分，其具有限制整體輸送量的效果。例如，記憶體區域可能小於必要的空間；存取單一必要資源可能會阻止多個 CPU 核心同時執行；或等待磁碟 I/O 完成可能會阻止 CPU 以全速運作。移除瓶頸有助於改善並行。例如，擁有多個 InnoDB 緩衝池執行個體的功能可減少多個工作階段同時從緩衝池讀取和寫入時的爭用情況。

另請參閱：緩衝池、並行。

關機操作緊接著重新啟動。理想情況下，預熱期相對較短，以便效能和輸送量迅速恢復到高水準。

另請參閱：關機。

用於管理 InnoDB 緩衝池中不同大小的頁面的機制。

另請參閱：緩衝池、頁面、頁面大小。

用於暫時儲存的記憶體或磁碟區域。資料會緩衝在記憶體中，以便可以有效地寫入磁碟，使用幾個大型 I/O 操作，而不是許多小型操作。資料會緩衝在磁碟上，以提高可靠性，以便即使在最糟糕的時間發生當機或其他故障時，也可以復原資料。InnoDB 使用的主要緩衝區類型為緩衝池、雙寫緩衝區和變更緩衝區。

另請參閱：緩衝池、變更緩衝區、當機、雙寫緩衝區。

記憶體區域，用於保存快取的 InnoDB 資料，包括表格和索引。為了提高大量讀取操作的效率，緩衝池被劃分為多個頁面（pages），每個頁面可以容納多行資料。為了提高快取管理效率，緩衝池以頁面的連結串列形式實作；很少使用的資料會使用LRU演算法的變體從快取中老化移出。在具有大量記憶體的系統上，您可以將緩衝池劃分為多個緩衝池實例（buffer pool instances），以提高並發性。

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

另請參閱緩衝池實例、LRU、頁面、預熱。

緩衝池（buffer pool）可以劃分成的多個區域中的任何一個，由 innodb_buffer_pool_instances 設定選項控制。 innodb_buffer_pool_size 指定的總記憶體大小將在所有緩衝池實例之間分配。通常，具有多個緩衝池實例適用於將多個 GB 分配給 InnoDB 緩衝池的系統，每個實例的大小為 1 GB 或更大。在從多個並行會話將大量資料載入或查找到緩衝池的系統上，具有多個緩衝池實例可減少對管理緩衝池的資料結構的獨佔存取的爭用。

另請參閱 緩衝池。

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

此區別主要在 MySQL 5.1 中很重要，在該版本中，功能或錯誤修復可能適用於 InnoDB 外掛程式，但不適用於內建的 InnoDB，反之亦然。

另請參閱 InnoDB。

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

例如，員工離開公司可能會觸發人力資源部門的一系列操作。人力資源資料庫可能還需要靈活性來表示關於已雇用但尚未開始工作的人的資料。關閉線上服務的帳戶可能會導致資料從資料庫中刪除，或者資料可能會被移動或標記，以便可以在重新開啟帳戶時恢復。除了基本的健全性檢查（例如薪資不為負數）之外，公司可能會制定關於薪資上限、下限和調整的政策。零售資料庫可能不允許使用相同序號的購買退回多次，或者可能不允許超過特定價值的信用卡購買，而用於偵測詐欺的資料庫可能允許這些事情。

另請參閱 關聯式。

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

另請參閱 .ibd 檔案、空間 ID、可傳輸表空間。

一種將可移植性與效能以及對低階硬體功能的存取相結合的程式語言，使其成為編寫作業系統、驅動程式和其他種類的系統軟體的熱門選擇。許多複雜的應用程式、語言和可重複使用的模組都具有以 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）、緩衝池。

表格欄（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 hints）來傳遞關於哪種查找方法對於特定查詢更有效率的建議。

基數也可以應用於多個欄中存在的不同值的數量，例如在複合索引（composite index）中。

另請參閱 欄、複合索引、索引、索引提示、持續性統計、隨機跳躍、選擇性、唯一約束。

一種特殊的資料結構，用於記錄對次要索引中的頁面所做的變更。這些值可能來自 SQL 的 INSERT、UPDATE 或 DELETE 陳述式 (DML)。涉及變更緩衝區的功能統稱為變更緩衝，包括插入緩衝、刪除緩衝和清除緩衝。

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

從物理角度來看，變更緩衝區是系統表空間的一部分，因此索引變更會在資料庫重新啟動後仍然被緩衝。只有當頁面因其他讀取操作而載入緩衝池時，才會套用變更（合併）。

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

先前稱為插入緩衝區。

另請參閱 緩衝池、變更緩衝、刪除緩衝、DML、插入緩衝區、插入緩衝、合併、頁面、清除、清除緩衝、次要索引、系統表空間。

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

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

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

另請參閱 緩衝池、資料檔、刷新、模糊檢查點、LSN。

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

在 MySQL 伺服器關閉時，innochecksum 命令可透過測試指定的表空間檔案的總和檢查碼值，協助診斷損毀問題。

MySQL 也會使用總和檢查碼進行複寫。如需詳細資訊，請參閱設定選項 binlog_checksum、source_verify_checksum 或 master_verify_checksum，以及 replica_sql_verify_checksum 或 slave_sql_verify_checksum。

另請參閱 緩衝池、頁面、表空間。

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

另請參閱 外部索引鍵、父表格。

InnoDB 緩衝池中的頁面，其中在記憶體中所做的所有變更也都已寫入（刷新）到資料檔。與髒頁面相反。

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

一種關機，會在完成前將所有變更套用至 InnoDB 表格，且沒有錯誤，與損毀或快速關機相對。與慢速關機同義。

另請參閱 損毀、快速關機、關機、慢速關機。

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

另請參閱 API、用戶端程式庫、連接器、mysql、伺服器。

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

另請參閱 用戶端、libmysqlclient。

一種準備好的陳述式，其中快取和重複使用是在本機管理，以模擬伺服器端準備好的陳述式的功能。過去，某些 Connector/J、Connector/ODBC 和 Connector/PHP 開發人員使用它來解決伺服器端預存程序的問題。在現代 MySQL 伺服器版本中，建議使用伺服器端準備好的陳述式來提高效能、可擴展性和記憶體效率。

另請參閱 Connector/J、Connector/ODBC、Connector/PHP、準備好的陳述式。

一種 SQL 資料類型（TINYTEXT、TEXT、MEDIUMTEXT 或 LONGTEXT），用於包含任何種類的字元資料（大小不拘）的物件。用於儲存以文字為基礎的文件，並具有相關的字元集和定序順序。在 MySQL 應用程式中處理 CLOB 的技術會因每個連接器和API而異。MySQL Connector/ODBC 將 TEXT 值定義為 LONGVARCHAR。如需儲存二進位資料，對應的類型為BLOB類型。

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

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

在 Oracle Database 產品中，此類型的資料表稱為索引組織表。

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

在資料庫關閉時進行的備份。對於繁忙的應用程式和網站，這可能不切實際，您可能會更喜歡溫備份或熱備份。

另請參閱 備份、熱備份、溫備份。

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

每個欄位都有一個基數值。一個欄位可以是其資料表的主鍵，或是主鍵的一部分。一個欄位可以受限於唯一約束、NOT NULL 約束或兩者。不同欄位（即使跨不同資料表）中的值可以透過外鍵關係連結。

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

另請參閱 基數、外鍵、索引、NOT NULL 約束、主鍵、資料列、資料表、唯一約束。

單一欄位上的索引。

另請參閱 複合索引、索引。

當使用長度規格建立索引時，例如 CREATE INDEX idx ON t1 (c1(N))，只有欄位值的前 N 個字元會儲存在索引中。保持索引前綴小巧可以使索引緊湊，並且節省記憶體和磁碟 I/O 有助於提高效能。（雖然使索引前綴過小可能會妨礙查詢最佳化，使查詢最佳化器認為具有不同值的資料列是重複的。）

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

另請參閱 索引。

語句攔截器的同義詞。攔截器設計模式的一個方面，適用於 Connector/NET 和 Connector/J。Connector/NET 稱為命令，而 Connector/J 則稱為語句。與例外攔截器相對。

另請參閱 Connector/J、Connector/NET、例外攔截器、攔截器、語句攔截器。

一個 SQL 語句，它結束一個交易，使交易進行的任何變更成為永久性的。它與回滾相反，後者會取消交易中進行的任何變更。

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

預設情況下，MySQL 使用自動提交設定，該設定會在每個 SQL 語句之後自動發出提交。

另請參閱 自動提交、樂觀、回滾、SQL、交易。

InnoDB 資料表的列格式。它是從 MySQL 5.0.3 到 MySQL 5.7.8 的預設列格式。在 MySQL 8.0 中，預設列格式由 innodb_default_row_format 設定選項定義，其預設設定為DYNAMIC。COMPACT 列格式為空值和可變長度欄位提供比REDUNDANT 列格式更緊湊的表示形式。

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

另請參閱 動態列格式、檔案格式、冗餘列格式、列格式。

包含多個欄位的索引。

另請參閱 索引。

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

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

在備份過程開始時套用壓縮有助於避免在壓縮過程中產生儲存額外負荷，並避免在將備份檔案傳輸到另一個伺服器時產生網路額外負荷。套用二進位日誌的過程需要更長的時間，並且需要解壓縮備份檔案。

另請參閱 套用、二進位日誌、壓縮、熱備份、MySQL Enterprise Backup、表空間。

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

有關 InnoDB COMPRESSED 列格式的其他資訊，請參閱 動態列格式。

另請參閱 壓縮、動態列格式、列格式。

將資料以壓縮形式儲存的資料表。對於 InnoDB，它是一個使用 ROW_FORMAT=COMPRESSED 建立的資料表。有關詳細資訊，請參閱 第 17.9 節，「InnoDB 資料表和頁面壓縮」。

另請參閱 壓縮列格式、壓縮。

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

InnoDB 支援資料表級和頁面級壓縮。InnoDB 頁面壓縮也稱為透明頁面壓縮。有關 InnoDB 壓縮的詳細資訊，請參閱 第 17.9 節，「InnoDB 資料表和頁面壓縮」。

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

參閱 緩衝池、壓縮備份、壓縮資料列格式、DML、透明頁面壓縮。

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

參閱 壓縮、DML、頁面。

多個操作（在資料庫術語中為 交易）能夠同時執行，而不會互相干擾的能力。並行也與效能有關，因為理想情況下，針對多個同時交易的保護措施會以最少的效能負擔運作，並使用有效率的機制進行鎖定。

參閱 ACID、鎖定、交易。

此檔案包含 MySQL 在啟動時使用的 選項 值。傳統上，在 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、選項、選項檔案。

應用程式與 MySQL 伺服器之間的通訊通道。資料庫應用程式的效能和可擴展性會受到資料庫連線建立速度、同時建立的數量以及其持續時間的影響。例如 主機、連接埠 等參數會以 Connector/NET 中的 連線字串 和 Connector/ODBC 中的 DSN 表示。高流量系統會使用稱為 連線集區 的最佳化方式。

參閱 連線集區、連線字串、Connector/NET、Connector/ODBC、DSN、主機、連接埠。

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

參閱 連線、Connector/J、J2EE、Tomcat。

資料庫連線的參數表示法，編碼為字串常值，以便在程式碼中使用。字串的各部分表示連線參數，例如 主機 和 連接埠。連線字串包含數個以分號分隔的鍵值組。每個鍵值組都以等號連線。通常與 Connector/NET 應用程式搭配使用；如需詳細資訊，請參閱 建立 Connector/NET 連線字串。

參閱 連線、Connector/NET、主機、連接埠。

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

參閱 API、用戶端、Connector/C++、Connector/J、Connector/NET、Connector/ODBC。

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

參閱 用戶端、連接器、JDBC。

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

參閱 用戶端、用戶端程式庫、連接器、Java、JDBC。

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

參閱 ADO.NET、ASP.net、連接器、C#、Mono、Visual Studio。

MySQL ODBC 驅動程式系列，可使用業界標準的開放資料庫連線能力 (ODBC) API 來存取 MySQL 資料庫。以前稱為 MyODBC 驅動程式。如需完整詳細資訊，請參閱MySQL Connector/ODBC 開發人員指南。

參閱 連接器、ODBC。

適用於 Windows 作業系統最佳化的 mysql 和 mysqli API 版本，適用於 PHP。

參閱 連接器、PHP、PHP API。

一種讀取操作，使用 快照 資訊來呈現基於時間點的查詢結果，而不管同時執行的其他交易進行了哪些變更。如果查詢的資料已被其他交易變更，則會根據 復原記錄 的內容重建原始資料。此技術可避免某些可能會透過強制交易等待其他交易完成而降低並行性的鎖定問題。

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

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

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

參見 並行性、隔離層級、鎖定、讀取已提交、可重複讀取、快照、交易、還原日誌。

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

參見 ACID、外來鍵、唯一約束。

一個由特定種類的 InnoDB 操作遞增的值。可用於測量伺服器的忙碌程度、排除效能問題的來源，以及測試變更（例如，組態設定或查詢使用的索引）是否具有所需的底層效果。不同種類的計數器可透過 效能架構 (Performance Schema) 表格和 INFORMATION_SCHEMA 表格取得，尤其是 INFORMATION_SCHEMA.INNODB_METRICS。

參見 INFORMATION_SCHEMA、度量計數器、效能架構 (Performance Schema)。

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

任何 欄位索引 或 複合索引 在正確的查詢下都可以作為覆蓋索引。請設計您的索引和查詢，盡可能利用此最佳化技術。

參見 欄位索引、複合索引、索引、主索引鍵、次要索引。

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

參見 瓶頸、緩衝池、工作負載。

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

參見 當機復原、快速關機、InnoDB、關機。

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

在正常操作期間，已提交的資料可以在寫入資料檔案之前，於 變更緩衝區 中儲存一段時間。在保持資料檔案最新（會在正常操作期間產生效能負擔）與緩衝資料（可能使關機和當機復原花費更長時間）之間總是存在取捨。

參見 變更緩衝區、提交、當機、資料檔案、雙寫緩衝區、InnoDB、清除 (purge)、重做日誌。

「建立 (create)、讀取 (read)、更新 (update)、刪除 (delete)」的縮寫，是資料庫應用程式中的常見操作序列。通常表示一類資料庫使用相對簡單的應用程式（在 SQL 中的基本 DDL、DML 和 查詢 陳述式），這些應用程式可以使用任何語言快速實作。

參見 DDL、DML、查詢、SQL。

一個代表 SQL 陳述式結果集的內部 MySQL 資料結構。經常與 預備陳述式 和 動態 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 執行個體 (instance) 中保存來自多個資料庫的表格資料，它保存在獨立於各個資料庫目錄之外的資料檔案中。當啟用每表檔案 (file-per-table) 模式時，表示各個 InnoDB 表格的 .ibd 檔案會儲存在資料庫目錄內，除非使用 DATA DIRECTORY 子句將其建立在其他位置。MySQL 5.7.6 中引入的一般表空間，也會將表格資料儲存在 .ibd 檔案中。與每表檔案的 .ibd 檔案不同，一般表空間的 .ibd 檔案可以保存來自 MySQL 執行個體 (instance) 中多個資料庫的表格資料，並且可以指定到相對於 MySQL 資料目錄或獨立於 MySQL 資料目錄的目錄。

對於長期的 MySQL 使用者來說，資料庫是一個熟悉的概念。來自 Oracle Database 背景的使用者可能會發現，MySQL 中資料庫的意義更接近 Oracle Database 所稱的綱要 (schema)。

另請參閱 資料檔案 (data files)、每表檔案 (file-per-table)、.ibd 檔案 (.ibd file)、執行個體 (instance)、綱要 (schema)、系統表空間 (system tablespace)。

資料控制語言，一組用於管理權限的 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 陳述式會自動提交 (commit) 當前的交易 (transaction)；它們不能被回滾 (rolled back)。

InnoDB 的線上 DDL 功能增強了 CREATE INDEX、DROP INDEX 和多種類型的 ALTER TABLE 操作的效能。有關更多資訊，請參閱 第 17.12 節「InnoDB 和線上 DDL」。此外，InnoDB 的每表檔案 (file-per-table) 設定可能會影響 DROP TABLE 和 TRUNCATE TABLE 操作的行為。

與 DML 和 DCL 相對。

另請參閱 提交 (commit)、DCL、DML、每表檔案 (file-per-table)、回滾 (rollback)、SQL、交易 (transaction)。

一種不同交易 (transactions)無法繼續的情況，因為每個交易都持有另一個交易需要的鎖定 (lock)。由於兩個交易都在等待資源變得可用，因此沒有一個交易會釋放其持有的鎖定。

當交易以相反的順序鎖定多個表格中的列時（透過諸如 UPDATE 或 SELECT ... FOR UPDATE 等陳述式），可能會發生死結。當這些陳述式鎖定索引記錄和間隙 (gaps)的範圍時，由於時序問題，每個交易都獲得了一些鎖定，但未獲得其他鎖定，也可能會發生死結。

有關如何自動偵測和處理死結的背景資訊，請參閱 第 17.7.5.2 節「死結偵測」。有關避免和從死結情況恢復的提示，請參閱 第 17.7.5.3 節「如何盡量減少和處理死結」。

另請參閱 間隙 (gap)、鎖定 (lock)、交易 (transaction)。

一種自動偵測何時發生死結 (deadlock)的機制，並自動回滾 (rolls back)其中一個相關的交易 (transactions)（受害者 (victim)）。可以使用 innodb_deadlock_detect 組態選項停用死結偵測。

另請參閱 死結 (deadlock)、回滾 (rollback)、交易 (transaction)、受害者 (victim)。

當 InnoDB 處理 DELETE 陳述式時，這些列會立即標記為刪除，並且查詢不再傳回這些列。儲存空間會在稍後（在稱為清除 (purge)操作的定期垃圾收集期間）回收。對於刪除大量資料，相關的操作及其效能特性為TRUNCATE 和 DROP。

另請參閱 捨棄 (drop)、清除 (purge)、截斷 (truncate)。

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

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

一種跨不同表格複製資料的資料儲存策略，而不是使用外部鍵 (foreign keys)和聯結 (join)查詢來連結表格。通常用於資料倉儲 (data warehouse)應用程式中，其中資料在載入後不會更新。在這種應用程式中，查詢效能比在更新期間簡化維護一致的資料更重要。與正規化 (normalized)相對。

另請參閱 資料倉儲 (data warehouse)、外部鍵 (foreign key)、聯結 (join)、正規化 (normalized)。

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

另請參閱 索引。

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

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

另請參閱 資料字典 (data dictionary)、LRU。

InnoDB 緩衝池 (buffer pool)中的頁面 (page)，已在記憶體中更新，但變更尚未寫入（刷新 (flushed)）至資料檔案 (data files)。與乾淨頁 (clean page)相反。

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

一種檢索不可靠資料的操作，該資料是由另一個交易更新但尚未提交 (committed)的資料。只有使用稱為讀取未提交 (read uncommitted)的隔離等級 (isolation level)才有可能發生。

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

它的相反是一致性讀取，其中 InnoDB 確保即使其他交易在此期間提交，交易也不會讀取其他交易更新的資訊。

另請參閱 ACID、提交 (commit)、一致性讀取 (consistent read)、隔離級別 (isolation level)、READ UNCOMMITTED、回滾 (rollback)。

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

另請參閱 自適應雜湊索引 (adaptive hash index)、緩衝池 (buffer pool)、記憶體內資料庫 (in-memory database)。

一種工作負載 (workload)類型，其中主要的瓶頸 (bottleneck)是磁碟 I/O。（也稱為I/O 受限 (I/O-bound)。）通常涉及頻繁地寫入磁碟，或隨機讀取比緩衝池 (buffer pool)能容納的更多資料。

參見 瓶頸、緩衝池、工作負載。

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

用於 InnoDB 資料表的 DML 陳述式在交易 (transaction) 的上下文中運作，因此它們的效果可以作為一個單元提交 (committed) 或回滾 (rolled back)。

與 DDL 和 DCL 對比。

另請參閱 提交 (commit)、DCL、DDL、鎖定 (locking)、回滾 (rollback)、SQL、交易 (transaction)。

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

另請參閱 全文檢索 (full-text search)、FULLTEXT 索引、ilist。

InnoDB 使用一種稱為雙寫的檔案刷新技術。在將頁面 (pages) 寫入資料檔 (data files) 之前，InnoDB 會先將它們寫入稱為雙寫緩衝區的儲存區域。只有在寫入和刷新到雙寫緩衝區完成後，InnoDB 才會將頁面寫入它們在資料檔中的正確位置。如果作業系統、儲存子系統或 mysqld 程序在頁面寫入過程中崩潰，InnoDB 可以在崩潰恢復 (crash recovery) 期間從雙寫緩衝區中找到頁面的良好副本。

雖然資料總是寫入兩次，但雙寫緩衝區不需要兩倍的 I/O 額外負荷或兩倍的 I/O 操作次數。資料會以大型循序區塊的形式寫入緩衝區本身，並對作業系統進行單一 fsync() 呼叫。

另請參閱 崩潰恢復 (crash recovery)、資料檔 (data files)、頁面 (page)、清除 (purge)。

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

另請參閱 緩衝池 (buffer pool)、資料字典 (data dictionary)、DDL、資料表 (table)、截斷 (truncate)。

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

另請參閱 連線 (connection)、連線字串 (connection string)、Connector/NET、Connector/ODBC。

ODBC 支援的一種游標 (cursor)類型，可以在再次讀取列時取得新的和變更的結果。變更對游標的可見程度和速度取決於所涉及的資料表類型（交易式或非交易式）以及交易式資料表的隔離級別。必須明確啟用對動態游標的支援。

另請參閱 游標 (cursor)、ODBC。

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

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

如需有關 InnoDB DYNAMIC 列格式的詳細資訊，請參閱 動態列格式。

另請參閱 緩衝池 (buffer pool)、檔案格式 (file format)、列格式 (row format)。

一種讓您使用比將陳述式的各部分串連到字串變數的簡單技術更穩固、安全且有效率的方法，來建立和執行預處理陳述式 (prepared statements)的功能。

另請參閱 預處理陳述式 (prepared statement)。

一個透過動態 SQL (dynamic SQL) 建立和執行的預處理陳述式 (prepared statement)。

另請參閱 動態 SQL (dynamic SQL)、預處理陳述式 (prepared statement)。

與 beta 類似的階段，當軟體產品通常在非關鍵任務環境中評估效能、功能和相容性時。

另請參閱 beta。

一種包含許多物件導向功能的程式語言。它的一些概念對於 Java 和 C# 開發人員來說很熟悉。如需適用於 MySQL 的開放原始碼 Eiffel API，請參閱 章節 31.13，「MySQL Eiffel Wrapper」。

參閱 API、C#、Java。

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

參閱 用戶端 (client)、libmysqld。

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

參閱 當機 (crash)、日誌 (log)。

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

參閱 緩衝池 (buffer pool)、髒頁 (dirty page)、刷新 (flush)、LRU、相鄰頁 (neighbor page)。

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

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

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

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

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

參閱 並行性 (concurrency)、一致讀取 (consistent read)、隔離等級 (isolation level)、鎖定 (lock)、可重複讀取 (REPEATABLE READ)、共用鎖定 (shared lock)、交易 (transaction)。

表空間內的一組頁面。對於預設的 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 操作。

參閱 雙寫緩衝區 (doublewrite buffer)、頁面 (page)、頁面大小 (page size)、預讀 (read-ahead)、區段 (segment)、表空間 (tablespace)。

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

參閱 資料字典 (data dictionary)、MySQL Enterprise Backup、系統表空間 (system tablespace)。

在發生故障時自動切換到備用伺服器的能力。在 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、索引 (index)、線上 DDL (online DDL)、次要索引 (secondary index)。

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

參閱 當機復原 (crash recovery)、資料檔案 (data files)、刷新 (flush)、關機 (shutdown)、慢速關機 (slow shutdown)。

InnoDB 資料表的檔案格式。

參閱 每表一檔 (file-per-table)、.ibd 檔案 (.ibd file)、ibdata 檔案 (ibdata file)、列格式 (row format)。

由 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 定期刷新的儲存結構包括重做日誌、復原日誌和緩衝池。

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

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

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

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

一種指標關係，存在於不同 InnoDB 表格中的資料列之間。外部索引鍵關係定義在父表格和子表格的同一個欄位上。

除了可以快速查詢相關資訊外，外部索引鍵還可以透過防止任何此類指標在插入、更新和刪除資料時失效，來幫助強制執行參照完整性。此強制機制是一種約束。如果另一個表格中不存在相關的外部索引鍵值，則無法插入指向另一個表格的資料列。如果刪除資料列或變更其外部索引鍵值，且另一個表格中的資料列指向該外部索引鍵值，則可以設定外部索引鍵以防止刪除、使另一個表格中的相應欄位值變為null，或自動刪除另一個表格中的相應資料列。

設計正規化資料庫的階段之一是識別重複的資料，將該資料分隔到一個新的表格中，並建立外部索引鍵關係，以便可以使用聯結操作像查詢單一表格一樣查詢多個表格。

另請參閱子表格、外部索引鍵約束、聯結、正規化、NULL、父表格、參照完整性、關聯式。

透過外部索引鍵關係維護資料庫一致性的約束類型。與其他類型的約束一樣，如果資料變得不一致，它可以防止資料被插入或更新；在這種情況下，所防止的不一致性是多個表格中的資料之間的不一致性。或者，當執行 DML 操作時，FOREIGN KEY 約束可能會導致子資料列中的資料被刪除、變更為不同的值或設定為null，具體取決於建立外部索引鍵時指定的 ON CASCADE 選項。

另請參閱子表格、約束、DML、外部索引鍵、NULL。

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

另請參閱全表掃描、全文檢索。

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

另請參閱備份、資料庫、執行個體、部分備份、表格。

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

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

另請參閱緩衝池、索引。

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

另請參閱FULLTEXT 索引。

一種特殊的索引，它會在 MySQL 全文檢索機制中保留搜尋索引。表示欄位值的字詞，省略任何指定為停用字的字詞。最初僅適用於 MyISAM 表格。從 MySQL 5.6.4 開始，也適用於InnoDB 表格。

另請參閱全文檢索、索引、InnoDB、搜尋索引、停用字。

一種技術，會從緩衝池刷新小批量的髒頁，而不是一次刷新所有髒頁，那樣會中斷資料庫處理。

另請參閱緩衝池、髒頁、刷新。

“正式發佈”，指軟體產品離開測試版 (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; 會阻止其他交易將值 15 插入 t.c1 資料行，無論該資料行中是否已存在任何此類值，因為範圍內所有現有值之間的間隙都被鎖定。與紀錄鎖定 (record lock)和下一個鍵鎖定 (next-key lock)形成對比。

間隙鎖定是效能和並行 (concurrency)之間的權衡的一部分，並且在某些交易隔離等級 (isolation levels)中使用，而在其他交易隔離等級 (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 資料表的主鍵的有效值。

一種索引 (index)類型，適用於使用等號運算子而非範圍運算子（例如大於或 BETWEEN）的查詢。 它適用於 MEMORY 資料表。 雖然雜湊索引因歷史原因而是 MEMORY 資料表的預設值，但該儲存引擎也支援B 樹 (B-tree) 索引，這通常是通用查詢的更好選擇。

MySQL 包含此索引類型的一種變體，即 自適應雜湊索引 (adaptive hash index)，該索引會根據執行階段條件，自動為 InnoDB 資料表建構。

另請參閱 自適應雜湊索引 (adaptive hash index), B 樹 (B-tree), 索引 (index), InnoDB。

“硬碟機 (hard disk drive)” 的縮寫。通常在與 SSD 進行比較和對比時，是指使用旋轉磁片的儲存媒體。 它的效能特徵會影響基於磁碟 (disk-based)工作負載的輸送量。

另請參閱 基於磁碟 (disk-based), SSD。

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

另請參閱 複製 (replication)、來源 (source)。

代表上限的值，可以是執行時不應超過的硬性限制，或是實際達到的最大值的記錄。與低水位標記對照。

另請參閱 低水位標記 (low-water mark)。

包含標記為刪除的交易列表，這些交易排定由 InnoDB 的清除操作處理。記錄在復原日誌中。歷史記錄列表的長度由指令 SHOW ENGINE INNODB STATUS 報告。如果歷史記錄列表的長度超過 innodb_max_purge_lag 設定選項的值，則每個DML 操作都會稍微延遲，以便讓清除操作完成刷新已刪除的記錄。

也稱為清除延遲。

另請參閱 DML、刷新 (flush)、清除 (purge)、清除延遲 (purge lag)、回滾區段 (rollback segment)、交易 (transaction)、復原日誌 (undo log)。

從頁面釋放空的區塊。InnoDB 的透明頁面壓縮功能依賴空洞填補支援。如需詳細資訊，請參閱第 17.9.2 節「InnoDB 頁面壓縮」。

另請參閱 稀疏檔案 (sparse file)、透明頁面壓縮 (transparent page compression)。

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

另請參閱 連線 (connection)、本機主機 (localhost)、埠 (port)。

指的是某個資料列、資料表或內部資料結構被過於頻繁地存取，以至於需要某種形式的鎖定或互斥，因而導致效能或可擴展性問題。

雖然「熱點」通常表示不希望發生的情況，但熱備份是較佳的備份類型。

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

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

執行熱備份的 Oracle 產品，特別是針對 InnoDB 資料表，但也包括 MyISAM 和其他儲存引擎的資料表，稱為MySQL Enterprise Backup。

熱備份程序包含兩個階段。初始複製資料檔案會產生原始備份。 套用步驟會將備份執行時發生的任何資料庫變更納入。套用變更會產生已準備的備份；這些檔案已準備好在必要時還原。

另請參閱 套用 (apply)、MySQL Enterprise Backup、已準備的備份 (prepared backup)、原始備份 (raw backup)。

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

.ibd 檔案副檔名不適用於系統表空間，系統表空間由一個或多個ibdata 檔案組成。

如果使用 DATA DIRECTORY = 子句建立單表表空間或一般表空間，則 .ibd 檔案會位於指定的路徑，而非一般的資料目錄中。

當 .ibd 檔案由MySQL Enterprise Backup產品包含在壓縮備份中時，壓縮後的對應檔案會是 .ibz 檔案。

另請參閱 資料庫 (database)、單表 (file-per-table)、一般表空間 (general tablespace)、ibdata 檔案 (ibdata file)、.ibz 檔案 (.ibz file)、innodb_file_per_table、MySQL Enterprise Backup、系統表空間 (system tablespace)。

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

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

另請參閱 壓縮備份 (compressed backup)、壓縮資料列格式 (compressed row format)、單表 (file-per-table)、.ibd 檔案 (.ibd file)、MySQL Enterprise Backup、表空間 (tablespace)。

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

另請參閱 資料庫 (database)、單表 (file-per-table)、一般表空間 (general tablespace)、重做日誌 (redo log)、系統表空間 (system tablespace)、暫時表空間 (temporary tablespace)、復原表空間 (undo tablespace)。

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

另請參閱 套用 (apply)、熱備份 (hot backup)、MySQL Enterprise Backup、已準備的備份 (prepared backup)、原始備份 (raw backup)。

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

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

另請參閱 變更緩衝區 (change buffer)、資料字典 (data dictionary)、雙寫緩衝區 (doublewrite buffer)、單表 (file-per-table)、.ibd 檔案 (.ibd file)、innodb_file_per_table、系統表空間 (system tablespace)、復原日誌 (undo log)。

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

另請參閱 資料檔案、臨時表、臨時表空間。

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

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

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

在 InnoDB 全文索引中，包含文件 ID 和符記（即特定詞語）位置資訊的資料結構。

另請參閱FULLTEXT 索引。

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 控制。

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

索引條件下推 (ICP) 是一種最佳化，如果可以使用索引中的欄位評估條件的一部分，則會將 WHERE 條件的一部分下推到儲存引擎。ICP 可以減少儲存引擎必須存取基底表格的次數，以及 MySQL 伺服器必須存取儲存引擎的次數。如需更多資訊，請參閱 第 10.2.1.6 節「索引條件下推最佳化」。

另請參閱 索引、儲存引擎。

用於覆寫最佳化工具建議的索引的擴充 SQL 語法。例如，FORCE INDEX、USE INDEX 和 IGNORE INDEX 子句。通常用於索引欄具有不均勻分佈的值，導致基數估計不準確的情況。

另請參閱 基數、索引。

在套用至多個欄的索引中（稱為複合索引），該索引的初始或前導欄。引用複合索引的前 1、2、3 等欄的查詢可以使用該索引，即使查詢沒有引用索引中的所有欄。

另請參閱 複合索引、索引。

索引中的虛擬記錄，表示該索引中最小值的間隔。如果交易具有諸如 SELECT ... FROM ... WHERE col < 10 FOR UPDATE; 的語句，且該欄中的最小值為 5，則對下限記錄的鎖定會阻止其他交易插入更小的值，例如 0、-10 等等。

另請參閱 間隔、索引、虛擬記錄、上限記錄。

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

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

另請參閱 資料字典、資料庫、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、熱備份、MySQL Enterprise Backup、儲存引擎、交易。

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) 是預設值，這反映了從基於陳述式到基於列的複寫作為預設複寫類型的變更。

另請參閱 自動遞增、自動遞增鎖定、混合模式插入、主鍵。

一個重要的組態選項，它會影響 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 節，「每個表格一個檔案的表空間」。

另請參閱 壓縮、每個表格一個檔案、.ibd 檔案、MySQL Enterprise Backup、系統表空間。

innodb_lock_wait_timeout 選項設定以下兩者之間的平衡：等待共用資源變成可用，或者放棄並處理錯誤、重試或在您的應用程式中執行替代處理。回溯任何等待超過指定時間以取得 鎖定 的 InnoDB 交易。如果不同儲存引擎控制的多個表格的更新導致 死結，這特別有用；此類死結不會自動偵測到。

另請參閱 死結、死結偵測、鎖定、等待。

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

另請參閱 嚴格模式。

具有相同主要版本的 Innovation 版本會形成一個 Innovation 系列。例如，MySQL 8.1 到 8.3 形成 MySQL 8 Innovation 系列。

另請參閱 LTS 系列。

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

另請參閱 自動遞增、變更緩衝、資料倉儲、DML、InnoDB、插入緩衝區、OLTP、SQL。

變更緩衝區 的舊名稱。在 MySQL 5.5 中，新增了支援緩衝針對 DELETE 和 UPDATE 操作的次要索引頁面的變更。先前，只有來自 INSERT 操作的變更會被緩衝。慣用術語現在是變更緩衝區。

另請參閱 變更緩衝區、變更緩衝。

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

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

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

一種由 INSERT 操作在插入列之前設定的間隙鎖定 (gap lock)。此類型的 鎖定 (lock) 表示插入意圖，如此一來，多個交易在同一個索引間隙中插入時，如果它們不是在間隙內的同一位置插入，則不需要互相等待。更多資訊請參閱第 17.7.1 節「InnoDB 鎖定」。

另請參閱 間隙鎖定 (gap lock)、鎖定 (lock)、next-key 鎖定。

一個管理 資料目錄 (data directory) 的 mysqld 精靈，該資料目錄代表一個或多個具有一組 表格 (tables) 的 資料庫 (databases)。在開發、測試和某些 複寫 (replication) 情況下，通常會在同一台 伺服器 (server) 機器上有多個實例，每個實例管理自己的資料目錄並監聽自己的連接埠或通訊端。當一個實例執行 磁碟受限 (disk-bound) 工作負載時，伺服器可能仍然有額外的 CPU 和記憶體容量來執行其他實例。

另請參閱 資料目錄 (data directory)、資料庫 (database)、磁碟受限 (disk-bound)、mysqld、複寫 (replication)、伺服器 (server)、表格 (table)。

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

另請參閱 INFORMATION_SCHEMA、Performance Schema。

一種適用於表格的 鎖定 (lock)，用於指示交易 (transaction)打算在表格中的列上取得的鎖定種類。不同的交易可以在同一個表格上取得不同種類的意圖鎖定，但是第一個在表格上取得意圖獨佔 (IX) 鎖定的交易會阻止其他交易在表格上取得任何 S 或 X 鎖定。相反地，第一個在表格上取得意圖共享 (IS) 鎖定的交易會阻止其他交易在表格上取得任何 X 鎖定。兩階段流程允許按順序解析鎖定請求，而不會阻擋相容的鎖定和對應的操作。有關此鎖定機制的更多資訊，請參閱第 17.7.1 節「InnoDB 鎖定」。

另請參閱 鎖定 (lock)、鎖定模式 (lock mode)、鎖定 (locking)、交易 (transaction)。

用於檢測或除錯應用程式某些方面的程式碼，可以在不重新編譯或變更應用程式本身來源的情況下啟用。

另請參閱 命令攔截器 (command interceptor)、Connector/J、Connector/NET、例外攔截器 (exception interceptor)。

由最佳化工具 (optimizer)使用的最佳化內部 InnoDB 臨時表。

另請參閱 最佳化工具 (optimizer)。

一種針對文件檢索系統最佳化的資料結構，用於實作 InnoDB 全文檢索 (full-text search)。InnoDB FULLTEXT 索引以反向索引的形式實作，記錄每個單字在文件中的位置，而不是表格列的位置。單個列值（以文字字串形式儲存的文件）在反向索引中由多個項目表示。

另請參閱 全文檢索 (full-text search)、FULLTEXT 索引、ilist。

每秒 I/O 操作 (I/O operations per second)的縮寫。繁忙系統的常用衡量指標，尤其是OLTP應用程式。如果此值接近儲存裝置可處理的最大值，則應用程式可能會變成磁碟受限 (disk-bound)，從而限制可擴展性 (scalability)。

另請參閱 磁碟受限 (disk-bound)、OLTP、可擴展性 (scalability)。

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

從最高的一致性和保護程度到最低，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、交易 (transaction)。

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 堆疊中經常提供的與資料庫相關的功能包括連線池 (connection pool)和容錯移轉 (failover)支援。

另請參閱 連線池 (connection pool)、Connector/J、容錯移轉 (failover)、Java、JBoss、Spring、Tomcat。

一種結合高效能、豐富的內建功能和資料類型、物件導向機制、廣泛的標準程式庫以及各種可重複使用的協力廠商模組的程式語言。許多框架、應用程式伺服器和其他技術支援企業開發。其許多語法對於 C 和 C++ 開發人員來說很熟悉。要使用 MySQL 編寫 Java 應用程式，您可以使用稱為 Connector/J 的 JDBC 驅動程式。

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

另請參閱 J2EE。

「Java 資料庫連線能力」的縮寫，是從 Java 應用程式存取資料庫的 API。編寫 MySQL 應用程式的 Java 開發人員使用 Connector/J 元件作為其 JDBC 驅動程式。

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

另請參閱 Java。

一個查詢，透過參照表中具有相同值的欄位，從多個表格中檢索資料。理想情況下，這些欄位是 InnoDB 外來鍵 關係的一部分，這可確保參考完整性，並且聯接欄位已建立索引。在正規化的資料設計中，通常透過將重複字串替換為數字 ID 來節省空間並提高查詢效能。

另請參閱 外來鍵、索引、正規化、查詢、參考完整性。

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

另請參閱 驗證伺服器、票證授權票證。

另請參閱 SSL。

用於指定使用壓縮列格式的 InnoDB 表格中資料頁面大小的選項。預設值為 8 KB。較低的值可能會觸及取決於列大小和壓縮百分比組合的內部限制。

對於 MyISAM 表格，KEY_BLOCK_SIZE 可選擇性地指定用於索引金鑰區塊的大小 (以位元組為單位)。該值被視為提示；如果需要，可以使用不同的尺寸。為個別索引定義指定的 KEY_BLOCK_SIZE 值會覆寫表格層級的 KEY_BLOCK_SIZE 值。

另請參閱 壓縮列格式。

InnoDB 用於為其內部記憶體結構實作鎖定的輕量型結構，通常保持很短的時間，以毫秒或微秒為單位測量。一個通用術語，包括 互斥鎖（用於獨佔存取）和 讀寫鎖（用於共享存取）。某些閂鎖是 InnoDB 效能調整的重點。透過 效能架構介面，可以取得閂鎖使用和競爭的統計資料。

另請參閱 鎖定、鎖定、互斥鎖、效能架構、讀寫鎖。

libmysqlclient 程式庫的非正式名稱。

另請參閱 libmysqlclient。

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

另請參閱 用戶端、libmysql、mysqlclient。

這個嵌入式 MySQL 伺服器程式庫，讓在用戶端應用程式內執行功能完整的 MySQL 伺服器成為可能。主要優點是加快速度，並簡化嵌入式應用程式的管理。您連結的會是 libmysqld 程式庫，而不是 libmysqlclient。這三個程式庫之間的 API 完全相同。

另請參閱 用戶端、嵌入式、libmysql、libmysqlclient。

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

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

InnoDB 緩衝池是以記憶體頁面列表表示的。當存取新頁面並進入緩衝池時，當緩衝池中的頁面被再次存取並被視為較新時，以及當長時間未存取的頁面從緩衝池中逐出時，會重新排序列表。緩衝池分為子列表，而取代原則是熟悉之LRU技術的變體。

另請參閱 緩衝池、逐出、LRU、頁面、子列表。

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

參閱 Connector/J、J2EE。

另請參閱 連線。

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

另請參閱 閂鎖、鎖定模式、鎖定、互斥鎖。

某些資料庫系統中使用的作業，可將許多列鎖定轉換為單一表格鎖定，以節省記憶體空間，但會減少對表格的並行存取。InnoDB 使用節省空間的列鎖定表示法，因此不需要鎖定升級。

另請參閱 鎖定、列鎖定、表格鎖定。

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

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

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

另請參閱 意圖鎖定、鎖定、鎖定、交易。

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

另請參閱 ACID、並行、隔離層級、鎖定、交易。

一個 SELECT 語句，它也會對 InnoDB 表執行鎖定操作。例如 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE。根據事務的隔離層級，它有可能產生死鎖。與非鎖定讀取相反。不允許在唯讀事務中用於全域表格。

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

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

另請參閱 死鎖、隔離層級、鎖定、非鎖定讀取、唯讀事務。

在 InnoDB 的上下文中，「日誌 (log)」或 「日誌檔案 (log files)」通常指的是由 ib_logfileN 檔案表示的重做日誌 (redo log)。另一種 InnoDB 日誌是復原日誌 (undo log)，它是一個儲存區域，用於保存活動交易所修改的資料副本。

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

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

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

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

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

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

構成重做日誌的檔案集合，通常命名為 ib_logfile0 和 ib_logfile1。（因此，有時也統稱為ib_logfile。）

另請參閱 ib_logfile、重做日誌。

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

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

一種重新產生表格結構和資料的備份 (backup)，而不複製實際的資料檔案。例如，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)的時間點。mysqlbackup 命令的輸出會顯示相關的 LSN。一旦您擁有與完整備份時間對應的 LSN，您就可以指定該值來取得後續的增量備份，其輸出包含另一個 LSN，用於下一個增量備份。

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

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

注意：MySQL 8.0 是 LTS 版本模型之前的錯誤修正系列。

另請參閱 創新系列。

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

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

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

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

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

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

一個 InnoDB 執行緒，在背景執行各種任務。這些任務大多與 I/O 相關，例如將變更緩衝區中的變更寫入到適當的次要索引。

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

另請參閱 緩衝池、變更緩衝區、並行性、髒頁、刷新、頁面清理器、執行緒。

「中繼資料鎖定」的縮寫。

另請參閱 中繼資料鎖定。

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

另請參閱 Connector/NET、部分信任。

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

另請參閱 NoSQL。

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

另請參閱 緩衝池、變更緩衝區、刷新、表空間。

一種鎖定類型，可防止在另一個交易同時使用表格時對其執行DDL 作業。如需詳細資訊，請參閱 第 10.11.4 節「中繼資料鎖定」。

在 MySQL 5.6 及更高版本中，對線上操作的增強主要集中在減少中繼資料鎖定的次數。目標是讓不變更表格結構的 DDL 操作（例如 CREATE INDEX 和 DROP INDEX，適用於 InnoDB 表格）在表格被其他交易查詢、更新等時繼續進行。

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

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

另請參閱 計數器、INFORMATION_SCHEMA、效能架構。

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

另請參閱 緩衝池、完整表格掃描、LRU、頁面。

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

另請參閱 提交、當機復原、DML、實體、清除、重做記錄、回滾、交易。

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

可能會導致來源和複本伺服器在複製組態中的一致性問題。可能需要調整innodb_autoinc_lock_mode組態選項的值。

另請參閱 自動遞增、innodb_autoinc_lock_mode、複本、複製、來源。

一個較舊的 MySQL JDBC 驅動程式，當其與 MySQL 產品整合時，已發展成 Connector/J。

另請參閱 Connector/J。

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

另請參閱 Connector/NET、C#。

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

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

另請參閱 閂鎖、鎖定、效能架構、Pthreads、rw-lock。

「多版本並行控制」的縮寫。此技術可讓具有特定隔離層級的 InnoDB 交易執行一致讀取操作；也就是說，查詢正在由其他交易更新的列，並查看這些更新發生之前的值。這是一種強大的技術，可透過允許查詢繼續進行而無需因其他交易所持有的鎖定而等待，從而提高並行性。

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

參見 ACID、並行性 (concurrency)、一致性讀取 (consistent read)、隔離層級 (isolation level)、鎖定 (lock)、交易 (transaction)。

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

參見 my.ini、選項檔案 (option file)。

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

參見 my.cnf、選項檔案 (option file)。

Connector/ODBC 的過時名稱。

參見 Connector/ODBC。

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

參見 mysqld、SQL。

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

參見 熱備份 (hot backup)、InnoDB。

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

參見 熱備份 (hot backup)、MySQL Enterprise Backup、暖備份 (warm backup)。

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

另請參閱 libmysqlclient。

mysqld，也稱為 MySQL Server，是一個單一多執行緒程式，它在 MySQL 安裝中執行大部分的工作。它不會產生額外的處理序。MySQL Server 管理對包含資料庫、資料表和其他資訊 (例如記錄檔和狀態檔) 的 MySQL 資料目錄的存取。

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

參見 執行個體 (instance)、mysql。

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

參見 Python、Python API。

一個命令，可執行某些資料庫、資料表和資料表資料的邏輯備份。結果是重新產生原始結構描述物件、資料或兩者的 SQL 陳述式。對於大量資料，例如 MySQL Enterprise Backup 等 實體備份解決方案速度更快，尤其是在 還原操作時。

參見 邏輯備份 (logical backup)、MySQL Enterprise Backup、實體備份 (physical backup)、還原 (restore)。

參見 ADO.NET、ASP.net、Connector/NET、Mono、Visual Studio。

libmysqlclient 的同義詞。

參見 libmysql。

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

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

參見 自動遞增 (auto-increment)、叢集索引 (clustered index)、主索引鍵 (primary key)、次要索引 (secondary index)、合成索引鍵 (synthetic key)。

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

參見 髒頁 (dirty page)、範圍 (extent)、清除 (flush)、頁面 (page)。

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

參見 間隙鎖定 (gap lock)、鎖定 (locking)、記錄鎖定 (record lock)。

未使用 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 為了向後相容仍然可用。

參見 鎖定讀取 (locking read)、查詢 (query)、唯讀交易 (read-only transaction)。

查詢擷取資料的情況，以及相同交易中的後續查詢擷取應該是相同資料，但查詢會傳回不同結果 (在此期間由另一個交易提交變更)。

這種操作與資料庫設計的 ACID 原則背道而馳。在交易中，資料應該是一致的，並具有可預測和穩定的關係。

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

參見 ACID、一致性讀取 (consistent read)、隔離層級 (isolation level)、READ UNCOMMITTED、REPEATABLE READ、SERIALIZABLE、交易 (transaction)。

與非同步 I/O 意義相同的產業術語。

另請參閱 非同步 I/O。

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

例如，可以給定地址一個唯一的 ID，以便人口普查資料庫可以將該 ID 與家庭的每個成員相關聯，而不是儲存複雜值 (例如 美國 AnyTown 主要街道 123 號) 的多個副本，來表示 住在此地址的關係。

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

並非總是建議標準化。主要用於查詢，且僅透過完全刪除並重新載入來更新的資料，通常會保留在較少、較大的表格中，並包含重複的值。這種資料表示方式稱為反正規化，並且經常在資料倉儲應用程式中看到。

參見 反正規化、外鍵、OLTP、關聯式。

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

參見 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、暖備份。

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

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

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

參見 DDL、快速索引建立、線上。

一種為關聯式資料庫系統的低階實作決策提供指導的方法。關聯式資料庫中效能和並行性的要求表示必須快速開始或調度作業。一致性和參考完整性的要求表示任何作業都可能失敗：交易可能會被復原，DML 作業可能會違反約束，對鎖定的請求可能會導致死結，網路錯誤可能會導致逾時。樂觀策略是一種假設大多數請求或嘗試都成功的策略，因此為失敗情況所做的準備工作相對較少。當此假設為真時，資料庫不會執行不必要的工作；當請求確實失敗時，必須執行額外的工作來清理和復原變更。

InnoDB 將樂觀策略用於諸如鎖定和提交等作業。例如，交易變更的資料可以在提交發生之前寫入資料檔案，這使得提交本身速度非常快，但如果交易被復原，則需要更多工作來復原變更。

樂觀策略的反面是悲觀策略，即系統經過最佳化以處理不可靠且經常不成功的作業。這種方法在資料庫系統中很少見，因為在選擇可靠的硬體、網路和演算法時會非常謹慎。

參見 提交、並行性、DML、鎖定、悲觀、參考完整性。

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

參見 索引、聯結、查詢、表格。

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

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

另請參閱 InnoDB、選項、選項檔案。

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

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

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

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

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

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

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

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

在每個頁面中容納更多資料的一種方法是使用壓縮列格式 (compressed row format)。對於使用 BLOB 或大型文字欄位的資料表，精簡列格式 (compact row format) 允許將這些大型欄位與其餘列分開儲存，從而減少不引用這些欄位的查詢的 I/O 開銷和記憶體使用量。

當 InnoDB 以批次方式讀取或寫入頁面集以提高 I/O 吞吐量時，它會一次讀取或寫入一個區 (extent)。

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

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

一個 InnoDB 背景執行緒 (thread)，它會將髒頁 (dirty pages) 從緩衝池刷新 (flushes)。在 MySQL 5.6 之前，此活動由主執行緒 (master thread)執行。頁面清理器執行緒的數量由 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 實例 (instance)的頁面大小可以是 4KB、8KB 或 16KB，由 innodb_page_size 組態選項控制。從 MySQL 5.7.6 開始，InnoDB 也支援 32KB 和 64KB 的頁面大小。對於 32KB 和 64KB 的頁面大小，不支援 ROW_FORMAT=COMPRESSED，並且最大記錄大小為 16KB。

頁面大小在建立 MySQL 實例時設定，之後保持不變。相同的頁面大小適用於所有 InnoDB 表空間 (tablespaces)，包括系統表空間 (system tablespace)、每個資料表表空間 (file-per-table) 和通用表空間 (general tablespaces)。

較小的頁面大小可以幫助使用小區塊大小的儲存裝置提高效能，尤其是在磁碟受限 (disk-bound)工作負載中的SSD裝置，例如OLTP應用程式。當更新單獨的列時，複製到記憶體、寫入磁碟、重新組織、鎖定等的資料較少。

另請參閱 磁碟受限 (disk-bound)、每個資料表 (file-per-table)、通用表空間 (general tablespace)、實例 (instance)、OLTP、頁面 (page)、SSD、系統表空間 (system tablespace)、表空間 (tablespace)。

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

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

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

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

僅表示欄位值一部分的索引 (index)，通常是長 VARCHAR 值的前 N 個字元（字首 (prefix)）。

另請參閱 索引 (index)、索引字首 (index prefix)。

通常由託管提供者使用的執行環境，其中應用程式具有某些權限但沒有其他權限。例如，應用程式可能可以透過網路存取資料庫伺服器，但對於讀取和寫入本機檔案而言，會被「沙箱化 (sandboxed)」。

另請參閱 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 資料表的索引統計資料儲存在磁碟上的功能，為查詢 (queries)提供更好的計劃穩定性 (plan stability)。有關詳細資訊，請參閱第 17.8.10.1 節，「設定持久最佳化工具統計資料參數」。

另請參閱 索引 (index)、最佳化工具 (optimizer)、計劃穩定性 (plan stability)、查詢 (query)、資料表 (table)。

一種為了安全而犧牲效能或並行性的方法。如果高比例的請求或嘗試可能會失敗，或者如果請求失敗的後果很嚴重，則適合使用此方法。InnoDB 使用一種稱為悲觀式鎖定策略，以盡量減少死鎖的機會。在應用程式層級，您可以在交易開始時就取得交易所需的所有鎖，以此悲觀策略來避免死鎖。

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

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

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

這種情況稱為幻讀。它比不可重複讀取更難以防範，因為鎖定第一個查詢結果集中的所有列並不能阻止導致幻讀出現的變更。

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

另請參閱 一致讀取、隔離等級、不可重複讀取、讀取未提交、可重複讀取、可序列化、交易。

一種源自 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 改良擴充功能 (Mysqli)、MySQL 原生驅動程式 (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 要求每個資料表都有這樣的索引 (也稱為叢集索引)，並根據主索引鍵的資料行值組織資料表儲存。

選擇主索引鍵值時，請考慮使用任意值 (一個合成索引鍵)，而不是依賴衍生自其他來源的值 (一個自然索引鍵)。

另請參閱 叢集索引、索引、自然索引鍵、合成索引鍵。

Kerberos 術語，用於命名實體，例如使用者或伺服器。

另請參閱 服務主體名稱、使用者主體名稱。

執行中的程式實例。作業系統會在多個執行中的處理程序之間切換，以實現一定程度的並行性。在大多數作業系統上，處理程序可以包含多個共用資源的執行執行緒。在執行緒之間切換內容比在處理程序之間進行對等切換更快。

另請參閱 並行性、執行緒。

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

另請參閱 下界記錄、鎖定、上界記錄。

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

參閱 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)。

由於歷史原因，有時關於語句內部處理的討論會以更廣泛的意義使用「查詢 (query)」，包括其他類型的 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 backup) 中反映的變更之前。在此階段，檔案尚未準備好還原 (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)。

參閱 髒讀 (dirty read)、不可重複讀取 (non-repeatable read)、幻讀 (phantom)。

提供交易之間最少保護的隔離等級。查詢採用一種鎖定策略，使其能在通常需要等待其他交易的情況下繼續進行。然而，這種額外的效能是以較不可靠的結果為代價，包括已被其他交易更改但尚未提交的資料（稱為髒讀）。使用此隔離等級時務必格外小心，並請注意，根據同時進行的其他交易，結果可能不一致或無法重現。通常，具有此隔離等級的交易僅執行查詢，而不執行插入、更新或刪除操作。

另請參閱 ACID、髒讀、隔離等級、鎖定、交易。

InnoDB 的 MVCC 機制使用的內部快照。某些交易，根據其隔離等級，會看到交易（或在某些情況下，是語句）開始時的資料值。使用讀取視圖的隔離等級為 REPEATABLE READ、READ COMMITTED 和 READ UNCOMMITTED。

另請參閱 隔離等級、MVCC、READ COMMITTED、READ UNCOMMITTED、REPEATABLE READ、交易。

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

另請參閱 緩衝池、範圍、頁面。

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

另請參閱 非鎖定讀取、讀取視圖、交易。

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

另請參閱 間隙鎖定 (gap lock)、鎖定 (lock)、next-key 鎖定。

當 DML 陳述式對 InnoDB 表格進行變更時，以記錄為單位記錄在重做日誌中的資料。它在崩潰恢復期間用於修正由不完整交易寫入的資料。不斷增加的LSN值表示已通過重做日誌的累計重做資料量。

另請參閱 崩潰恢復、DML、LSN、重做日誌、交易。

一種基於磁碟的資料結構，在崩潰恢復期間使用，用於修正由不完整交易寫入的資料。在正常操作期間，它會編碼變更 InnoDB 表格資料的請求，這些請求來自 SQL 陳述式或低階 API 呼叫。在意外關機之前，未完成更新資料檔案的修改會自動重新執行。

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

有關更多資訊，請參閱第 17.6.5 節「重做日誌」

另請參閱 崩潰恢復、資料檔案、ib_logfile、日誌緩衝區、LSN、重做、關機、交易。

InnoDB 的一項功能，啟用後，它會將重做日誌記錄循序寫入歸檔檔案，以避免在備份作業進行時，備份公用程式無法跟上重做日誌產生速度而可能發生的資料遺失。有關更多資訊，請參閱重做日誌歸檔。

另請參閱 重做日誌。

最舊的 InnoDB 資料列格式。在 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 資料列格式」。

另請參閱 緊湊資料列格式、動態資料列格式、資料列格式。

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

另請參閱 ACID、外鍵約束、NOT NULL 約束、唯一約束。

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

資料庫伺服器可以使用這些關係來防止插入錯誤的資料，並找到有效率的方式來尋找資訊。例如，如果某個值被宣告為唯一的，伺服器可以在找到第一個相符項後停止搜尋，並且可以拒絕嘗試插入相同值的第二個副本。

在資料庫層級，這些關係透過 SQL 功能表示，例如表格內的欄位、唯一和 NOT NULL 約束、外鍵和不同類型的聯結作業。複雜的關係通常涉及拆分在多個表格之間的資料。通常，資料會正規化，以便在一對多關係中的重複值只儲存一次。

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

另請參閱 ACID、欄位、約束、外鍵、正規化。

在全文檢索功能中，會使用一個數字來表示搜尋字串與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 使用的表格鎖定，或是在無法使用線上 DDL完成的 InnoDB 表格上執行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 用於表示和強制執行內部記憶體資料結構的共享存取鎖定的底層物件，遵循特定規則。與互斥鎖形成對比，InnoDB 使用互斥鎖來表示和強制執行內部記憶體資料結構的獨佔存取。互斥鎖和 rw-lock 統稱為閂鎖。

rw-lock 類型包括 s-locks（共享鎖定）、x-locks（獨佔鎖定）和 sx-locks（共享獨佔鎖定）。

以下矩陣總結了 rw-lock 類型相容性。

另請參閱 閂鎖、鎖定、互斥鎖、效能架構。

儲存點有助於實作巢狀交易。它們可以用於為較大交易中的資料表操作提供範圍。例如，在預訂系統中安排旅行可能涉及預訂幾種不同的航班；如果所需的航班不可用，您可能會回滾預訂該段航程所涉及的變更，而不會回滾先前成功預訂的航班。

另請參閱 回滾、交易。

能夠向系統新增更多工作並發出更多同時要求，而不會因為超出系統容量限制而導致效能突然下降。軟體架構、硬體設定、應用程式程式碼和工作負載類型都在可擴展性中發揮作用。當系統達到其最大容量時，提高可擴展性的常見技術是向上擴展（增加現有硬體或軟體的容量）和向外擴展（新增伺服器和更多 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、效能架構。

「已序列化字典資訊」的縮寫。

另請參閱 已序列化字典資訊 (SDI)。

在 MySQL 中，全文檢索查詢使用一種特殊的索引，即FULLTEXT 索引。在 MySQL 5.6.4 及更高版本中，InnoDB 和 MyISAM 資料表都支援 FULLTEXT 索引；以前，這些索引僅適用於 MyISAM 資料表。

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

一種 InnoDB 索引類型，表示資料表欄的子集。InnoDB 資料表可以有零個、一個或多個次要索引。（與每個 InnoDB 資料表都需要的叢集索引形成對比，叢集索引儲存所有資料表欄的資料。）

次要索引可用於滿足僅需要索引欄值的查詢。對於更複雜的查詢，它可用於識別資料表中的相關列，然後使用叢集索引透過查詢來擷取這些列。

建立和刪除次要索引傳統上涉及複製 InnoDB 資料表中所有資料的巨大額外負荷。快速索引建立功能使得 CREATE INDEX 和 DROP INDEX 陳述式對於 InnoDB 次要索引都快得多。

另請參閱 叢集索引、快速索引建立、索引。

InnoDB 表格空間內的分割。如果表格空間類似於目錄，則區段類似於該目錄中的檔案。區段可以成長。可以建立新的區段。

例如，在file-per-table 表空間中，表格資料位於一個區段，而每個相關的索引則位於各自的區段中。系統表空間包含許多不同的區段，因為它可以容納許多表格及其相關的索引。在 MySQL 8.0 之前，系統表空間還包含一個或多個用於復原日誌的復原區段。

區段會隨著資料的插入和刪除而增長和縮小。當區段需要更多空間時，它會一次擴展一個範圍 (1 MB)。同樣地，當範圍中的所有資料都不再需要時，區段會釋放一個範圍的空間。

另請參閱 範圍、file-per-table、復原區段、系統表空間、表空間、復原日誌。

資料分佈的屬性，欄位中不同值的數量（其基數）除以表格中的記錄數量。高選擇性表示欄位值相對唯一，可以透過索引有效地檢索。如果您（或查詢最佳化工具）可以預測 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 中繼資料檔案。

另請參閱 file-per-table、一般表空間、系統表空間、表空間。

一種持續執行的程式類型，等待接收和處理來自另一個程式（用戶端）的請求。由於通常整台電腦都專用於執行一個或多個伺服器程式（例如資料庫伺服器、網路伺服器、應用程式伺服器或這些的某種組合），因此術語伺服器也可以指執行伺服器軟體的電腦。

另請參閱 用戶端、mysqld。

由 MySQL 伺服器管理的預備陳述式。過去，由於伺服器端預備陳述式的問題，導致 Connector/J 和 Connector/PHP 開發人員有時會改用用戶端預備陳述式。在現代 MySQL 伺服器版本中，建議使用伺服器端預備陳述式，以提高效能、可擴展性和記憶體效率。

另請參閱 用戶端預備陳述式、Connector/J、Connector/PHP、預備陳述式。

Kerberos 具名實體的名稱，代表一個服務。

另請參閱 主體。

一種 Kerberos 票證，提供對應用程式服務的存取權，例如網路或資料庫伺服器提供的服務。

另請參閱 Connector/J。

一個暫存表空間，用於儲存使用者建立的暫存表格以及當 InnoDB 設定為內部暫存表格的磁碟儲存引擎時，最佳化工具建立的內部暫存表格。

另請參閱 最佳化工具、暫存表格、暫存表空間。

一種鎖定，允許其他交易讀取鎖定的物件，並在其上取得其他共用鎖定，但不允許寫入。與獨佔鎖定相反。

另請參閱 獨佔鎖定、鎖定、交易。

指的是系統表空間或一般表空間的另一種方式。一般表空間在 MySQL 5.7 中引入。多個表格可以位於共用表空間中。只有一個表格可以位於file-per-table表空間中。

另請參閱 一般表空間、系統表空間。

將所有髒緩衝池頁面刷新到磁碟的程序，這些頁面的 redo 項目包含在redo 日誌的特定部分中。在 InnoDB 重複使用日誌檔案的一部分之前發生；日誌檔案以循環方式使用。通常發生在寫入密集型的工作負載中。

另請參閱 髒頁面、刷新、redo 日誌、工作負載。

停止 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 頁面壓縮」。

參見 空洞填補、透明頁面壓縮。

一種等待操作類型，會持續測試資源是否可用。此技術用於通常只短暫持有的資源，在此情況下，在「忙碌迴圈」中等待，比將執行緒置於睡眠狀態並執行內容切換更有效率。如果資源在短時間內沒有變得可用，自旋迴圈就會停止並使用另一種等待技術。

參見 閂鎖、鎖定、互斥鎖、等待。

一個基於 Java 的應用程式框架，旨在透過提供設定元件的方式來協助應用程式設計。

另請參閱 J2EE。

用於執行資料庫作業的標準結構化查詢語言。通常分為DDL、DML 和查詢等類別。MySQL 包含一些額外的語句類別，例如複製。如需 SQL 語法基本組件，請參閱第 11 章，語言結構；如需 MySQL 資料表欄位使用的資料類型，請參閱第 13 章，資料類型；如需 SQL 語句及其相關類別的詳細資訊，請參閱第 15 章，SQL 語句；如需在查詢中使用的標準和 MySQL 特有函式，請參閱第 14 章，函式與運算子。

參見 DDL、DML、查詢、複製。

由 JDBC 標準定義的錯誤代碼，供使用 Connector/J 的應用程式進行例外處理。

參見 Connector/J、JDBC。

「固態硬碟」的縮寫。一種儲存裝置類型，其效能特性與傳統硬碟 (HDD) 不同：儲存容量較小、隨機讀取速度較快、沒有移動部件，且有多項會影響寫入效能的考量。其效能特性可能會影響磁碟 I/O 限制工作負載的輸送量。

參見 磁碟 I/O 限制、HDD。