› MySQL 5.5 Community Server
› MySQL 5.6 Community Server
› Percona Configuration Wizard
› XtraBackup 搭建主从复制
Great Sites on MySQL
› Percona
› MySQL Performance Blog
› Severalnines
推荐管理工具
› Sequel Pro
› phpMyAdmin
推荐书目
› MySQL Cookbook
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
这是一个创建于 1478 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 表结构
+---------------+--------------+------+-----+---------+----------------+
| 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" 这样的参数进行校验呢?
8 条回复 • 2020-12-11 14:18:00 +08:00
 |
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
我自己的一个猜想，ｍｙｓｑｌ遇到这种答非所问会根据字段的类型对对比值进行转换
很明显的一个类型转换操作，１ gggg 可以转换成１ 但 ggg1 是不能转换为１的； 我觉得不需要过分担忧，毕竟自己在业务设计时就不应该让它出现这种情况 |
 |
7
ben1024 2020-12-11 13:46:41 +08:00 1
这个要通过数据库是否开启严格验证影响
|
Select Language