以前说到 SQL ，几乎都认为不应该使用 select *
理由无非是覆盖索引、占用网络带宽、性能问题……
随着时代的发展，我感觉这个没有绝对，其实很多情况使用 select * 完全没问题，很多时候 select * 和 select 字段带来的性能差距还不如做其他优化来的实在
除非是少数情况，比如 blob 、text 等大字段或者一张表有 100 多个字段……
我见过有人吐槽新入职的同事把 select * 当圣经，一张配置表，总共就 100 多条数据，所以就用了 select * ，然后这个新同事指出不应该这么用，理由是会影响性能……
 |
ipwxNov 3, 2025
1
一般不都走框架么，哪需要手写 SELECT *
|
 |
liuhuan475Nov 3, 2025
2
还真有 text 导致 cpu 和带宽打满的情况
|
 |
3
不要靠感觉,写后端谁给你靠感觉.靠数据说话.
|
 |
chamberedNov 3, 2025
4
如果数据量和并发小的话，*确实没什么问题。不过建议想要什么，就投影什么字段。毕竟投影越多，执行器里的各个算子要处理的数据就会多，内存和 cpu 就会受到影响
|
 |
5
有些不是数据大小问题是原则性问题, 人是健忘的, 不是说表大小就能代表可以写 *, 有些公司 程序员并不能真正接触到 线上环境数据库, 他们不知道这个体量有多大
|
 |
jefferyJQNov 3, 2025
6
遇到再改
|
 |
kristoferNov 3, 2025
7
通常来说都不建议 select *。
|
 |
8
还有就是兼容性上的考虑, 如果新版本新增个字段, 用滚动升级更新, 旧版本 select * 就会多出这个字段, 导致报错
再说你能保证这个表不会新增 blob 字段 ? 如果新增的话, 不还是得手动改 select * ? 不如一上来就 select 指定字段, 这个成本也不高 |
 |
kingofzihuaNov 3, 2025
9
用 ORM ，如果用 ORM 还 selcet($filed) 那 Model 传递上下文会有问题，字段是空的排查异常恶心，所以不关心是否 select * ，如果 select * 有问题，那就是表没设计好，没分表，
|
 |
10
萬一你這個*包含了一個不需要的 blob 又恰好很大呢
這種事很難一概而論 |
 |
hefishNov 3, 2025
11
不要纠结这种小问题。
|
 |
wu67Nov 3, 2025
12
这不是看场景的吗?
有时候几十个列可能真的有性能问题. 但是之前真的有过特么需要在一个页面上 select 几十个列出来(客户就要看这么多, 不记得是 40+还是 50+了, 哪怕横向滚滚滚), 而且每个字段都是小整型或者不长的字符(数据源那边入库就这么长),那还不如直接*了好吧 |
 |
Gilfoyle26Nov 3, 2025
13
前端：你们说的都是些啥
 |
 |
icanforkNov 3, 2025
14
ORM ，不手写 SQL 了
|
 |
lbunderwayNov 3, 2025
15
这样内存也会很高的
|
 |
Wh1teNov 3, 2025
17
@icanfork OP 的问题不是手写不手写，是能不能 select 所有字段，用 ORM ，底层也是生成一个 sql 去执行，这个 sql 是 select * 还是只 select 必要字段
|
 |
WaldenHorizonNov 3, 2025
18
配置表你就*去吧，应该根据环境做决策
|
 |
pulutom40Nov 3, 2025 via iPhone
19
orm ，不手写 sql ，但是 orm 框架默认都是*，所以我们绝大部分 sql 都是*
什么时候 dba 找过来了再去优化，目前没找过来 |
 |
javalaw2010Nov 3, 2025
20
除非有大的文本字段，并且一次查询的条目很多，我才有可能手写 select 字段，不然就直接 select *，费那劲。
|
 |
isnullstringNov 3, 2025
21
除非表里有大字段 blob,否则全字段
如果后续逻辑上只用到 10 个字段以内，那还是只查用到的 代码写得再好，如果没赶在公司倒闭之前交付实施，写啥都没用，哈哈哈哈哈哈哈 |
 |
labubuNov 3, 2025
22
能用就行，不能用改（滑稽）
|
 |
membersNov 3, 2025
23
是的，大多数项目的性能还没有极致到这个份儿上。
见过很多人一边追求 select ，一边写着 N+1 浪费性能。 或者后端在意性能，前端直接 per_page=99999 。 甚至还有不用 ORM 用手写，理由是掌控 SQL 。却不去想增加了维护难度和开发恶心程度。 |
 |
24
直接* 不做过早优化
|
 |
jackleo120Nov 3, 2025
25
前期 select * 得了，你要是大厂的话，那肯定有 dba 审核的了。。中等团队谁管你，能跑就行了。。。现在就做到优化了后面还怎么优化操作 hhhh
|
 |
suibianwanwanNov 3, 2025
26
@lvlongxiang199 这才是正解, 说到点了
|
 |
reavidNov 3, 2025
27
用什么字段从数据库查什么字段。
|
 |
cwliangNov 3, 2025
28
见过 findAll 把所有数据丢给前端了，这里面还有敏感数据，相当炸裂
|
 |
loloXNov 3, 2025
30
大多数时间都是直接用 ORM ，极少数情况会手搓 SQL 。不用 select *应该算是养成好习惯吧，毕竟数据不是一成不变的。
|
 |
yvyvyvNov 3, 2025
31
用 ORM,看过两个 ORM 生成的 sql 都是具体字段的，并且每个字段 as 生成实体字段同名的别名。
|
 |
32
楼上说的 ORM 也是全部字段的和 SELECT * 差别不大, 至少现在我还没见过哪家 ORM 可以自动的. 都是根据模型的字段去 SELECT, 但是 class 又是通过表反向生成, 除非每个查询都有独立的模型去映射.
|
 |
montaro2017Nov 3, 2025
35
select field 能直观看出表结构，select * 要自己去查表结构，也存在大字段的问题
|
 |
FelldeadbirdNov 3, 2025
36
看场景，看团队规范。
看看我司，170 个字段。一样用 select * 。 性能问题？遇到再说吧。 |
 |
AllenZ0Nov 3, 2025
37
老胡，在村上经常逆行开车，没出过事故，便认为是自己车机了得。有天他上了高速，走错了路，第一时间也是直接掉头就走！
|
 |
acedbsNov 3, 2025
38
管理不规范。
|
 |
LoNeZNov 3, 2025
39
显式声明了下字段顺序...
|
 |
kfpennNov 3, 2025
41
select fields 用 orm 还好说，如果是手写的，那增加一个字段，所有用到这个表的 sql 都要去看要不要改，那才是灾难
|
 |
displayabcNov 3, 2025
42
我用 select 所有字段 ,各位怎么应对？用 mybatis 的，大部分是这么写的吧
|
 |
nbndcoNov 3, 2025 via iPhone
43
最大的问题是现在可能没问题，将来万一加了什么很大的字段现在已有的地方会记得要修改么
|
 |
guanhui07Nov 3, 2025
44
内存,覆盖索引,网络 io,通常用* 时为了快捷
|
 |
wangtian2020Nov 3, 2025
45
我都上 sqlite 了我还在意性能，这种事心里有数程序能跑就行。再说，公司里根本没人管我，我就用/就用/就用
|
 |
egfegdfrNov 3, 2025
46
我觉得现在讨论 select* 和 select 属性和当年讨论 是用时间戳还是 年月日时分秒这种可读性高，但是性能差些的格式来记录时间一样
|
 |
tanszheNov 3, 2025
47
1. 如果是行数据库大部分 sql 都需要指定字段，那说明表设计的本身就有问题。
2. 如果是列数据库大部分 sql 不指定字段，那 sql 肯定有问题。 |
 |
cocongNov 3, 2025
48
拿 3000 块工资，替老板操碎了心，能跑就行了，有问题再优化呗，反正业务也是改来改去，不差这点。
|
 |
body007Nov 3, 2025
49
@Wh1te #16 一般都是执行 SHOW FULL COLUMNS FROM `table` 将表的列信息缓存到内存，查询所有列的时候直接用全部列信息就行。
|
 |
AlucnsNov 3, 2025
50
要使用场景是否使用 SELECT * 数量小且表内容不会过大增长的可以放宽要求，查询频率高的表建议还是要严格要求进行，要什么内容取什么内容。
|
 |
MIUIOSNov 3, 2025
51
现在都 ORM 都自动拼了，不用瞎操心这个了
|
 |
hervey0424Nov 3, 2025
52
select * 省事, select 字段省资源, 我选择省事
|
 |
wulinnNov 3, 2025
53
很久都没有手写过 select 了，麻烦。习惯用 Linq 了。
|
 |
dongzhuo777Nov 3, 2025
54
不分场景都是扯淡。有些配置表列表用 select * 动添不很正常。
改的时候代码都不用改 执行一下补丁就行了。高频业务表这样玩就找死 |
 |
emricNov 3, 2025
55
gql 前端自己拿
|
 |
la2laNov 3, 2025
56
代码是写给人看的
select * 后面维护的人想骂娘 |
|
ipwxNov 3, 2025
57
@Wh1te 不一样的。
举个例子，线上是微服务，新版增加了接口，需要更新数据库 Schema 、添加 Column 。 如果运维不靠谱，不小心把测试分支推上线，至少写全了 fields 的新版会报错，而不是给客户扔一个错误的空字段。 |
 |
windyboyNov 3, 2025
58
正常一定要手写的场合，没用人会用 “*”
|
 |
Yesr00Nov 3, 2025
59
一般不都是需要什么字段返什么字段么。。。每次看到全字段暴露的我都挺无奈的。。。
|
 |
Whiplash55Nov 3, 2025
61
扯个方向，像 sql devlpoer ，idea database 这些 UI 界面，select*选出来都是分页或者行数显示的，那用他们做 select*应该也没问题吧
|
 |
jkc626Nov 4, 2025
62
至少在金融领域是不允许用 select *的
|
 |
zzmissuNov 4, 2025
63
好的再说一遍 我的 sql 怎么写是我的事情 我只负责查询结果给需求部门 卡顿优化啥的 去找 DBA 啊
|
 |
gongquanlinNov 4, 2025
64
谁 tm 在数据库里存 blob 呀
 但是如果有 text 确实会慢很多 |
 |
lyxxxh2Nov 4, 2025
66
DB::select(
$orm->toSql(),$orm->getBindings() ); 再加条规则: 还禁止用 orm 直接执行,必须转原生 sql 再执行（狗头保命） 十几条和几万条数据,谁不会做取舍。 一棍子打死,看文章看傻了吧。 |
 |
HuelseNov 4, 2025
67
为什么人会重蹈覆辙，就是因为后人会怀疑前人的经验教训，想尝试违反规则
|
 |
difNov 4, 2025
68
我个人还是不建议，源于一个天才同事把字段名写错，后续发现了又改了字段名。
|
10
Select Language