gpt4 book ai didi

mysql、预处理语句和自动类型转换

转载 作者:行者123 更新时间:2023-11-29 03:13:02 26 4
gpt4 key购买 nike

我在使用常规语句和准备语句执行完全相同的查询时得到不同的结果,我认为这是一个类型转换错误。

mysql> show columns from server where field = "vlan";
+-------------+--------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------+------+-----+---------+-------+
| vlan | int(5) | YES | MUL | NULL | |
+-------------+--------+------+-----+---------+-------+

mysql> select hostname from server where `vlan` = '184.182' limit 1;
Empty set (0.00 sec)

mysql> prepare stupid from "select hostname from server where `vlan` = ? limit 1";
Query OK, 0 rows affected (0.00 sec)
Statement prepared

mysql> set @vlan = '184.182';
Query OK, 0 rows affected (0.00 sec)

mysql> execute stupid using @vlan;
+-------------------+
| hostname |
+-------------------+
| web20.servers.com |
+-------------------+
1 row in set (0.00 sec)

vlan的实际值为184

看起来 mysql 处理类型转换的方式对于准备语句和常规语句是不同的?那有意义吗?我该如何解决这个问题?

最佳答案

准备好的语句参数的预期数据类型在语句准备时确定,并且在语句执行之前发生到该数据类型的类型转换。

在您的示例中,需要一个整数参数;因此,在语句执行之前,将提供的字符串转换为整数 (184),并且整数列 vlan 与参数之间的比较对于匹配记录成功。

相比之下,“常规”语句将整数列与字符串进行比较;因此参数作为 float 进行比较,并且没有记录具有匹配的 vlan

为避免这种情况,请确保在准备时无法确定数据类型(或者确定的数据类型不会丢失任何信息)——例如:

prepare not_so_stupid from
"select hostname from server where `vlan` = CAST(? AS CHAR) limit 1"
;

关于mysql、预处理语句和自动类型转换,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5189224/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com