InnoDB的限制

咱們常常遇到MySQL的問題,不少是一些限制產生的,如今咱們整理一下關於InnoDB的限制,這裏直接翻譯了MySQL 5.6的官方文檔html

14.22 InnoDB Limits

This section describes limits for InnoDB tables, indexes, tablespaces, and other aspects of the InnoDB storage engine.mysql

此段落描述了 InnoDB 表,索引,表空間 和 InnoDB 存儲引擎的限制。sql

  • A table can contain a maximum of 1017 columns (raised in MySQL 5.6.9 from the earlier limit of 1000). 一張表能夠包含最多 1017 個字段 (在 5.6.9 版本中從早先的 1000 個限制進行了提高。)bash

  • A table can contain a maximum of 64 secondary indexes. 一張表能夠包含最多 64 個二級索引 (也就是聚簇索引以外的 非聚簇索引)。併發

  • By default, the index key prefix length limit is 767 bytes. See Section 13.1.13, 「CREATE INDEX Statement」. For example, you might hit this limit with a column prefix index of more than 255 characters on a TEXT or VARCHAR column, assuming a utf8mb3 character set and the maximum of 3 bytes for each character. When the innodb_large_prefix configuration option is enabled, the index key prefix length limit is raised to 3072 bytes for InnoDB tables that use the DYNAMIC or COMPRESSED row format. 默認地,索引的 鍵 前綴長度限制是 767 字節 (參看 13.1.13 建立索引聲明:下一項)。例如,你給一個多於 255字符的 TEXT 或 VARCHAR 字段 帶上字段前綴索引,將會觸發這個限制,假設是一個utf8mb3 字符集,且每一個字符最多3字節 (3 * 256 = 768)。 當 innodb_large_prefix 配置項被開啓時,索引鍵的前綴長度限制會被提高到 3072 字節。app

  • Column Prefix Key Parts 字段前綴索引部分

    For string columns, indexes can be created that use only the leading part of column values, using col_name(length) syntax to specify an index prefix length: 對於字符串字段,能夠創造索引,這個索引僅用到字段值的開頭部分,用 字段名(長度) 語法來聲明一個索引前綴長度。less

    • Prefixes can be specified for CHAR, VARCHAR, BINARY, and VARBINARY key parts. 能夠爲 CHAR, VARCHAR, BINARY 以及 VARBINARY 鍵部分 聲明前綴。性能

    • Prefixes must be specified for BLOB and TEXT key parts. Additionally, BLOB and TEXT columns can be indexed only for InnoDB, MyISAM, and BLACKHOLE tables. 必須爲 BLOB 和 TEXT 鍵部分 必須聲明前綴。另外,BLOB 和 TEXT 字段只能在 以InnoDB, MyISAM 和 BLACKHOLE 爲存儲引擎的表中進行索引。ui

    • Prefix limits are measured in bytes. However, prefix lengths for index specifications in CREATE TABLE, ALTER TABLE, and CREATE INDEX statements are interpreted as number of characters for nonbinary string types (CHAR, VARCHAR, TEXT) and number of bytes for binary string types (BINARY, VARBINARY, BLOB). Take this into account when specifying a prefix length for a nonbinary string column that uses a multibyte character set. 前綴限制是按字節進行測量的。然而,在 CREATE TABLE, ALTER TABLE, CREATE INDEX 語句中的 前綴長度 索引聲明,對於 非二進制字符串類型 (nonbinary string types) (CHAR, VARCHAR, TEXT) 會被理解成爲 字符數量,對於 二進制字符串類型(binary string types) (BINARY, VARBINARY, BLOB) 會被理解成爲 字節數量。當使用多字節字符集時,爲一個非二進制字符串類字段聲明前綴長度時,要把這點考慮進去。this

      Prefix support and lengths of prefixes (where supported) are storage engine dependent. For example, a prefix can be up to 767 bytes long for InnoDB tables or 3072 bytes if the innodb_large_prefix option is enabled. For MyISAM tables, the prefix length limit is 1000 bytes. The NDB storage engine does not support prefixes (see Section 18.1.7.6, 「Unsupported or Missing Features in NDB Cluster」). 前綴支持 以及 前綴長度(當支持時) 是依賴於存儲引擎的。例如,一個前綴在 InnoDB 引擎中能夠上至 767 字節,或者 3072 字節 當 innodb_large_prefix 選項開啓時。對於 MyISAM 表,前綴長度限制是 1000 字節。NDB 存儲引擎不支持前綴。

    The statement shown here creates an index using the first 10 characters of the name column (assuming that name has a nonbinary string type):
    這裏展現的語句,建立了一個 用 name字段的 前10個字符 建立了一個索引 (假定 name 是一個非二進制字符串類字段)

    CREATE INDEX part_of_name ON customer (name(10));

    If names in the column usually differ in the first 10 characters, lookups performed using this index should not be much slower than using an index created from the entire name column. Also, using column prefixes for indexes can make the index file much smaller, which could save a lot of disk space and might also speed up INSERT operations.
    若是 在這個name字段中的名字經過在前10個字符不相同,則用剛剛建立的這個索引的性能,應該不會比用name字段所有名稱建立的索引慢太多。同時,使用字段的前綴去建立索引可讓索引文件小不少,這將節省不少磁盤空間,並且有可能讓 INSERT 操做更快一些。

    Attempting to use an index key prefix length that exceeds the limit returns an error. To avoid such errors in replication configurations, avoid enabling innodb_large_prefix on the source if it cannot also be enabled on replicas.
    嘗試建立一個超過限制的 索引鍵前綴長度將會返回一個錯誤。爲了不在複製配置時產生這類錯誤,若是在備份上也不能開啓 innodb_large_prefix選項,那麼在源頭上就應該避免開啓 innodb_large_prefix。
     

    ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes

     

  • If you reduce the InnoDB page size to 8KB or 4KB by specifying the innodb_page_size option when creating the MySQL instance, the maximum length of the index key is lowered proportionally, based on the limit of 3072 bytes for a 16KB page size. That is, the maximum index key length is 1536 bytes when the page size is 8KB, and 768 bytes when the page size is 4KB.
    根據 3072字節對應16KB頁大小,若是在建立MySQL實例時,你經過聲明 innodb_page_sise 選項 把 InnoDB 頁大小 (page size) 減小到 8KB 或者 4KB,那麼 索引鍵的最大長度也會按比例地下降。也就是說,在 8KB時 最大的索引鍵長度是 1536字節,而4KB是768字節。

    The limits that apply to index key prefixes also apply to full-column index keys. 適用於索引鍵前綴的限制通用適用於全字段索引鍵(如單個完整字段鍵或多個字段的聯合索引鍵)。

  • A maximum of 16 columns is permitted for multicolumn indexes. Exceeding the limit returns an error.
    對於多字段索引,最多運行16個字段。超出此限制會返回錯誤。

    ERROR 1070 (42000): Too many key parts specified; max 16 parts allowed
  • The maximum row size, excluding any variable-length columns that are stored off-page, is slightly less than half of a page. That is, the maximum row size is about 8000 bytes for the default page size of 16KB. If you reduce the page size by specifying the innodb_page_size option when creating the MySQL instance, the maximum row size is 4000 bytes for 8KB pages, or 2000 bytes for 4KB pages. LONGBLOB and LONGTEXT columns must be less than 4GB, and the total row size, including BLOB and TEXT columns must be less than 4GB.
    最大的行大小,包括全部被離頁(off-page)存儲的長度可變的字段,會稍微少於一個半頁。也就是說,對於默認的16KB的頁大小,最大的行大小大概是8000字節。若是在建立MySQL實例時,經過聲明 innodb_page_size 選項來減小 頁大小,那麼8KB的頁最大行大小爲4000字節,或者4KB的2000字節。LONGBLOB 和 LONGTEXT 字段必須小於 4GB,包括 BLOB 和 TEXT字段的總的行大小頁必須小於4GB。

    If a row is less than half a page long, all of it is stored locally within the page. If it exceeds half a page, variable-length columns are chosen for external off-page storage until the row fits within half a page, as described in Section 14.12.2, 「File Space Management」.
    若是一行小於一個半頁長,它的所有將在本頁內存儲。若是超過了一個半頁,(多出來的)可變的長度字段將被選擇到外部離頁存儲,直到這行能存進一個半頁裏,如 14.12.1 文件空間管理 所述。

  • Although InnoDB supports row sizes larger than 65,535 bytes internally, MySQL itself imposes a row-size limit of 65,535 for the combined size of all columns. See Section 8.4.7, 「Limits on Table Column Count and Row Size」.
    儘管 InnoDB 支持行大小內部大於 65,535 字節,MySQL它自己 對 全部字段的組合大小 強加了一個 65,535的行大小限制,參看 8.4.7 表字段計數和行大小

  • On some older operating systems, files must be less than 2GB. This is not an InnoDB limitation. If you require a large system tablespace, configure it using several smaller data files rather than one large data file, or distribute table data across file-per-table data files.
    在一些老的操做系統中,文件必須小於2GB。這不是 InnoDB的限制。若是你須要一個大的系統表空間,把它設置成幾個小一點的數據文件,而不是一個大的數據文件,或者 將表數據 拆分到 幾個 單表文件 數據文件中。

  • The combined maximum size for InnoDB log files is 512GB. InnoDB 日誌文件的 組合最大尺寸是 512GB。

  • The minimum tablespace size is slightly larger than 10MB. The maximum tablespace size depends on the InnoDB page size.
    最小的表空間大小比10MB稍微大一些。最大的表空間大小 取決於 InnoDB 頁大小。

    Table 14.20 InnoDB Maximum Tablespace Size

    InnoDB Page Size
    InnoDB 頁大小
    Maximum Tablespace Size
    最大的表空間大小
    4KB 16TB
    8KB 32TB
    16KB 64TB

    The maximum tablespace size is also the maximum size for a table. 最大的表空間尺寸也就是一個表的最大尺寸。

  • Tablespace files cannot exceed 4GB on Windows 32-bit systems (Bug #80149). 再Win32系統中,表空間文件不能超過4GB。

  • The path of a tablespace file, including the file name, cannot exceed the MAX_PATH limit on Windows. Prior to Windows 10, the MAX_PATH limit is 260 characters. As of Windows 10, version 1607, MAX_PATH limitations are removed from common Win32 file and directory functions, but you must enable the new behavior. 表空間文件的路徑,包括文件名,不能超出 Windows系統規定的 MAX_PATH變量。在 Win10 以前,MAX_PATH限制是260個字母。對於Win10-1607版本,MAX_PATH限制從一般的Win32文件和目錄方法中移除了,可是你必須使新的操做行爲可用。

  • For limits associated with concurrent read-write transactions, see Section 14.6.7, 「Undo Logs」.
    對於 併發讀-寫 事務的相關限制,參照:14.6.7 回滾日誌

相關文章
相關標籤/搜索