MySQL刪除了記錄不生效的原因排查
線上的一次MySQL事務問題記錄
上週五進行了一個大表刪除的操作,在刪除的過程中,出現了一點小問題,白白花費了兩個小時,我這裡記錄了一下大概的過程,廢話不多說了,直接看過程吧。
當時想進行刪除,先測試了一下刪除語句的語法,刪了一條試了一下,如下:
mysql ::>>select min(id) from XXXX_user_login; +---------+ | min(id) | +---------+ | | +---------+ row in set (0.00 sec) mysql ::>>delete from XXXX_user_login where id < ; Query OK,row affected (0.00 sec) mysql ::>>select min(id) from XXXX_user_login; +---------+ | min(id) | +---------+ | | +---------+ row in set (0.00 sec)
然後重新使用mysql客戶端登入進去,發現了一個奇怪的問題:
[dba_mysql ~]$ /usr/local/mysql/bin/mysql -udba_admin -p -h127.0.0.1 -P4306 Enter password: XXXXXXXXXXXXXXXXXXXXXX Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql ::>>select min(id) from XXXXX_user_login; +---------+ | min(id) | +---------+ | | +---------+ row in set (0.00 sec)
也就是剛才刪除掉的那一條記錄又重新回來了。
想想覺得挺奇怪的,是不是我刪除錯了,或者說刪除之後,業務方又重新插入了資料,這不是出問題了麼。。。又重新試了幾次,都是一樣的效果。
這個現象很奇怪,之前沒有遇到過,我首先是檢查了一下指令碼,確認刪除的指令碼無誤後,又查了好半天,最後終於從事務的這個方向找到了一個突破口,懷疑是事務沒有提交導致的,於是看了一眼當前事務的引數,如下:
mysql ::>>show variables like '%commit%'; +--------------------------------+-------+ | Variable_name | Value | +--------------------------------+-------+ | autocommit | OFF | | innodb_commit_concurrency | | | innodb_flush_log_at_trx_commit | | +--------------------------------+-------+ rows in set (0.00 sec) [email protected]:(none) ::>> mysql ::>>show global variables like '%commit%'; +--------------------------------+-------+ | Variable_name | Value | +--------------------------------+-------+ | autocommit | ON | | innodb_commit_concurrency | | | innodb_flush_log_at_trx_commit | | +--------------------------------+-------+ rows in set (0.00 sec)
看到這個,基本上問題就已經確定了,是因為當前會話中的自動提交被設定成了off,所以刪除的時候,貌似已經成功了,重啟之後再看,這些事務被回滾了,所以就好像刪除操作"失效"一樣。
那既然已經定位到了問題,就開始找這個問題的根本原因,最終在配置檔案中找到了最根本的原因,如下:
[mysqldump] quick max_allowed_packet = M [mysql] no-auto-rehash max_allowed_packet = M prompt=mysql--\\u@\\h:\\d \\R:\\m:\\s>> init-command="set interactive_timeout=28800;set wait_timeout=28800;set autocommit=0;"
配置檔案中的最後一行,mysql客戶端組的配置autocommit被設定成了0,當然就無法自動提交了,於是改了這個引數為1,再次重試指令碼,發現問題依舊。。。
看來還是改的不徹底。
我們知道,mysql載入配置檔案有一個順序,我們可以使用mysql --help|grep my.cnf的命令來檢視,經過檢視,是因為/etc/my.cnf中的配置也是autocommit=0,所以就把當前這個配置檔案的引數給覆蓋了,最終,改完/etc/my.cnf檔案中的autocommit引數內容之後,重新連線mysql伺服器,發現問題解決。
總結,下面幾個小的知識點需要注意一下:
1、當發現數據無法刪除之後,可以先看看事務提交的引數是否設定成了off
2、使用show variables和show global variables可以分別檢視當前會話和全域性變數的事務引數;
3、my.cnf檔案中的mysql組中的引數是用來控制mysql客戶端的配置的。
4、my.cnf檔案有載入順序,改動的時候,需要全部都變更。或者保證只存在一個my.cnf檔案。
以上就是MySQL刪除了記錄不生效的原因排查的詳細內容,更多關於MySQL刪除了記錄不生效的資料請關注我們其它相關文章!