MySQL刪除了記錄不生效的原因排查

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

  上周五進(jìn)行了一個(gè)大表刪除的操作，在刪除的過(guò)程中，出現(xiàn)了一點(diǎn)小問(wèn)題，白白花費(fèi)了兩個(gè)小時(shí)，我這里記錄了一下大概的過(guò)程，廢話不多說(shuō)了，直接看過(guò)程吧。

   當(dāng)時(shí)想進(jìn)行刪除，先測(cè)試了一下刪除語(yǔ)句的語(yǔ)法，刪了一條試了一下，如下：

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

[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)

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

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

   這個(gè)現(xiàn)象很奇怪，之前沒(méi)有遇到過(guò)，我首先是檢查了一下腳本，確認(rèn)刪除的腳本無(wú)誤后，又查了好半天，最后終于從事務(wù)的這個(gè)方向找到了一個(gè)突破口，懷疑是事務(wù)沒(méi)有提交導(dǎo)致的，于是看了一眼當(dāng)前事務(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)

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

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

[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被設(shè)置成了0，當(dāng)然就無(wú)法自動(dòng)提交了，于是改了這個(gè)參數(shù)為1，再次重試腳本，發(fā)現(xiàn)問(wèn)題依舊。。。

看來(lái)還是改的不徹底。

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

總結(jié)，下面幾個(gè)小的知識(shí)點(diǎn)需要注意一下：

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

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

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

4、my.cnf文件有加載順序，改動(dòng)的時(shí)候，需要全部都變更?；蛘弑ＷC只存在一個(gè)my.cnf文件。

以上就是MySQL刪除了記錄不生效的原因排查的詳細(xì)內(nèi)容，更多關(guān)于MySQL刪除了記錄不生效的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！