Mysql int 字段 字符串比较查询的一个问题

[SjwNo1]

• 表结构

+---------------+--------------+------+-----+---------+----------------+
| Field         | Type         | Null | Key | Default | Extra          |
+---------------+--------------+------+-----+---------+----------------+
| id            | int(32)      | NO   | PRI | NULL    | auto_increment |
| created_at    | datetime     | NO   |     | NULL    |                |
| updated_at    | datetime     | NO   |     | NULL    |                |
| name          | varchar(64)  | NO   |     | NULL    |                |
+---------------+--------------+------+-----+---------+----------------+

• 数据 (就 1 条)

*************************** 1. row ***************************
           id: 1
   created_at: 2020-10-29 08:48:28
   updated_at: 2020-10-29 08:48:28
         name: 文件夹 1

• 查询语句
  select * from repository_folder_nodes where id="1aaaaaa" \G

• 结果
  结果就是可以查到那条数据

• 疑问
  上面的现象应该是由于比较时 string 转了数字，那么在开发中是否需要对类似于 "1aaaaa" 这样的参数进行校验呢?

[l00t]

看你高兴啊。

[SjwNo1]

@l00t 这好像在业务校验中蛮重要的，需要检是否是纯数字

[l00t]

@SjwNo1 #2 业务是你们的业务，你们认为重要就校验，你们认为不重要就不校验。ID 在前端是否可以输入，以及是否可以输入 1aaaa， 以及输入 1aaaa 时应当是个怎样的行为表现，这是你们定义的，不需要问别人。

[HENQIGUAI]

如果是强类型语言，id 的类型是对应的 int 或者 Integer, 就不会有这种问题，要校验也只是校验枚举或者判空。让 MySQL 帮你做这种徒劳无意义的转换，我认为不应当。

[zyyzj]

数据库层执行的命令，最好是明确无误的。如果要匹配查询 ，就明确用 like 之类的运算符。
参数校验应该在业务层中完成。
像上面示例中的，一个 int 型字段，查询用了""字符型的值，可以当作程序的 BUG 对待。

[edk24]

我自己的一个猜想，ｍｙｓｑｌ遇到这种答非所问会根据字段的类型对对比值进行转换

很明显的一个类型转换操作，１ gggg 可以转换成１

但 ggg1 是不能转换为１的；　我觉得不需要过分担忧，毕竟自己在业务设计时就不应该让它出现这种情况

[ben1024]

这个要通过数据库是否开启严格验证影响

[SjwNo1]

@edk24 刚刚在业务加了判断，之前疏忽了