記一次資料庫踩下的坑

2022-02-11 09:59:59 字數 1105 閱讀 9941

公司部署了一套系統,之前在別的地方部署沒有問題,執行正常,但是在濟南部署時就出現了問題

出現的問題是:錯誤日誌資訊不能插入錯誤資訊的日誌表中,導致前台查不到錯誤資訊資料

(1)首先檢視錯誤日誌查詢的sql,確實沒有資料產生,這就排除了是前台不載入的問題

(2)之後排查節點狀態記錄表,發現錯誤記錄的標誌產生,但是沒有把詳情插入另一張表

(3)反推的時候發現,乙個檔案的流程節點狀態本該是五個的,現在變成了10個,翻了一倍,

猜想是資料執行更新的時候,沒有執行更新,而是執行了插入

(4)排查到一籌莫展,無奈請了資料庫大神來排查

(5)大神果然不同,開啟資料庫查詢資料庫程序,發現有乙個sql一直執行,從未停止

(6)把sql複製出來,單獨執行,確實停不下來,大神在系統裡查詢資料庫的快取配置【buffer pool size】,調大再試,不行

(7)那會是資料庫在linux系統佔滿導致不能執行的嗎?

我們的現場系統占用的都是虛擬機器,檢視mysql的掛載狀態,發現mysql掛到了乙個已經占用74%的盤上

大神堅定的說,這就試問題所在,快,把mysql掛到另乙個獨立的系統分割槽,軟連線到這個地方

把目錄下檔案移動,改動mysql的【my.cnf】檔案,修改檔案路徑

結果依舊,這就幾乎可以排除空間不夠和磁碟壞道問題

(8)那sql為什麼會執行這麼慢?

檢視linux系統程序執行狀態,看my.cnf檔案,

最後大神開啟表結構發現是字符集指定成了二進位制格式,修改為【utf-8-general-ci後】,4秒完成連線查詢和校驗,錯誤資訊插入成功

(9)檢視發現資料庫建庫時,字符集指定為bin型別,所以之後過程呼叫在該資料庫建表時,預設使用了該字符集,修改資料庫字符集成功

(1)如果發現資料查詢很慢,很可能是【字符集設定不正確】,導致資料查詢效率極慢,資料量大尤其明顯

(1)大神修改之後感嘆,上次他碰到的另乙個問題

一次現場系統公升級,系統癱了,發現json解析的時候出了錯,最後排查發現是打包的時候jdk使用了1.8版本

而現場環境是1.7版本,也是一起活生生的血淚史啊!!!

在此與大家共勉,也給大家提供大神的排查思路

記一次資料庫遷移遇到的坑

因為一開始專案中用的是oracle的資料庫,後來因為一些原因需要換成mysql的。由於oracle中所有庫表 欄位名都是大小不敏感的,所以專案中各種大寫小寫都有人用,但是遷移到mysql上面,他是區分的,然後就把mysql也設定成不區分大小寫了,並且字符集也設定成了utf8 general ci。後...

記一次資料庫的實戰

話不多說 直接開始 開始我們的敲 的工程吧 首先匯入標頭檔案 import tkinter import tkinter.messagebox import pandas as pd import numpy as np import matplotlib.pyplot as plt from sk...

記一次資料庫事務鎖

最近在做專案的時候碰到乙個問題,事務鎖。transactionoptions tos new transactionoptions tos.isolationlevel isolationlevel.repeatableread 行鎖 只會鎖住當前操作的那一行資料,當前表的其他資料不受影響。已驗證 ...