关于go:php程序员转go常犯的错误sql中in功能的使用

2次阅读

共计 933 个字符,预计需要花费 3 分钟才能阅读完成。

我想要实现这样的成果
select * from table_name where id in (1,2,3)
代码是这么写的。

where := `id in (?)`
sb := sqlbuilder.NewStruct(data{}).SelectFrom("table_name")

sqlText, args := sb.Where(where).Build()

var temp []string
for _, v := range IDs {temp = append(temp, fmt.Sprintf("%d", v))
}
IDString := strings.Join(temp, ",")

args = []interface{}{IDString}
rows, err := client.DBClient(ctx).Query(sqlText, args...)
err = orm.ScanRows(rows, &dataResult)

// dataResult 返回后果空值

log.Infof("rawsql=%v",  util.FormatSql(sqlText, args...))

通过 log 打印进去的 sql 是这个样子的
select * from table_name where id in (1,2,3)

完全符合预期,拿这个 sql 在数据库里间接执行,也能查出后果。
这个让我很奇怪。这不就是把 sql 拼进去搞进去一个字符串吗?难道是 in 应该用大写 IN?
试了下,不行。

而后我就想到还有一个 go 里封装好的专门用于 in 语句的办法,于是改成这样

sb := sqlbuilder.NewStruct(data{}).SelectFrom("table_name")

sqlText, args :=  sb.Where(sb.In(`id`, sqlbuilder.Flatten(IDs)...)).Build()

这么写就齐全 ok 了。
狐疑是不是 mysql 遇到这种,先 pre,而后变量替换的场景时,为了平安,执行前把字符串型值进行了非凡解决,例如加了引号?问了专家,专家说数据安全性由应用程序保障,数据库还是只做它业余的事件。
那就有可能是 go 客户端给加了引号之类的吧,跟了下代码,也没找到是哪解决的。

总结:
就当做一个论断记下就好了,当前遇到应用 in 性能的时候,都应用前面这种办法。

正文完
 0