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

這次遇到的坑，更加的隱蔽。 是一個log表裡面的一個int signed型別的列寫滿了。快速的解決方法當然還是隻能切新表來救急了，然後搬遷老表的部分歷史資料到熱表。

亡羊補牢，處理完故障後，趕緊寫指令碼把生產的其他表都捋一遍。

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

分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/profile
set -u

mkdir $(date +%F) -pv

# step1 檢測
for host in {'192.168.1.100','192.168.1.110','192.168.1.120','192.168.1.130'}; do

mysql -udts -pdts -h${host} -BN < check.sql  2>/dev/null > sql.log
wait

echo "說明： | 當前列允許的最大值 | 巡檢用的SQL   " >> $(date +%F)/$host.log

while 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
  
  fi
done < ./sql.log

done

# step2 將檢查的內容打包發郵件（這裡可能需要根據自己生產的情況改改）
tar czf $(date +%F).tar.gz $(date +%F)
sendemail -s 192.168.1.200 -f [email protected] -t [email protected] -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 非主鍵列溢位內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！