關於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，所以說，理論值可以那麼大，但是我們絕對不會那麼幹。

InnoDB Page Size	Maximum Tablespace Size
4KB	16TB
8KB	32TB
16KB	64TB

輔助索引的個數

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也需要注意。