問題發(fā)現(xiàn)

今天在導入他人項目中的sql數(shù)據庫文件時，出現(xiàn)一個mysql的錯誤提示，大致描述是：
Row size too large (> 8126)，英文不算好的我看字面意思，估摸著大概就是說我們插入的行數(shù)據可能太大了，超過了設定的闕值；

一、問題導致的可能原因

這個限制主要是因為MySQL內部存儲機制的約束，MySQL的InnoDB存儲引擎有一個最大行大小限制關于mysql引擎內容比較多，以后再專門寫一篇內容好好說說；這里我們只需要知道他是目前mysql 默認的存儲引擎就好啦；

而這個最大行大小限制主要由于幾個因素影響：

1、頁大小

頁是InnoDB管理數(shù)據的最小單位，InnoDB使用16KB的頁來存儲數(shù)據，行數(shù)據在進行保存插入的時候，要求我們的單行數(shù)據不能跨越多于半個頁（8KB）。否則數(shù)據庫會自動按照是否進行溢出頁的機制來處理數(shù)據；
簡單說的話，其實就是數(shù)據庫中的每行數(shù)據我們可以看作是一所個人專屬的小房子，里面預留了一個固定的空間給他們放東西，如果放入的東西太多了，超過這個空間大小，屋主就會考慮是否可以把東西放在屋外，來保障空間不至于太過擁擠，這里的房間內的空間就是頁內空間大小，房外就是多出的

2、行格式

InnoDB支持幾種行格式，如compact、redundant、dynamic和compressed。其中，dynamic和compressed格式是為了解決行大小限制而引入的，允許行中的某些列（如BLOB和TEXT類型）存儲在頁外。
這點簡單的來說，四種行格式可以看作是房屋管理辦法四個準則，每個準則都有各自適用的場景和優(yōu)點；

關于行格式，我們這里只需要知道有哪幾種，以及他們數(shù)據存儲方式，各自應用場景即可；

2.1 compact格式

InnoDB的默認行格式，也是最常用常見的格式；采取的是位圖壓縮的存儲方式；適用于大多數(shù)OLTP（在線事務處理應用場景。OLTP其實就是指那種較高并發(fā)，并且要求低延遲，專注業(yè)務操作的應用，類似銀行交易、訂單處理、庫存更新那些情況比較常用；

2.2 Redundant格式

MySQL 5.0以前的默認行格式；適用具有大量NULL值的表；

2.3 Dynamic格式

從 MySQL 5.6.3 開始，默認的行格式是 DYNAMIC，Dynamic行格式具有高度的靈活性，可以動態(tài)地調整行的大小和存儲方式。基于實際數(shù)據長度大小來進行調整存儲空間，以節(jié)省存儲空間；適用于包含大量長度可變列的表，例如包含TEXT、BLOB等大型字段的表。

2.4 Compressed格式

Compressed行格式采用壓縮存儲方式，它適用于存儲大量重復數(shù)據或較大的表。Compressed行格式使用多種壓縮算法，如Zlib和LZO等，能夠顯著減少磁盤I/O操作，提高存儲和讀取性能

3、BLOB和TEXT列

這點因素與上面那點有關，Blob 和 Text 是mysql中的大數(shù)據存儲類型，但是在我們不設置行模式為ynamic和compressed的時候，這些列通常存儲在頁外，但它們的元數(shù)據（如長度）仍然存儲在行內，而這個存儲的大小跟行格式的設置會有所不同。也就是說明他會計入行大小限制的計算；

二、解決辦法

好了，既然知道問題原因的可能了，現(xiàn)在就是開始如何解決了；

1、修改頁大小（不推薦）

雖然mysql InnoDB的引擎默認的頁大小是16KB，但是這個值并不是不能修改，修改配置文件；
添加或修改innodb_page_size參數(shù)來設置新的頁大小。例如，innodb_page_size = 16384（以字節(jié)為單位，對應16KB），或者設置的更大；
不過需要注意的是：頁大小的調整最好是在數(shù)據庫初始化的初期去設置，一旦數(shù)據庫初始化完成后，就不建議更改了，這種情況下意味著你原來已經存在的所有ibdata和ib_logfile文件都需要重建，那就不是很合適了，而且這樣做也可能會帶來一定的性能影響；

2、修改行格式

既然dynamic和compressed行格式就是為了解決行大小限制而引入的，我們可以修改該格式即可；當然了，我們也不是都要去修改這個，這個也是和我們的mysql版本有關的；

從 MySQL 5.6.3 開始，默認的行格式是 DYNAMIC，也就是說，其實在這個版本之后的我們其實就不需要修改行格式了；
不過如果你和博主一樣是通過導入sql文件的方式創(chuàng)建的表的話，需要確認你的sql文件中是否有另外定義行格式；例如：

博主雖然數(shù)據庫是8.0+，默認行模式已經是DYNAMIC，但是對方給的sql文件創(chuàng)建表的語句中指定了Compact行格式，這個原因大概率是因為它在導出時候環(huán)境是基于mysql5.x，而博主是8.0+的，所以這里導出的時候會有所出入；這里我講所有的行模式設置都去掉了，默認就會按照DYNAMIC設置，就不會報錯了；因此我們在做不同版本mysql的數(shù)據導入與導出時，需要特別小心版本不同帶來的影響

3、修改數(shù)據類型為BLOB和TEXT列

如果你本來該字段就會需要存儲較大的數(shù)據，就應該用blob和text來替換原來的數(shù)據類型VARCHAR或CHAR，這樣能讓數(shù)據大部分存儲在溢出頁中，而不去納入大小限制的值計算；而如果我們之前設置了行模式的話，這個納入計算的值占用會更??；

4、其他優(yōu)化方式（可以參考使用）

4.1 合理設置數(shù)據類型大小

在進行表設計時候，一些列字段我們根據實際需要設計，例如varchar數(shù)據類型，如果實際存儲值不大，長度就定義足夠空間大小即可（即能用varchar64就不用varchar128，能用128就不要用256，盡可能合理分配空間）；

4.2 合理進行表結構設計

如果設計表的時候，單表列盡量不要太多，適當?shù)倪M行拆表將列分出去，也能在一定橫渡上避免問題；

4.3 更換存儲引擎

換另一種存儲引擎，這個方法的話見仁見智，要根據自己的業(yè)務場景來抉擇了，比如MyISAM引擎最大的缺點就是它不支持事務和高并發(fā)，所以才使得大多數(shù)情況下我們仍然在用InnoDB引擎的原因，雖然它讀寫性能上并沒有前者優(yōu)秀；

到此這篇關于Mysql中Row size too large (＞ 8126) 錯誤的問題解決的文章就介紹到這了,更多相關Mysql Row size too large (＞ 8126) 內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論