14.6.7?Limits on InnoDB Tables InnoDB 表的限制

14.6.7?Limits on InnoDB Tables   InnoDB 表的限制

警告:

不要把MySQL  system tables  从MyISAM 到InnoDB 表。

这是不支持的操作,如果你这么做,MySQL 不重启直到你恢复老的system tables从一个备份或者再生通过初始化数据目录。

这不是好的注意配置InnoDB 使用 data files或者log files 在NFS 文件系统,

否则, 文件可能被其他进程锁定和变的不可用:

最大值和最小值:

1. 一个表可以包含最大1017列(在5.6.9,从早期的1000提高到1017)

2.一个包可以包含最多64个secodary indexes

默认情况下, 一个index key 对于一个单列index 可以最大到767字节。

相同的长度限制应用于任何  index key prefix.

 比如, 你可以hit这个限制 在一个前缀索引列对于255个字节在一个TEXT或者VARCHAR列,

假设一个UTF-8 字符设置每个字符最大3个字节。

当 innodb_large_prefix 配置选项被启用,

mysql> show variables like '%innodb_large_prefix%';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| innodb_large_prefix | OFF   |
+---------------------+-------+
1 row in set (0.00 sec)

长度限制上升到3072字节,对于InnoDB 表使用动态和COMPRESSED 行格式

尝试使用一个index prefix 长度大于允许的最大值会产生一个错误,为了避免这样的错误对于复制配置,

避免 设置 innodb_large_prefix  选项 在master上如果 它不能设置在slaves,

slaves 有一个唯一索引

mysql> show variables like '%innodb_page_size%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_page_size | 16384 |
+------------------+-------+
1 row in set (0.00 sec)

如果你降低InnoDB page szie 到8KB 或者4KB 通过指定innodb_page_size option  在创建MySQL 实例的时候

index key 的最大长度是降低比例,  对于一个16KB page size 基于3072字节。

也就是说, 最大的index key length 是1536字节当page size 是8KB, 768 字节当page 是4KB

最大的行长度,除了对于可变长度列(VARBINARY, VARCHAR, BLOB and TEXT), 

是略少于一半的数据库页。

 最大行长度是大概8000字节对于默认的page size 16KB

 如果一个行是小于一半的page 长度, 行所有都存储在本地。  

 尽管 InnoDB 支持row sizes 大于65,535字节,

 MySQL 本身实现一个行大小限制为65535

 1.在一些老的操纵系统上, 文件必须小于2GB。

 这个不是InnoDB 本身限制, 但是如果你需要一个更大的表空间,你需要配置它使用多个小的文件相比一个大的文件

 2.  InnODB log files 组合大小可以最大到512GB

 3.最小tablespace size 时略小于10MB,  最大的tablespace 大小是64TB。

 这也是表的最大值

 默认的database page size 在InnoDB 是16KB，或者你可以降低页面大小到8KB或者4KB 通过指定 innodb_page_size 

 在创建MySQL 实例的时候:

mysql> show variables like '%innodb_page_size%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_page_size | 16384 |
+------------------+-------+
1 row in set (0.00 sec)

注意:

增加pages size 是不支持的操作, 没有保障InnoDB 会工作正常在使用一个page size 大于16KB.

编译或者运行InnoDB 可能发生错误。 特别的,

ROW_FORMAT=COMPRESSED  在Barracuda 文件格式

一个MySQL 实例使用一个特定的InnoDB page size 不能使用data files或者log files 在一个实例里使用一个不同的page size .

这种限制会影响恢复或者downgrade 操作在MySQL 5.6中使用数据

Index Types 索引类型:

1.InnoDB 表支持全文索引

2. InnoDB 表支持指定的数据类型,但不是在它们上面的Indexes

在InnoDB 表上的限制:

1. ANALYZE TABLE 决定index cardinality( 在SHOW INDEX output 输出的评估列)

通过随机的dives 到每个index trees 和更新index cardinality ，因为这些只是评估,

重复运行ANALYZE TABLE  会产生不同的数字。 这使得ANALYZE TABLE fast 在InnoDB表单不是100%精确

因为它不考虑所有的行。

index cardinality:

  基数(Cardinality) 列唯一键(Distinct_keys)的数量，比如性别，该列只有男女之分，所以这一列基数是2。主键列的基数等于行数。

你可以收集统计信息通过ANALYZE TABLE更加精确和更加稳定通过设置 innodb_stats_persistent 配置选项

mysql> show variables like '%innodb_stats_persistent%';
+--------------------------------------+-------+
| Variable_name                        | Value |
+--------------------------------------+-------+
| innodb_stats_persistent              | ON    |
| innodb_stats_persistent_sample_pages | 20    |
+--------------------------------------+-------+
2 rows in set (0.00 sec)

当设置被启用, 运行ANALYZE TABLE 是重要的 在重要的改变到索引列的数据,因为 统计信息不会定期的重新收集

(比如在一个server 重启后)

你可以改变随机dives 的数量通过修改 innodb_stats_persistent_sample_pages  系统变量

( 如果persistent statistics setting 是开启的)

或者 innodb_stats_transient_sample_pages

MySQL 使用index cardinality 评估只有在关联优化时,  如果一些关联是没有被优化以正确的方式,

你可以尝试使用ANALYZE TABLE .

在少数情况下, ANALYZE TABLE 不会产生足够好的值对于你的实际表,

你可以使用 FORCE INDEX 在你的查询来强制使用一个特定的索引,

或者设置 max_seeks_for_key 来确保MySQL 建议index lookups

如果语句或者事务 是运行在一个表, ANALYZE TABLE 是运行在相同的表 跟着一个 second ANALYZE TABLE operation, 

 second ANALYZE TABLE operation 会被堵塞 直到 语句或者事务完成。

 这个行为发生因为 ANALYZE TABLE 让当前加载的表定义过期了当ANALYZE TABLE完成运行时。

 新的语句或者事务(包含 一个 second ANALYZE TABLE statement)  必须加载新表定义到表cache,

 不能发生直到当前运行语句或者事务是完成了,老的表定义是被purged.

 加载多个并发表定义是不支持的。

 SHOW TABLE STATUS 不会给出准备的统计信息 ,除非 表的物理大小会被保留。  行计数只是用于一个SQL优化评估使用

 InnoDB  不保持 一个内部的行的记录数,因为并发的事务 可能"看到"不同的行的记录数在相同的时间。

 处理一个 SELECT COUNT(*) FROM t statement, InnoDB 描述一个表的索引,

 会花费一些时间如果索引整个不在buffer pool里。

 如果你的表不经常改变,使用e MySQL query cache 是一个好的方法。

 为了得到一个快速的count统计, 你需要使用一个counter table。

 让你的应用更新它,根据插入和删除。

 如果一个人相应的行记录数是足够的,SHOW TABLE STATUS可以使用

 在Windows上, InnoDB 总是存储 数据和表名字内部按小写,

 移动数据库以2进制的方式从Unix 到Windows 或者从Windows到Unix,创建所有数据库和表使用小写

 一个AUTO_INCREMENT 列  ai_col 必须定义为一个索引的一部分 

 这样才能可以执行一个等价的SELECT MAX(ai_col) lookup 在表上得到最大值。

 典型的, 这是通过让列称为一些表索引的第一列

 InnoDB 设置一个排它锁在在索引的尾部

 当设置 innodb_autoinc_lock_mode=0 ，

mysql> mysql> show variables like '%innodb_autoinc_lock_mode%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_autoinc_lock_mode | 1     |
+--------------------------+-------+
1 row in set (0.00 sec)

InnoDB 使用一个指定的AUTO-INC 表 lock 模式 lock被获得和持有到SQL语句的结束,

在访问自增列的统计。

别的客户端不能插入表 当AUTO-INC lock 被持有,

当你重启你的MySQL SERVER，InnoDB 可能重新使用一个old value 有AUTO_INCREMENT列产生但是没有被存储

(也就是说,一个值在老的事务中已经产生,但是被回滚)

当一个自增列整型列值用完,随后的插入操作返回一个重复值。 这是MySQL 的行为, 类似于MyISAM的工作方式

DELETE FROM tbl_name 不重新产生,但是删除所有的记录,一个接一个