应该使用 select * 吗?

2020 年 8 月 4 日
 lux182

在使用同样索引,同样需要回表查询的情况下,应该使用

  1. select * 还是 2. select 字段,字段,...

我能想到的使用后者的优点可能就是节省那么一点点带宽,

缺点是极大的影响开发效率和维护难度,并且 mapper 文件难看,难懂

10026 次点击
所在节点    程序员
72 条回复
panhongx
2020 年 8 月 4 日
@hello826 你好像审错题了
gz911122
2020 年 8 月 4 日
@lolizeppelin 跟顺序有什么关系啊?
lux182
2020 年 8 月 4 日
@lolizeppelin
@gz911122 没遇到影响顺序的场景
lux182
2020 年 8 月 4 日
@lolizeppelin
”新字段不在最后一行的时候,你 model 全乱“ ,这点我一直没遇到过,你的场景是什么啊,用的什么框架?
”遇到需要热更需要先升级数据库,再慢慢升级程序的时候,你 select*咋搞” ,这种情况也是比较常见的,我们也经常先更新数据库,后上程序的。所以还是不知道你的场景。
所以你说的这几点没有说服力。
lux182
2020 年 8 月 4 日
@brader 不是语言的问题,而是框架设计问题。我看过一些 python 程序员喜欢直接拿数据库 map 结果返回前端
lux182
2020 年 8 月 4 日
@admol “如果先上数据库, 你线上代码还是老的, 还没有那个新的字段, 代码全是 select * , 而你与之对应的 model 肯定是没有这个字段, 如何与它映射? 是否会报错? java 的 mybatis 至少会.”
我使用过程中,这种情形很多,mybatis 不会报错的
lolizeppelin
2020 年 8 月 4 日
@lux182
那我知道了
框架里 map 字段,压根就不需要你关心是 select*还是 select 字段
wakzz
2020 年 8 月 4 日
单单考虑业务的问题,也不建议用 select *,因为一旦业务变更数据库新增字段,就会导致线上程序 sql 映射错误,不好向前兼容。
gz911122
2020 年 8 月 4 日
@wakzz 新增字段无影响吧?
为什么会导致映射错误呢?
VictorJing94
2020 年 8 月 4 日
@lux182 楼下说清楚了.......应该不需要我再重复了吧
useben
2020 年 8 月 4 日
看查询的索引类型, 不同不同处理
wangbudong
2020 年 8 月 4 日
没有性能问题的情况下,也就是不会导致 io 阻塞的情况都可以用 select * ,至于说啥迭代,数据库和 entity 的关系处理好了,只需要改 entity 和数据库,不用 orm 也可以
1069401249
2020 年 8 月 4 日
谁用 select *我直接打死,占 io 内存,大列表的时候 select*有几次导致内存爆掉了
akira
2020 年 8 月 4 日
小项目随便你怎么写都行。 稍微有点量的项目 还是别用 select *了,回头逐个地方修改还是挺麻烦的
realpg
2020 年 8 月 4 日
结合实际,没有一杆子打死。
性能,吞吐,负载综合考虑。
CEBBCAT
2020 年 8 月 4 日
谢邀,Golang 选手,SQL 手写
DelayNoMay
2020 年 8 月 4 日
用 * 的话,数据库新增一个字段就报 scan error 了
blockmin
2020 年 8 月 4 日
测试的时候数据都是几亿条,用 select * 的话下游团队会砍死我们的
crclz
2020 年 8 月 4 日
事务类的操作,用 ORM,例如 SpringDataJpa 的 repository
查询类的操作,用 select*,外加 ModelMapper ( java )或者 AutoMapper ( c#)之类的工具.

对于大字段,请将表拆分。
woshipanghu
2020 年 8 月 4 日
说实话 你写的严谨一点那是不用*
实际开发的时候用*没什么问题 不要有敏感字段暴露出去就行
大部分项目不会因为加了*或没加*产生太大的影响
读写多的几张表自然会想着去优化

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/695458

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX