記得之前寫過一篇關(guān)于存儲過程刪除語句的博客，其實就是這個問題，今天又遇到了，問題是我居然搞了好久都沒想起來。

下面看代碼

BEGIN/* 更新采集任務(wù)狀態(tài) */DECLARE v_id BIGINT;DECLARE v_navclueId BIGINT;DECLARE v_keyWord VARCHAR(255);DECLARE v_path TEXT;DECLARE v_collectStatus VARCHAR(20);DECLARE v_status TINYINT;DECLARE done INT;DECLARE v_ct INT;-- 定義游標(biāo)DECLARE cur CURSOR FOR SELECT bk.`RECORDID` recordId,bk.`KEYWORD` keyWord, bk.`WORDPATH` path, bk.`NAVCLUEID` navclueId FROM `bdexpand`.`KEYWORDS` bk INNER JOIN (SELECT `TASKID`,`CREATETIME` FROM `bdexpand`.`TASK` WHERE `AUTHOR`=author LIMIT startPage,pageNumber) bt ON bk.`TASKID`=bt.`TASKID` WHERE bk.`STATUS` != -1 ORDER BY bt.`CREATETIME` DESC;-- 定義結(jié)束標(biāo)記DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;OPEN cur;stuLoop:LOOPFETCH cur INTO v_id, v_keyWord, v_path,v_navclueId;IF done = 1 THENLEAVE stuLoop;END IF;SELECT v_id; END LOOP stuLoop;CLOSE cur; END

這個存儲過程表面看起來沒有問題，沒有語法錯誤，運行的時候也不報錯，但是仔細(xì)查看運行結(jié)果，會發(fā)現(xiàn)在循環(huán)里面輸出的數(shù)據(jù)很多都不是想要的

我本地單獨運行下面的語句會得到5條符合要求的數(shù)據(jù)

SELECT bk.`RECORDID` recordId,bk.`KEYWORD` keyWord, bk.`WORDPATH` path, bk.`NAVCLUEID` navclueId FROM `bdexpand`.`KEYWORDS` bk INNER JOIN (SELECT `TASKID`,`CREATETIME` FROM `bdexpand`.`TASK` WHERE `AUTHOR`=author LIMIT startPage,pageNumber) bt ON bk.`TASKID`=bt.`TASKID` WHERE bk.`STATUS` != -1 ORDER BY bt.`CREATETIME` DESC;

但是運行存儲過程會輸出十多條數(shù)據(jù)，很多都不滿足?`AUTHOR`=author 這個條件，為什么會出現(xiàn)這種情況？

MYSQL的存儲過程傳入?yún)?shù)（author）如果與表字段名（`AUTHOR`）相同（不區(qū)分大小寫），存儲過程就會把這個約束條件忽略，如上面的語句放到存儲過程中就相當(dāng)于

SELECT bk.`RECORDID` recordId,bk.`KEYWORD` keyWord, bk.`WORDPATH` path, bk.`NAVCLUEID` navclueId FROM `bdexpand`.`KEYWORDS` bk INNER JOIN (SELECT `TASKID`,`CREATETIME` FROM `bdexpand`.`TASK` LIMIT startPage,pageNumber) bt ON bk.`TASKID`=bt.`TASKID` WHERE bk.`STATUS` != -1 ORDER BY bt.`CREATETIME` DESC;

所以在存儲過程里面千萬記得在字段名前面帶上表名，這樣才能確保不會出問題

轉(zhuǎn)載于:https://www.cnblogs.com/quyixuanblog/p/5581185.html

總結(jié)

以上是生活随笔為你收集整理的存储过程传入参数与表字段名相同时产生的问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。