1

一般不都走框架么，哪需要手写 SELECT *

2

还真有 text 导致 cpu 和带宽打满的情况

3

10

不要靠感觉,写后端谁给你靠感觉.靠数据说话.

4

如果数据量和并发小的话，*确实没什么问题。不过建议想要什么，就投影什么字段。毕竟投影越多，执行器里的各个算子要处理的数据就会多，内存和 cpu 就会受到影响

5

2

有些不是数据大小问题是原则性问题, 人是健忘的, 不是说表大小就能代表可以写 *, 有些公司 程序员并不能真正接触到 线上环境数据库, 他们不知道这个体量有多大

7

通常来说都不建议 select *。

8

6

9

用 ORM ，如果用 ORM 还 selcet($filed) 那 Model 传递上下文会有问题，字段是空的排查异常恶心，所以不关心是否 select * ，如果 select * 有问题，那就是表没设计好，没分表，

10

1

11

不要纠结这种小问题。

12

14

ORM ，不手写 SQL 了

16

@ipwx 框架底层是怎么实现的，是 select * 还是

17

@icanfork OP 的问题不是手写不手写，是能不能 select 所有字段，用 ORM ，底层也是生成一个 sql 去执行，这个 sql 是 select * 还是只 select 必要字段

18

配置表你就*去吧，应该根据环境做决策

19

20

除非有大的文本字段，并且一次查询的条目很多，我才有可能手写 select 字段，不然就直接 select *，费那劲。

21

22

能用就行，不能用改（滑稽）

23

24

1

直接* 不做过早优化

25

前期 select * 得了，你要是大厂的话，那肯定有 dba 审核的了。。中等团队谁管你，能跑就行了。。。现在就做到优化了后面还怎么优化操作 hhhh

27

用什么字段从数据库查什么字段。

28

见过 findAll 把所有数据丢给前端了，这里面还有敏感数据，相当炸裂

29

@Wh1te orm 不一般都自动 select fields... 么

30

大多数时间都是直接用 ORM ，极少数情况会手搓 SQL 。不用 select *应该算是养成好习惯吧，毕竟数据不是一成不变的。

31

用 ORM,看过两个 ORM 生成的 sql 都是具体字段的，并且每个字段 as 生成实体字段同名的别名。

32

1

楼上说的 ORM 也是全部字段的和 SELECT * 差别不大, 至少现在我还没见过哪家 ORM 可以自动的. 都是根据模型的字段去 SELECT, 但是 class 又是通过表反向生成, 除非每个查询都有独立的模型去映射.

33

@ipwx #29 ORM 把所有字段列出来，那不是和 select * 一样嘛。

34

@ipwx #29 select fields... ≈ select *

35

select field 能直观看出表结构，select * 要自己去查表结构，也存在大字段的问题

36

37

老胡，在村上经常逆行开车，没出过事故，便认为是自己车机了得。有天他上了高速，走错了路，第一时间也是直接掉头就走！

38

管理不规范。

39

显式声明了下字段顺序...

40

@members 看场景吧，数据量大的时候，原生 SQL 完爆 ORM ；就像 clickhouse 你根本找不到 ORM

41

select fields 用 orm 还好说，如果是手写的，那增加一个字段，所有用到这个表的 sql 都要去看要不要改，那才是灾难

42

我用 select 所有字段 ,各位怎么应对？用 mybatis 的，大部分是这么写的吧

43

最大的问题是现在可能没问题，将来万一加了什么很大的字段现在已有的地方会记得要修改么

44

内存,覆盖索引,网络 io,通常用* 时为了快捷

45

我都上 sqlite 了我还在意性能，这种事心里有数程序能跑就行。再说，公司里根本没人管我，我就用/就用/就用

46

我觉得现在讨论 select* 和 select 属性和当年讨论 是用时间戳还是 年月日时分秒这种可读性高，但是性能差些的格式来记录时间一样

47

48

拿 3000 块工资，替老板操碎了心，能跑就行了，有问题再优化呗，反正业务也是改来改去，不差这点。

49

@Wh1te #16 一般都是执行 SHOW FULL COLUMNS FROM `table` 将表的列信息缓存到内存，查询所有列的时候直接用全部列信息就行。

50

要使用场景是否使用 SELECT * 数量小且表内容不会过大增长的可以放宽要求，查询频率高的表建议还是要严格要求进行，要什么内容取什么内容。

51

现在都 ORM 都自动拼了，不用瞎操心这个了

52

select * 省事, select 字段省资源, 我选择省事

53

很久都没有手写过 select 了，麻烦。习惯用 Linq 了。

54

不分场景都是扯淡。有些配置表列表用 select * 动添不很正常。
改的时候代码都不用改 执行一下补丁就行了。高频业务表这样玩就找死

55

gql 前端自己拿

56

代码是写给人看的
select * 后面维护的人想骂娘

57

58

正常一定要手写的场合，没用人会用 “*”

59

一般不都是需要什么字段返什么字段么。。。每次看到全字段暴露的我都挺无奈的。。。

60

@icanfork ORM 也是一样的，你 select 写上表里的所有字段，和 select *是一样一样的。

61

扯个方向，像 sql devlpoer ，idea database 这些 UI 界面，select*选出来都是分页或者行数显示的，那用他们做 select*应该也没问题吧

62

至少在金融领域是不允许用 select *的

63

好的再说一遍 我的 sql 怎么写是我的事情 我只负责查询结果给需求部门 卡顿优化啥的 去找 DBA 啊

64

谁 tm 在数据库里存 blob 呀 但是如果有 text 确实会慢很多

65

@sead 我就用 clickhouse ，也用的 orm 啊...

66

DB::select(
$orm->toSql(),$orm->getBindings()
);
再加条规则: 还禁止用 orm 直接执行,必须转原生 sql 再执行（狗头保命）
十几条和几万条数据,谁不会做取舍。
一棍子打死,看文章看傻了吧。

67

为什么人会重蹈覆辙，就是因为后人会怀疑前人的经验教训，想尝试违反规则

68

我个人还是不建议，源于一个天才同事把字段名写错，后续发现了又改了字段名。

69

@Rat3 官方有篇帖子专门是说“为什么它不合适用 ORM”，你用的哪个轮子，我找了很多遍根本没有一个完美支持的。

70