InnoDB的限制

原创
2020/11/30 22:11
阅读数 6.4K

我们经常遇到MySQL的问题,很多是一些限制产生的,现在我们整理一下关于InnoDB的限制,这里直接翻译了MySQL 5.6的官方文档

14.22 InnoDB Limits

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

此段落描述了 InnoDB 表,索引,表空间 和 InnoDB 存储引擎其他方面的限制。

  • 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 个的限制进行了提升。)

  • 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 字节。

  • 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: 对于字符串字段,可以创造索引,这个索引仅用到字段值的开头部分,用 字段名(长度) 语法来声明一个索引前缀长度。

    • 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 为存储引擎的表中进行索引。

    • 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) 会被理解成为 字节数量。当使用多字节字符集时,为一个非二进制字符串类字段声明前缀长度时,要把这点考虑进去。

      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 回滚日志

展开阅读全文
打赏
2
4 收藏
分享
加载中
更多评论
打赏
0 评论
4 收藏
2
分享
返回顶部
顶部