+---------------+--------------+------+-----+---------+----------------+
| 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. 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" 这样的参数进行校验呢?
1
l00t 2020-12-11 12:44:04 +08:00 1
看你高兴啊。
|
3
l00t 2020-12-11 12:51:09 +08:00
@SjwNo1 #2 业务是你们的业务,你们认为重要就校验,你们认为不重要就不校验。ID 在前端是否可以输入,以及是否可以输入 1aaaa, 以及输入 1aaaa 时应当是个怎样的行为表现,这是你们定义的,不需要问别人。
|
4
HENQIGUAI 2020-12-11 12:51:34 +08:00
如果是强类型语言,id 的类型是对应的 int 或者 Integer, 就不会有这种问题,要校验也只是校验枚举或者判空。让 MySQL 帮你做这种徒劳无意义的转换,我认为不应当。
|
5
zyyzj 2020-12-11 13:13:04 +08:00 1
数据库层执行的命令,最好是明确无误的。如果要匹配查询 ,就明确用 like 之类的运算符。
参数校验应该在业务层中完成。 像上面示例中的,一个 int 型字段,查询用了""字符型的值,可以当作程序的 BUG 对待。 |
6
edk24 2020-12-11 13:40:15 +08:00 1
我自己的一个猜想,mysql遇到这种答非所问会根据字段的类型对对比值进行转换
很明显的一个类型转换操作,1 gggg 可以转换成1 但 ggg1 是不能转换为1的; 我觉得不需要过分担忧,毕竟自己在业务设计时就不应该让它出现这种情况 |
7
ben1024 2020-12-11 13:46:41 +08:00 1
这个要通过数据库是否开启严格验证影响
|