線上的一次MySQL事務(wù)問題記錄

上周五進行了一個大表刪除的操作，在刪除的過程中，出現(xiàn)了一點小問題，白白花費了兩個小時，我這里記錄了一下大概的過程，廢話不多說了，直接看過程吧。

當時想進行刪除，先測試了一下刪除語句的語法，刪了一條試了一下，如下：

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客戶端登錄進去，發(fā)現(xiàn)了一個奇怪的問題：

[dba_mysql ~]$ /usr/local/mysql/bin/mysql -udba_admin -p -h127.0.0.1 -P4306Enter password: XXXXXXXXXXXXXXXXXXXXXXType ’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)

也就是剛才刪除掉的那一條記錄又重新回來了。

想想覺得挺奇怪的，是不是我刪除錯了，或者說刪除之后，業(yè)務(wù)方又重新插入了數(shù)據(jù)，這不是出問題了么。。。又重新試了幾次，都是一樣的效果。

這個現(xiàn)象很奇怪，之前沒有遇到過，我首先是檢查了一下腳本，確認刪除的腳本無誤后，又查了好半天，最后終于從事務(wù)的這個方向找到了一個突破口，懷疑是事務(wù)沒有提交導(dǎo)致的，于是看了一眼當前事務(wù)的參數(shù)，如下：

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)mysql--dba_admin@127.0.0.1:(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)

看到這個，基本上問題就已經(jīng)確定了，是因為當前會話中的自動提交被設(shè)置成了off，所以刪除的時候，貌似已經(jīng)成功了，重啟之后再看，這些事務(wù)被回滾了，所以就好像刪除操作'失效'一樣。

那既然已經(jīng)定位到了問題，就開始找這個問題的根本原因，最終在配置文件中找到了最根本的原因，如下：

[mysqldump]quickmax_allowed_packet = M[mysql]no-auto-rehashmax_allowed_packet = Mprompt=mysql--u@h:d R:m:s>>init-command='set interactive_timeout=28800;set wait_timeout=28800;set autocommit=0;'

配置文件中的最后一行，mysql客戶端組的配置autocommit被設(shè)置成了0，當然就無法自動提交了，于是改了這個參數(shù)為1，再次重試腳本，發(fā)現(xiàn)問題依舊。。。

看來還是改的不徹底。

我們知道，mysql加載配置文件有一個順序，我們可以使用mysql --help|grep my.cnf的命令來查看，經(jīng)過查看，是因為/etc/my.cnf中的配置也是autocommit=0，所以就把當前這個配置文件的參數(shù)給覆蓋了，最終，改完/etc/my.cnf文件中的autocommit參數(shù)內(nèi)容之后，重新連接mysql服務(wù)器，發(fā)現(xiàn)問題解決。

總結(jié)，下面幾個小的知識點需要注意一下：

1、當發(fā)現(xiàn)數(shù)據(jù)無法刪除之后，可以先看看事務(wù)提交的參數(shù)是否設(shè)置成了off

2、使用show variables和show global variables可以分別查看當前會話和全局變量的事務(wù)參數(shù)；

3、my.cnf文件中的mysql組中的參數(shù)是用來控制mysql客戶端的配置的。

4、my.cnf文件有加載順序，改動的時候，需要全部都變更。或者保證只存在一個my.cnf文件。

以上就是MySQL刪除了記錄不生效的原因排查的詳細內(nèi)容，更多關(guān)于MySQL刪除了記錄不生效的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！