关于MySQL极限值的初步验证纠错（二）

之前写了一篇自己的简单测试总结：关于MySQL极限值的初步验证纠错

今天在这个基础上继续做一些分析，如果说最权威，最全面的材料，那应该非官方文档莫属了，而要把文档看明白，理解清楚，那就只有大量的练习了，目前我是没发现捷径可走，如果有的话，请告知。

要想较为全面的了解MySQL中的极限值，或者叫做边界值，有很多需要考虑的点，我们有些可以做测试，有些就需要参考文档了。比如一个表里的列最多是1017个，注意这里是最多，如果是varchar型，那就达不到1017，但是最大值1017的结论还是成立的。而如果要测试MySQL innoDB存储引擎的表最大可以有多大，那么这类问题，我是完全没法通过程序和数据来模拟的，官方文档里有，我们完全可以参考。

数据库的数量，表的数量：

官方的链接在这里：https://dev.mysql.com/doc/mysql-reslimits-excerpt/5.7/en/database-count-limit.html

简单来说，就是MySQL说我随意。

当然个别的云厂商还是会做一些资源的限制。

表空间的极限值：

最小的表空间大小：10M

最大的表空间大小：基于存储引擎和页的大小

The minimum tablespace size is slightly larger than 10MB. The maximum tablespace size depends on the InnoDB page size,

The maximum tablespace size is also the maximum size for a table.

所以说，默认页是16k,那么表空间的最大值就是64T，所以说，理论值可以那么大，但是我们绝对不会那么干。

辅助索引的个数

A table can contain a maximum of 64 secondary indexes.

没错，最多的辅助索引个数是64个。

复合索引的列

A maximum of 16 columns is permitted for multicolumn indexes. Exceeding the limit returns an error.

复合索引的列最多是16个。

索引键前缀长度

主要还是和参数innodb_large_prefix有关。默认是767字节，如果开启了参数，是3072，这个地方在5.6和5.7的描述有一些细小的偏差。

一些补充：

SHOW TABLE STATUS的结果只是一个估算值，不是完全精确的值。

5.7.18版本前的select count(*)的处理机制已经不同了，虽然方向是改进，其实性能还略有下降，已有同学提交了相关的bug.

SELECT COUNT(*) 和SELECT COUNT(1) 没有性能差别

Windows下都是默认的小写，迁移到Unix,Linux也需要注意。