今天，又掉坑了。 之前踩到過MySQL主鍵溢出的情況，通過prometheus監控起來了，具體見這篇MySQL主鍵溢出復盤

這次遇到的坑，更加的隱蔽。 是一個log表里面的一個int signed類型的列寫滿了?？焖俚慕鉀Q方法當然還是只能切新表來救急了，然后搬遷老表的部分歷史數據到熱表。

亡羊補牢，處理完故障后，趕緊寫腳本把生產的其他表都捋一遍。

下面是我暫時用的一個檢測腳本，還不太完善，湊合用

分2個文件（1個sql文件，1個shell腳本）

check.sql 內容如下：

SELECT cast( pow(2, case data_type when ’tinyint’ then 7 when ’smallint’ then 15 when ’mediumint’ then 23 when ’int’ then 31 when ’bigint’ then 63 end+(column_type like ’% unsigned’))-1 as decimal(30,0)) as max_int,’ - ’,concat (’(’, concat(’select ’,’max(’,COLUMN_NAME,’)’,’ from ’,TABLE_SCHEMA,’.’,TABLE_NAME),’)’) from information_schema.COLUMNS where TABLE_SCHEMA NOT IN (’information_schema’,’sys’,’test’,’mysql’,’performance_schema’) AND DATA_TYPE IN (’int’ ) ;

直接到數據庫里面執行，效果類似這樣：

check.sh 內容如下：

#!/bin/bash# 監測int類型的當可用空間少500w的時候，提醒做DDL操作 # 設置 session級別的 max_execution_time為2秒，防止沒有索引的大的拖慢數據庫，但是這樣可能漏判部分列，需要注意下# 注意：我這里bigint類型的沒有檢查，如果需要請修改 check.sql where條件中的DATA_TYPE加上 bigint的檢查source /etc/profileset -umkdir $(date +%F) -pv# step1 檢測for host in {’192.168.1.100’,’192.168.1.110’,’192.168.1.120’,’192.168.1.130’}; domysql -udts -pdts -h${host} -BN < check.sql 2>/dev/null > sql.logwaitecho '說明： | 當前列允許的最大值 | 巡檢用的SQL ' >> $(date +%F)/$host.logwhile read line; do ret=$(mysql -udts -pdts -h${host} -BNe 'set session max_execution_time=2000;select $line' 2>/dev/null) echo ${ret} if [[ '${ret}' == 'NULL' ]]; then continue fi if [ ${ret} -lt 5000000 ] ; then echo '$line 剩余空間 ${ret}, 該表可用水位不足500W，建議做DDL修改為bigint類型' >> $(date +%F)/$host.log fidone < ./sql.logdone# step2 將檢查的內容打包發郵件（這里可能需要根據自己生產的情況改改）tar czf $(date +%F).tar.gz $(date +%F)sendemail -s 192.168.1.200 -f post@domain.com -t ergou@domain.com -a $(date +%F).tar.gz -u '$(date +%F) int水位線巡檢日志' -o message-content-type=html -o message-charset=utf8 -m '內容詳見附件'# step3 清理每日生成的以日期命名的目錄和tar.gz文件，這里我就不貼命令

再配個每天上午10點的cronjob即可，

最終每天收到郵件里面內容大致類似如下：

到此這篇關于詳解MySQL 表中非主鍵列溢出情況監控的文章就介紹到這了,更多相關MySQL 非主鍵列溢出內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！