MySQL排查問題row size too large (＞ 8126). Changing some columns to TEXT or BLOB may help.

2年前作者：柏拉圖的稻穗分類：Toy博客閱讀(47)違法舉報(bào)

這篇具有很好參考價(jià)值的文章主要介紹了MySQL排查問題row size too large (＞ 8126). Changing some columns to TEXT or BLOB may help.。希望對大家有所幫助。如果存在錯(cuò)誤或未考慮完全的地方，請大家不吝賜教，您也可以點(diǎn)擊"舉報(bào)違法"按鈕提交疑問。

例子：給表增加一列報(bào)錯(cuò):

alter table student add column `aggregate_id` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '聚合id'

1118: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

單行記錄的合計(jì)最大大小超過了8126字節(jié)，那么根據(jù)文檔描述的話，使用dynamic行格式的表行最大大小可以達(dá)到65536字節(jié)(因?yàn)閙ysql內(nèi)部使用了2個(gè)字節(jié)來表示字段長度，因此可以表示最大65535的長度)

CREATE TABLE `student` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(700) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '名字',
  `picture` varchar(127) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `description` varchar(1023) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `college_id` bigint(20) NOT NULL DEFAULT '0',
  `create_time` bigint(20) NOT NULL,
  `user_id` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '用戶id',
  `data` json DEFAULT NULL COMMENT 'ext',
  `status` int(11) NOT NULL DEFAULT '0' COMMENT '狀態(tài)',
  PRIMARY KEY (`id`),
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

計(jì)算：bigint 8 byte

80*8+700+127+1023+11*4=2534

雖然沒有算上json字段的長度，感覺計(jì)算結(jié)果對不上。看了一些博客修改varchar為text并不能解決，需要修改mysql的配置文件，并且重啟。但實(shí)際上，很多地方修改表的字段varchar啥的都會失敗，跟alter語句的執(zhí)行過程有關(guān)，有興趣可以了解下，最有效的辦法就是修改key_block_size的大小。

https://blog.51cto.com/hcymysql/4369124

https://www.jianshu.com/p/2c96a7f1b8aa

經(jīng)過調(diào)研，“row_size>8126”報(bào)錯(cuò)應(yīng)該是一個(gè)固定提示，所以可以不用糾結(jié)了！

MySQL排查問題row size too large (＞ 8126). Changing some columns to TEXT or BLOB may help.,MySQL,mysql,數(shù)據(jù)庫,Powered by 金山文檔

https://mariadb.com/kb/en/innodb-strict-mode/文章來源地址http://www.zghlxwxcb.cn/news/detail-546873.html

到了這里，關(guān)于MySQL排查問題row size too large (＞ 8126). Changing some columns to TEXT or BLOB may help.的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！

本文來自互聯(lián)網(wǎng)用戶投稿，該文觀點(diǎn)僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如若轉(zhuǎn)載，請注明出處：如若內(nèi)容造成侵權(quán)/違法違規(guī)/事實(shí)不符，請點(diǎn)擊違法舉報(bào)進(jìn)行投訴反饋，一經(jīng)查實(shí)，立即刪除！

分享到：

領(lǐng)支付寶紅包贊助服務(wù)器費(fèi)用

Result window is too large, from + size must be less than or equal to: [10000] but was
做分頁查詢，當(dāng)分頁達(dá)到一定量的時(shí)候，報(bào)如下錯(cuò)誤：原因分析: es對from + size的大小進(jìn)行限制，必須小于等于10000。方案一（有風(fēng)險(xiǎn)）將max_result_window參數(shù)閾值調(diào)大，在業(yè)務(wù)中限制分頁大小，使from+size=10000; 具體操作改法一：動態(tài)更改索引設(shè)置，為max_result_window參數(shù)賦值足夠
2024年02月16日
瀏覽(19)
解決Data too long for column ‘xxx‘ at row 1問題以及深入理解mysql的字符串?dāng)?shù)據(jù)類型(char,varchar,enum,text,longtext...)
今天在測試環(huán)境新增數(shù)據(jù)時(shí)，報(bào)出如是錯(cuò)誤： Data too long for column \\\'apply_service_type\\\' at row 1 。為了復(fù)現(xiàn)這個(gè)問題，我特地在本地?cái)?shù)據(jù)庫中增加如下 test 表：
2023年04月17日
瀏覽(26)
elasticsearch Data too large問題解決
現(xiàn)象： 1、釘釘上收到es集群監(jiān)控告警，集群變?yōu)閥ellow 2、kibana上沒有數(shù)據(jù)，打開索引管理報(bào)以下錯(cuò)誤：解決： 1、修改config目錄下jvm配置文件中關(guān)于jvm的參數(shù) 2、重啟es集群 2.1 如果分片有副本的話，重啟過程中，要臨時(shí)關(guān)閉分片復(fù)制功能。每個(gè)結(jié)點(diǎn)重啟時(shí)，ElasticSearch集群的
2024年02月07日
瀏覽(21)
413 Request Entity Too Large問題解決方法
最近我們有個(gè)小程序需求是現(xiàn)場拍照提取照片中的有效信息，上傳圖片只能通過現(xiàn)場拍照，由于目前手機(jī)像素普遍較高，導(dǎo)致上傳接口出現(xiàn)413 Request Entity Too Large，上傳文件過大引起nginx代理報(bào)錯(cuò)。針對這個(gè)問題，解決方案是：項(xiàng)目配置文件修改，比如springboot項(xiàng)目中的applic
2024年02月16日
瀏覽(16)
【Elasticsearch】Elasticsearch中使用_id排序?qū)е?data too large 問題
Elasticsearch 一個(gè)彈性伸縮的搜索數(shù)據(jù)庫，后文簡稱：ES ,最近有一個(gè)ES 服務(wù)查詢數(shù)據(jù)時(shí)候出現(xiàn)了數(shù)據(jù) Hits 結(jié)果多次查詢不一致的問題，而且這塊代碼已經(jīng)很長時(shí)間沒有修改，一直穩(wěn)定運(yùn)行了很長時(shí)間，用戶翻譯查詢列表數(shù)據(jù)的時(shí)候又是出現(xiàn)1條，有時(shí)候出現(xiàn)2條或者3條。(再加上
2024年02月03日
瀏覽(30)
【解決問題】413錯(cuò)誤 413 Request Entity Too Large 接口返回413 報(bào)413nginx
博客背景：JAVA項(xiàng)目，前端想弄個(gè)便捷富文本，直接很多圖片轉(zhuǎn)base64編碼直接存庫了。字段為longtext類型。這種問題通常是在使用http請求對象太大的時(shí)候。。 1、如果是超長的話varchar類型改成longtext類型。 2、依舊懷疑超長的話，搜了一下longtext的最大長度 mysql里3種text類型的最
2024年02月07日
瀏覽(22)
解決Elasticsearch exception [type=circuit_breaking_exception, reason=[parent] Data too large問題
一、背景公司有一批8萬的數(shù)據(jù)存儲在Mysql中，然后我使用多線程的方式調(diào)用Elasticsearch的bulk()方法推送到ES，但是在推送過程中出現(xiàn)了該問題，這屬于插入數(shù)據(jù)時(shí)產(chǎn)生的問題二、異常三、解決辦法加大 -Xms 和 -Xmx 的值，比如 docker-compose.yaml 文件中可以這樣設(shè)置：四、解釋
2024年02月03日
瀏覽(26)
導(dǎo)入失敗，報(bào)錯(cuò)：“too many filtered rows xxx, “ErrorURL“:“
一、問題：注：前面能正常寫入，突然就報(bào)錯(cuò)，導(dǎo)入失敗，報(bào)錯(cuò)：“too many filtered rows xxx, \\\"ErrorURL\\\":\\\" {\\\"TxnId\\\":769494,\\\"Label\\\":\\\"datax_doris_writer_bf176078-15d7-414f-8923-b0eb5f6d5da1\\\",\\\"TwoPhaseCommit\\\":\\\"false\\\",\\\"Status\\\":\\\"Fail\\\",\\\"Message\\\":\\\" [INTERNAL_ERROR]too many filtered rows\\\",\\\" NumberTotalRows\\\":325476,\\\"NumberLoadedRows\\\":325473,\\\"
2024年01月18日
瀏覽(35)
Nginx報(bào)錯(cuò) HTTP 413 Request Entity Too Large（Payload Too Large）解決方案
上傳文件時(shí)，請求參數(shù)過大，導(dǎo)致超出服務(wù)端限制。客戶端發(fā)送的實(shí)體主體部分比服務(wù)器能夠或者希望處理的要大。? Nginx默認(rèn)最大能夠上傳1MB文件，打開nginx.conf在http{}中，找到server{}設(shè)置： client_max_body_size 30m;（配置客戶端請求實(shí)體最大值） client_body_buffer_size 128k;（配置請
2024年02月07日
瀏覽(24)
Data too long for column ‘xxxx‘ at row 1 解決辦法
很簡單的啦，往下看 Data too long for column ‘xxxx’ at row 1 第一種情況就是很普遍的，xxx字段長度不夠就是用Mybatis映射文件xml，字段匹配順序錯(cuò)誤即原來很短的一個(gè)列，插入了很長的數(shù)據(jù) 就是數(shù)據(jù)庫字符集的問題重新設(shè)置字符串長度仔細(xì)看一眼sql，就能排錯(cuò) PS：前端提出來
2024年02月07日
瀏覽(24)