標(biāo)題: mysql寫新數(shù)據(jù)時(shí)某列值總是被自動(dòng)修改 [打印本頁(yè)]
作者: hubaba    時(shí)間: 2016-4-7 23:13
標(biāo)題: mysql寫新數(shù)據(jù)時(shí)某列值總是被自動(dòng)修改
0、導(dǎo)讀

往表里寫入新數(shù)據(jù)時(shí)，卻一直報(bào)告主鍵沖突，某列值一直被重置為一個(gè)固定值，疑似被黑，啥情況？

1、問題描述

某朋友的線上數(shù)據(jù)庫(kù)，懷疑被侵入了。具體表象是：INSERT的時(shí)候，某列值總被自動(dòng)改成一個(gè)固定值。

他們先自查了 TRIGGER 和 EVENT，都是空的，確定不是因?yàn)檫@兩種原因引起，實(shí)在想不出是哪里被動(dòng)了手腳。

問題的現(xiàn)象：

MariaDB [information_schema]> use bbs9;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed

MariaDB [bbs9]> INSERT INTO cdb_mythreads_latest (uid,username,tid,fid,subject,special,dateline) VALUES ('1239009','yayv','13482713','815','bbs5 ................','0','1459569279');

ERROR 1062 (23000): Duplicate entry '1239009-8388607' for key 'PRIMARY'

可以看到，tid列的值被從 13482713(原始值) 自動(dòng)替換成了 8388607(篡改值)。

更讓人奇怪的是，這條SQL在mysql client端手動(dòng)執(zhí)行手，也會(huì)報(bào)告同樣的錯(cuò)誤。究竟是什么黑客這么牛逼呢，百思不得其解~~~

2、原因分析

單從現(xiàn)象來看，好像還真是被黑了的意思。

but，但是，可是，你如果足夠細(xì)心，就會(huì)發(fā)現(xiàn)端倪。

為什么這么說呢，因?yàn)?8388607 這個(gè)數(shù)值是不是看起來挺眼熟的？嗯，沒錯(cuò)，你才對(duì)了，這個(gè)值是 MEDIUMINT 類型的最大值，而 MEDIUMINT UNSIGNED 的最大值是 16777215。

當(dāng)然了，你再認(rèn)真看一眼表的名字是什么：cdb_mythreads_latest，我又要呵呵了，你懂得的。

3、其他建議

既然原因已經(jīng)清楚了，那么解決起來也就簡(jiǎn)單了，只需要把tid列類型改成INT UNSIGNED，甚至BIGINT UNSIGNED都行。

MEDIUMINT和INT兩種類型，也只是差了1個(gè)字節(jié)，何必呢。與其在這個(gè)地方節(jié)約1個(gè)字節(jié)，還不如在別的CHAR/VARCHAR/TEXT列調(diào)整下，其優(yōu)化效果要好的多得多。

4、相關(guān)案例



歡迎光臨 (http://www.torrancerestoration.com/bbs/) Powered by Discuz! X3.1