我要寫這樣一個sql select * from tableA where id in (1234, 342, 54245)xml文件部分如下
select ah.*
FROM
tableA ah
WHERE
user_id > 0 and is_done = 'Y' and
announced_time >= #{startTime} and
announced_time <= #{endTime} and
ah.active_id in
<foreach collection="activeIds" item="activeId" index="index" open="(" close=")" separator=",">
#{activeId}
</foreach>
order by id desc
這是方法:
public List<A> find(@Param("activeIds")List<String> activeIds, @Param("startTime")Date startTime, @Param("endTime")Date endTime);
我傳入的List<String> 是這樣的{123-1, 234-2,444-5}
這樣sql就變成了 ....where active_id in (123, 234, 444) 也就是說自動把"-"符號后面的去掉了。
其實這個是因為我寫代碼的時候本來就是要取"-"前面的數(shù)的，失誤寫錯了。。直接傳進去了。但也恰好實現(xiàn)了這個功能。。
我的問題是。mybatis什么時候做的這個截取。。我看了一下源碼，找不到。。希望可以得到幫助。。謝謝。
1 回答
慕標5832272
TA貢獻1966條經驗 獲得超4個贊
與mybatis沒有關系，是MySQL的隱式類型轉換問題
下面來分析一下隱式轉換的規(guī)則：
兩個參數(shù)至少有一個是 NULL 時，比較的結果也是 NULL，例外是使用 <=> 對兩個 NULL 做比較時會返回 1，這兩種情況都不需要做類型轉換
兩個參數(shù)都是字符串，會按照字符串來比較，不做類型轉換
兩個參數(shù)都是整數(shù)，按照整數(shù)來比較，不做類型轉換
十六進制的值和非數(shù)字做比較時，會被當做二進制串
有一個參數(shù)是 TIMESTAMP 或 DATETIME，并且另外一個參數(shù)是常量，常量會被轉換為 timestamp
有一個參數(shù)是 decimal 類型，如果另外一個參數(shù)是 decimal 或者整數(shù)，會將整數(shù)轉換為 decimal 后進行比較，如果另外一個參數(shù)是浮點數(shù)，則會把 decimal 轉換為浮點數(shù)進行比較
所有其他情況下，兩個參數(shù)都會被轉換為浮點數(shù)再進行比較
與題主相關的只有最后一條：
問題可以簡單歸納像如下的情況：
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
INSERT INTO `user` (`id`)
VALUES
(123);mysql> SELECT * FROM USER WHERE id IN ( '123-1' ,'124-1' );
+-----+
| id |
+-----+
| 123 |
+-----+等價于：
SELECT * FROM USER WHERE id = '123-1' or id = '124-1';id是int類型，參數(shù)是字符類型，不同類型比較的過程中,會發(fā)生上述的mysql隱式類型轉換，兩個參數(shù)都會被轉換為浮點數(shù)再進行比較。
mysql> select '123-1'=123;
+-------------+
| '123-1'=123 |
+-------------+
| 1 |
+-------------+
1 row in set, 1 warning (0.00 sec)'123-1'轉換成浮點類型是：
mysql> select '123-1'+0.0;
+-------------+
| '123-1'+0.0 |
+-------------+
| 123 |
+-------------+
1 row in set, 1 warning (0.00 sec)我們看到'123-1'和123轉換成浮點型后數(shù)值上是相等的，所以
由于 MySQL 隱式類型轉換規(guī)則比較復雜，依賴 MySQL 隱式轉換很容易出現(xiàn)各種想想不到的問題，所以建議代碼做嚴格的類型查詢。
添加回答
舉報
0/150
提交
取消