mysql bind_param变量类型为什么不遵循规则

我正在使用以下带有bind_参数的查询：

$qry=" UPDATE `prog_m` SET prog_descr=? WHERE prog_id=? ";
$stmt= $conn->prepare($qry);
$stmt->bind_param('si', $content_text, $prog_id);

在代码中，如果我将两个变量都绑定为字符串，那么prog_id显然是整数

bind_param('ss', $content_text, $prog_id);

---

代码仍然有效。谁能解释一下MySQL是如何隐式执行数据类型转换的吗

作为示例，请考虑：

SELECT 4       + 1
     , ' 4'    + 1
     , '4tune' + 1

我们还可以显式地进行数据类型转换，例如，使用

CAST

或

CONVERT

从字符串到数字的转换非常简单。该行为记录在MySQL参考手册中：

---

我们可以在具体的例子中观察到这种行为。考虑数字文字的情况：

UPDATE `prog_m` SET prog_descr = 'foo' WHERE prog_id = 42 ;

并与字符串文字进行比较

UPDATE `prog_m` SET prog_descr = 'bar' WHERE prog_id = '42' ;
                                                       ^  ^

如果

prog\u id

列是数字，MySQL将执行字符串文本到数字的隐式转换

如果

prog_id

是字符类型，在第一种情况下，MySQL会隐式地将数字文本转换为字符串

如果

prog\u id

是字符类型的列，在第一种情况下，MySQL隐式地将列值转换为数字，并与数字文本进行比较

---

---

另外，使用带绑定占位符的预处理语句也值得称赞

太好了！非常感谢你的完美解释。在示例语句中，如果prog_id参数在绑定时定义为字符串，它是否仍应保护sql注入？是。使用带有绑定占位符的准备好的语句是缓解SQL注入漏洞的标准模式。通过绑定占位符/参数提供的值就是：值。值是否为字符串并不重要。如果我们传递的是一个整数值，那么在bind_参数中将其指定为类型是有意义的。（为了未来读者的利益，这更好地记录了我们的意图。）仅仅因为当我们将整数绑定为字符串时它是有效的，并不是将所有参数绑定为字符串的理由。它完美地澄清了混淆！