V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
itechnology
V2EX  ›  数据库

2025 年了, select *是否仍然禁止使用?

  •  
  •   itechnology · 2 天前 via Android · 8407 次点击

    以前说到 SQL ,几乎都认为不应该使用 select *

    理由无非是覆盖索引、占用网络带宽、性能问题……

    随着时代的发展,我感觉这个没有绝对,其实很多情况使用 select * 完全没问题,很多时候 select * 和 select 字段带来的性能差距还不如做其他优化来的实在

    除非是少数情况,比如 blob 、text 等大字段或者一张表有 100 多个字段……

    我见过有人吐槽新入职的同事把 select * 当圣经,一张配置表,总共就 100 多条数据,所以就用了 select * ,然后这个新同事指出不应该这么用,理由是会影响性能……

    68 条回复    2025-11-04 19:09:09 +08:00
    ipwx
        1
    ipwx  
       2 天前
    一般不都走框架么,哪需要手写 SELECT *
    liuhuan475
        2
    liuhuan475  
       2 天前
    还真有 text 导致 cpu 和带宽打满的情况
    CyouYamato
        3
    CyouYamato  
       2 天前   ❤️ 10
    不要靠感觉,写后端谁给你靠感觉.靠数据说话.
    chambered
        4
    chambered  
       2 天前
    如果数据量和并发小的话,*确实没什么问题。不过建议想要什么,就投影什么字段。毕竟投影越多,执行器里的各个算子要处理的数据就会多,内存和 cpu 就会受到影响
    NoobPhper
        5
    NoobPhper  
       2 天前   ❤️ 2
    有些不是数据大小问题是原则性问题, 人是健忘的, 不是说表大小就能代表可以写 *, 有些公司 程序员并不能真正接触到 线上环境数据库, 他们不知道这个体量有多大
    jefferyJQ
        6
    jefferyJQ  
       2 天前
    遇到再改
    kristofer
        7
    kristofer  
       2 天前
    通常来说都不建议 select *。
    lvlongxiang199
        8
    lvlongxiang199  
       2 天前   ❤️ 6
    还有就是兼容性上的考虑, 如果新版本新增个字段, 用滚动升级更新, 旧版本 select * 就会多出这个字段, 导致报错

    再说你能保证这个表不会新增 blob 字段 ? 如果新增的话, 不还是得手动改 select * ? 不如一上来就 select 指定字段, 这个成本也不高
    kingofzihua
        9
    kingofzihua  
       2 天前
    用 ORM ,如果用 ORM 还 selcet($filed) 那 Model 传递上下文会有问题,字段是空的排查异常恶心,所以不关心是否 select * ,如果 select * 有问题,那就是表没设计好,没分表,
    roundgis
        10
    roundgis  
       2 天前 via Android   ❤️ 1
    萬一你這個*包含了一個不需要的 blob 又恰好很大呢

    這種事很難一概而論
    hefish
        11
    hefish  
       2 天前
    不要纠结这种小问题。
    wu67
        12
    wu67  
       2 天前
    这不是看场景的吗?

    有时候几十个列可能真的有性能问题.

    但是之前真的有过特么需要在一个页面上 select 几十个列出来(客户就要看这么多, 不记得是 40+还是 50+了, 哪怕横向滚滚滚), 而且每个字段都是小整型或者不长的字符(数据源那边入库就这么长),那还不如直接*了好吧
    Gilfoyle26
        13
    Gilfoyle26  
       2 天前
    前端:你们说的都是些啥
    icanfork
        14
    icanfork  
       2 天前
    ORM ,不手写 SQL 了
    lbunderway
        15
    lbunderway  
       2 天前
    这样内存也会很高的
    Wh1te
        16
    Wh1te  
       2 天前
    @ipwx 框架底层是怎么实现的,是 select * 还是
    Wh1te
        17
    Wh1te  
       2 天前
    @icanfork OP 的问题不是手写不手写,是能不能 select 所有字段,用 ORM ,底层也是生成一个 sql 去执行,这个 sql 是 select * 还是只 select 必要字段
    wangritian
        18
    wangritian  
       2 天前
    配置表你就*去吧,应该根据环境做决策
    pulutom40
        19
    pulutom40  
       2 天前 via iPhone
    orm ,不手写 sql ,但是 orm 框架默认都是*,所以我们绝大部分 sql 都是*

    什么时候 dba 找过来了再去优化,目前没找过来
    javalaw2010
        20
    javalaw2010  
       2 天前
    除非有大的文本字段,并且一次查询的条目很多,我才有可能手写 select 字段,不然就直接 select *,费那劲。
    isnullstring
        21
    isnullstring  
       2 天前
    除非表里有大字段 blob,否则全字段

    如果后续逻辑上只用到 10 个字段以内,那还是只查用到的

    代码写得再好,如果没赶在公司倒闭之前交付实施,写啥都没用,哈哈哈哈哈哈哈
    labubu
        22
    labubu  
       2 天前
    能用就行,不能用改(滑稽)
    members
        23
    members  
       2 天前
    是的,大多数项目的性能还没有极致到这个份儿上。

    见过很多人一边追求 select ,一边写着 N+1 浪费性能。
    或者后端在意性能,前端直接 per_page=99999 。
    甚至还有不用 ORM 用手写,理由是掌控 SQL 。却不去想增加了维护难度和开发恶心程度。
    loginv2
        24
    loginv2  
       2 天前   ❤️ 1
    直接* 不做过早优化
    jackleo120
        25
    jackleo120  
       2 天前
    前期 select * 得了,你要是大厂的话,那肯定有 dba 审核的了。。中等团队谁管你,能跑就行了。。。现在就做到优化了后面还怎么优化操作 hhhh
    suibianwanwan
        26
    suibianwanwan  
       2 天前
    @lvlongxiang199 这才是正解, 说到点了
    reavid
        27
    reavid  
       2 天前
    用什么字段从数据库查什么字段。
    cwliang
        28
    cwliang  
       2 天前
    见过 findAll 把所有数据丢给前端了,这里面还有敏感数据,相当炸裂
    ipwx
        29
    ipwx  
       2 天前
    @Wh1te orm 不一般都自动 select fields... 么
    loloX
        30
    loloX  
       2 天前
    大多数时间都是直接用 ORM ,极少数情况会手搓 SQL 。不用 select *应该算是养成好习惯吧,毕竟数据不是一成不变的。
    yvyvyv
        31
    yvyvyv  
       2 天前
    用 ORM,看过两个 ORM 生成的 sql 都是具体字段的,并且每个字段 as 生成实体字段同名的别名。
    SethShi
        32
    SethShi  
       2 天前   ❤️ 1
    楼上说的 ORM 也是全部字段的和 SELECT * 差别不大, 至少现在我还没见过哪家 ORM 可以自动的. 都是根据模型的字段去 SELECT, 但是 class 又是通过表反向生成, 除非每个查询都有独立的模型去映射.
    iyaozhen
        33
    iyaozhen  
       2 天前
    @ipwx #29 ORM 把所有字段列出来,那不是和 select * 一样嘛。
    Wh1te
        34
    Wh1te  
       2 天前
    @ipwx #29 select fields... ≈ select *
    montaro2017
        35
    montaro2017  
       2 天前
    select field 能直观看出表结构,select * 要自己去查表结构,也存在大字段的问题
    Felldeadbird
        36
    Felldeadbird  
       2 天前
    看场景,看团队规范。

    看看我司,170 个字段。一样用 select * 。 性能问题?遇到再说吧。
    AllenZ0
        37
    AllenZ0  
       2 天前
    老胡,在村上经常逆行开车,没出过事故,便认为是自己车机了得。有天他上了高速,走错了路,第一时间也是直接掉头就走!
    ice2016
        38
    ice2016  
       2 天前
    管理不规范。
    LoNeZ
        39
    LoNeZ  
       2 天前
    显式声明了下字段顺序...
    sead
        40
    sead  
       2 天前
    @members 看场景吧,数据量大的时候,原生 SQL 完爆 ORM ;就像 clickhouse 你根本找不到 ORM
    kfpenn
        41
    kfpenn  
       2 天前
    select fields 用 orm 还好说,如果是手写的,那增加一个字段,所有用到这个表的 sql 都要去看要不要改,那才是灾难
    displayabc
        42
    displayabc  
       2 天前
    我用 select 所有字段 ,各位怎么应对?用 mybatis 的,大部分是这么写的吧
    nbndco
        43
    nbndco  
       2 天前 via iPhone
    最大的问题是现在可能没问题,将来万一加了什么很大的字段现在已有的地方会记得要修改么
    guanhui07
        44
    guanhui07  
       2 天前
    内存,覆盖索引,网络 io,通常用* 时为了快捷
    wangtian2020
        45
    wangtian2020  
       2 天前
    我都上 sqlite 了我还在意性能,这种事心里有数程序能跑就行。再说,公司里根本没人管我,我就用/就用/就用
    egfegdfr
        46
    egfegdfr  
       2 天前
    我觉得现在讨论 select* 和 select 属性和当年讨论 是用时间戳还是 年月日时分秒这种可读性高,但是性能差些的格式来记录时间一样
    tanszhe
        47
    tanszhe  
       2 天前
    1. 如果是行数据库大部分 sql 都需要指定字段,那说明表设计的本身就有问题。

    2. 如果是列数据库大部分 sql 不指定字段,那 sql 肯定有问题。
    cocong
        48
    cocong  
       2 天前
    拿 3000 块工资,替老板操碎了心,能跑就行了,有问题再优化呗,反正业务也是改来改去,不差这点。
    body007
        49
    body007  
       2 天前
    @Wh1te #16 一般都是执行 SHOW FULL COLUMNS FROM `table` 将表的列信息缓存到内存,查询所有列的时候直接用全部列信息就行。
    Alucns
        50
    Alucns  
       2 天前
    要使用场景是否使用 SELECT * 数量小且表内容不会过大增长的可以放宽要求,查询频率高的表建议还是要严格要求进行,要什么内容取什么内容。
    MIUIOS
        51
    MIUIOS  
       2 天前
    现在都 ORM 都自动拼了,不用瞎操心这个了
    hervey0424
        52
    hervey0424  
       2 天前
    select * 省事, select 字段省资源, 我选择省事
    wulinn
        53
    wulinn  
       2 天前
    很久都没有手写过 select 了,麻烦。习惯用 Linq 了。
    dongzhuo777
        54
    dongzhuo777  
       2 天前
    不分场景都是扯淡。有些配置表列表用 select * 动添不很正常。
    改的时候代码都不用改 执行一下补丁就行了。高频业务表这样玩就找死
    emric
        55
    emric  
       2 天前
    gql 前端自己拿
    la2la
        56
    la2la  
       2 天前
    代码是写给人看的
    select * 后面维护的人想骂娘
    ipwx
        57
    ipwx  
       2 天前
    @Wh1te 不一样的。

    举个例子,线上是微服务,新版增加了接口,需要更新数据库 Schema 、添加 Column 。

    如果运维不靠谱,不小心把测试分支推上线,至少写全了 fields 的新版会报错,而不是给客户扔一个错误的空字段。
    windyboy
        58
    windyboy  
       2 天前
    正常一定要手写的场合,没用人会用 “*”
    Yesr00
        59
    Yesr00  
       2 天前
    一般不都是需要什么字段返什么字段么。。。每次看到全字段暴露的我都挺无奈的。。。
    xuanbg
        60
    xuanbg  
       2 天前
    @icanfork ORM 也是一样的,你 select 写上表里的所有字段,和 select *是一样一样的。
    Whiplash55
        61
    Whiplash55  
       1 天前
    扯个方向,像 sql devlpoer ,idea database 这些 UI 界面,select*选出来都是分页或者行数显示的,那用他们做 select*应该也没问题吧
    jkc626
        62
    jkc626  
       1 天前
    至少在金融领域是不允许用 select *的
    zzmissu
        63
    zzmissu  
       1 天前
    好的再说一遍 我的 sql 怎么写是我的事情 我只负责查询结果给需求部门 卡顿优化啥的 去找 DBA 啊
    gongquanlin
        64
    gongquanlin  
       1 天前
    谁 tm 在数据库里存 blob 呀 但是如果有 text 确实会慢很多
    Rat3
        65
    Rat3  
       1 天前
    @sead 我就用 clickhouse ,也用的 orm 啊...
    lyxxxh2
        66
    lyxxxh2  
       1 天前
    DB::select(
    $orm->toSql(),$orm->getBindings()
    );
    再加条规则: 还禁止用 orm 直接执行,必须转原生 sql 再执行(狗头保命)
    十几条和几万条数据,谁不会做取舍。
    一棍子打死,看文章看傻了吧。
    Huelse
        67
    Huelse  
       1 天前
    为什么人会重蹈覆辙,就是因为后人会怀疑前人的经验教训,想尝试违反规则
    dif
        68
    dif  
       1 天前
    我个人还是不建议,源于一个天才同事把字段名写错,后续发现了又改了字段名。
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2993 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 252ms · UTC 13:31 · PVG 21:31 · LAX 05:31 · JFK 08:31
    ♥ Do have faith in what you're doing.