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

Mybatis 到底好在哪?国内大厂也在用?

  •  
  •   ouxch · 2020-12-16 15:23:53 +08:00 · 5223 次点击
    这是一个创建于 719 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我司新项目小伙伴们用的 Mybatis,我之前没用过这个,初看他们写的代码和生成的sql,总觉得这玩意儿这么用有些不妥,特来请教下是他们用的方式有问题还是这玩意儿有什么别的黑魔法?

    1. 我看到很多用 mapper 生成的语句都是select *,这严重违反常见规约也严重影响性能吧?
    2. 自定义的mapper xml给我的直观感受还不如格式化后的SQL易读,而且编码效率也不会更高吧?
    46 条回复    2020-12-18 16:21:21 +08:00
    shinelogo
        1
    shinelogo  
       2020-12-16 15:29:37 +08:00 via iPhone
    参照物是?
    manami
        2
    manami  
       2020-12-16 15:33:25 +08:00
    如果找个对比的话,个人觉得 MyBatis 没有 Spring Data JPA 好用。MyBatis 可以不用 xml 的,个人习惯使用 mybatis 注解的方式写 SQL,感觉也不错
    brezp
        3
    brezp  
       2020-12-16 15:36:17 +08:00
    比较方便撸业务 , 业务不复杂(多表,多动态等等)看不出 mybatis 的优势,那你司之前不用 mybatis 都是用的什么呢? JDBC , JPA?
    brezp
        4
    brezp  
       2020-12-16 15:37:09 +08:00
    @manami JPA 撸动态 sql 感觉没有 mybatis 好用
    StopTheWorld
        5
    StopTheWorld  
       2020-12-16 15:38:13 +08:00
    [我看到很多用 mapper 生成的语句都是 select *] ,这是你小伙伴的问题,不是 mybatis 的问题。
    xiangyuecn
        6
    xiangyuecn  
       2020-12-16 15:43:05 +08:00
    所以导致了 一堆蹩脚的 plus plus plus 存在(不用写 xml 居然能成为最大卖点😂)
    SuperXRay
        7
    SuperXRay  
       2020-12-16 15:44:33 +08:00
    select * 和 select 所有字段性能相差无几,说严重影响性能有看过性能对比么
    当然我们有时候只需要部分字段,那可以不 select *,这和用不用 Mybatis 没什么关系

    Jpa 一开始觉得简单,多表之后简直要命,还是 Mybatis 方便
    ouxch
        8
    ouxch  
    OP
       2020-12-16 15:48:28 +08:00
    @shinelogo 哈哈 O(∩_∩)O,是我没说清楚。
    我并不是拿它跟其他 ORM 对比,当然严格说它也算不上 ORM,就是个 SQL 模板引擎吧。
    所以就简单的跟手写 SQL+自己封装 DBUtils 来比吧。
    既然这么多人用,应该是解决了某个痛点吧,但以我目前粗浅的认识来看,没有解决多大痛点不说还带来一系列新的问题。

    其实主要就是我说的那两个问题,当然还有一些别的问题比如:
    3. 编写 xml 既费时易读性又差,代码不像代码、配置不像配置,这种东西到底比 Java 拼接字符串高明在哪里?
    4. 还有调试也是一个问题,不运行就不知道最终生成的 SQL 是什么样的。
    ouxch
        9
    ouxch  
    OP
       2020-12-16 15:50:50 +08:00
    @xiangyuecn 所以这并不是一个开箱即用的好方案,还得自己折腾是吧😄
    shinelogo
        10
    shinelogo  
       2020-12-16 15:55:49 +08:00 via iPhone
    @ouxch 我多年没撸代码了,但是 mybatis 对比 hibernate 我还是更喜欢前者,这些框架的优势是弱化数据库之间的差异化,提高兼容性,未后期切换数据库减轻工作量,还有就是我记得 mybatis 有个框架可以根据你的数据库生成很多 增删改的通用语句(规则可以自定义),所以我认为这东西的存在意义是快速开发,把一些无趣的编码工作省略掉
    opengps
        11
    opengps  
       2020-12-16 15:56:57 +08:00
    不要只看重技术性能,写原生 sql 当然省事高性能,在看看团队配合方面的优势,性能其实并不是重点了
    Jooooooooo
        12
    Jooooooooo  
       2020-12-16 15:56:59 +08:00
    所以用别的就不会有 select * 的问题?
    ouxch
        13
    ouxch  
    OP
       2020-12-16 15:58:26 +08:00
    @SuperXRay
    [select * 和 select 所有字段性能相差无几,说严重影响性能有看过性能对比么]
    我当然不是这个意思啊,为什么会有这种理解😄,`select * `和`select 所有字段`能有什么区别。

    读取不需要的列除了会影响执行计划是否走索引,还会增加 CPU 、IO 、NET 消耗。当然这都是另外的问题了。

    我的疑问是查询部分字段的话,mybatis 的实现方式是自定义 mapper xml,这种反人类的设计无论从工作量还是易读性,好像都比不上手写 sql 。
    Hurriance
        14
    Hurriance  
       2020-12-16 15:59:50 +08:00
    @ouxch xml 的确是易读性差了点,只是相对于 jpa 来讲,多表下 mybatis 的确更好写点,也可以搭配 mybatis-plus 来用,单表查询基本都可以不用写 xml
    ouxch
        15
    ouxch  
    OP
       2020-12-16 16:00:02 +08:00
    @Jooooooooo 求不抬杠😄。看下我 13 楼的回复🙏
    Jooooooooo
        16
    Jooooooooo  
       2020-12-16 16:01:12 +08:00
    @ouxch 没看出 xml 可读性差在哪, 贴个代码对比一下?
    Hurriance
        17
    Hurriance  
       2020-12-16 16:02:16 +08:00
    @Jooooooooo xml 可读性不差 spring 就不会推 yaml 了
    ouxch
        18
    ouxch  
    OP
       2020-12-16 16:02:44 +08:00
    @StopTheWorld 那`mybatis`除了写反人类的 xml,请教下还有其他优雅的方式来实现只查询部分字段吗。回头我去嘲讽他们哈哈😄
    slyang5
        19
    slyang5  
       2020-12-16 16:04:51 +08:00
    月经帖 ?
    securityCoding
        20
    securityCoding  
       2020-12-16 16:08:23 +08:00
    @SuperXRay
    select * 和 select 所有字段性能相差无几

    查全部字段是性能一样的,都要回表 .如果恰好是查索引字段性能差距还有点的 ,不需要回表直接使用覆盖索引或者索引下推机制了 ,大表高并发时会比较明显
    ouxch
        21
    ouxch  
    OP
       2020-12-16 16:08:50 +08:00
    @slyang5 哈哈,特意去百度了下什么是月经帖 。我很少提问,确实之前也没看到这个主题的讨论,提个问就是想讨论求教一下。不好意思了🙏
    Jooooooooo
        22
    Jooooooooo  
       2020-12-16 16:11:55 +08:00
    @Hurriance 复杂 sql 的可读性差不是 xml 造成的吧

    简单 sql 在 xml 下我看很清晰
    sagaxu
        23
    sagaxu  
       2020-12-16 16:14:01 +08:00 via Android
    @ouxch 有一种痛点,叫别人觉得你痛。mybatis 还没手拼 sql 方便,代码约束好 sql 在什么文件拼,编程语言的表达能力比 XML 强的多。
    Oktfolio
        24
    Oktfolio  
       2020-12-16 16:21:02 +08:00
    不要问我这是在做什么,有没有必要这样做,不是我干的,这里面还有动态查询。
    https://sm.ms/image/JEPm2uXckIF9UhK
    zjsxwc
        25
    zjsxwc  
       2020-12-16 16:24:00 +08:00
    都是为了拼 sql:
    - Mybatis 用 xml 模板代码里面拼 sql,非常直观一目了然,一定程度上具有一定灵活性方便复用
    - Jpa 用 Builder 模式 java 代码面向对象方式拼 sql,一定程度上直观一目了然,非常具有灵活性方便复用


    类比 Vue 与 React

    都是为了拼 html
    - Vue 用私有的 vue 模板代码里面拼 html,非常直观一目了然,一定程度上具有一定灵活性方便复用
    - React 用 Builder 模式 javascript 代码面向对象方式拼 html,一定程度上直观一目了然,非常具有灵活性方便复用

    比如 React 可以非常简单地做可见就可得的拖拽组件的方式生成运营活动页,而 Vue 很难,因为 vue 模板代码已经写死,不能在运行代码的时候动态修改 vue 模板代码,这类不够灵活复用的问题对于 Mybatis 也一样,xml 模板代码写死后也不能运行时动态修改,当然对于大部分后端项目来说没有前端对于灵活性要求大,甚至大部分前端项目也不需要 React 的灵活性。
    liudaolunhuibl
        26
    liudaolunhuibl  
       2020-12-16 16:24:48 +08:00
    统计相关的需要复杂 sql 的用 mybaties,简单的 CRUD 的就用 jpa
    hantsy
        27
    hantsy  
       2020-12-16 16:24:55 +08:00
    mybatis 不如用 Spring JdbcTemplate 方便,如果我真的需要写 SQL 的话。
    coderwl
        28
    coderwl  
       2020-12-16 16:26:16 +08:00
    mybatis 在我看来要配和 mybatisHelper 等插件使用,在 xml 中写 SQL 的体验是拼接字符串不能比的,自动提示,字段纠错这些拼接功能都是必备的。如果没有插件,那还不如拼接 SQL
    hantsy
        29
    hantsy  
       2020-12-16 16:31:11 +08:00
    日经帖子,Hide
    sagaxu
        30
    sagaxu  
       2020-12-16 16:31:33 +08:00 via Android
    @coderwl 字段提示,语法检查,idea 里手拼 sql 都有哦
    yalin
        31
    yalin  
       2020-12-16 16:35:36 +08:00
    菜刀而已
    jitongxi
        32
    jitongxi  
       2020-12-16 16:52:02 +08:00
    mybatis plus,方法注解 sql 模板,爽歪歪。。。

    5 个以上表关联查询, 试试 jpa ?试试就逝世。
    ElmerZhang
        33
    ElmerZhang  
       2020-12-16 16:57:15 +08:00
    我们之前用 Mybatis 是为了直接用 xml 写 SQL,规定所有数据库语句都必须用 xml 来写,这样某个 SQL 出慢查询时方便定位到底是哪里用到的。
    totoro52
        34
    totoro52  
       2020-12-16 17:04:51 +08:00
    不要再去纠结 mybatis 和 jpa 了 不结合业务情况来讨论技术的完全是耍流氓
    coderwl
        35
    coderwl  
       2020-12-16 17:11:47 +08:00
    @sagaxu 稍微复杂点,多几个逻辑判断就提示不出来了
    securityCoding
        36
    securityCoding  
       2020-12-16 17:13:59 +08:00
    @jitongxi jpa 多表条件查询确实难用 ,好在业务中规定只能单表查询 , 5 个表以上得去拜访下数据组大佬了
    Jrue0011
        37
    Jrue0011  
       2020-12-16 17:31:39 +08:00
    Mybatis 适合比如需要动态 SQL 复用( include 、bind )、复杂结果映射( discriminator 、collection )之类的场景。

    至于普通的动态 SQL 倒不算特别大优势,因为其他 ORM 框架也基本能做到。

    之前因为某个需要稍微去了解了下 Camunda 、Activiti 工作流引擎,然后发现他们操作数据库也是用的 Mybatis,就去看了下他们是怎么用的,好家伙那里面各种标签用的飞起。
    SuperXRay
        38
    SuperXRay  
       2020-12-16 18:21:56 +08:00 via iPad
    @ouxch #18
    这个也是有的,
    随便搜一下“mybatis-plus select 部分字段”,不需要写 xml,也不算麻烦
    hangszhang
        39
    hangszhang  
       2020-12-17 00:28:35 +08:00
    日经贴, 天天讨论, 服了
    beginor
        40
    beginor  
       2020-12-17 08:30:28 +08:00 via Android
    .Net 平台上基于 linq 的 ORM 兴起之后, 像 mybatis 这种半自动的就没落了, 当年 iBATIS.Net 也是能扛起半边天的。

    Java 平台却一直没有出现好用的 linq 的 ORM 框架, 到底是什么原因呢? 期待 Java 平台上的基于 linq 的 ORM 框架, 看到时候还有谁说 mybatis 香!
    fpure
        41
    fpure  
       2020-12-17 08:40:02 +08:00 via Android
    表达能力。
    我知道许多人喜欢 jpa 的类型安全,但是遇到复杂的查询用 jpa 写不出来的时候你就得抓狂
    liuhuan475
        42
    liuhuan475  
       2020-12-17 09:47:36 +08:00
    @beginor jpa ? mp?
    cco
        43
    cco  
       2020-12-17 09:53:41 +08:00
    @SuperXRay 确实看到过这种文章,应该是 mysql 升级后做的一些优化,包括 in 之类的操作。
    不过我个人没有去用大量的数据去验证,只不过目前看确实没啥影响。
    jiao
        44
    jiao  
       2020-12-17 13:40:00 +08:00
    项目里但凡有一两个复杂 sql 的需求,jpa 就得去各种查文档,代码、sql 语句外加创建视图结合来实现功能。费很大劲实现的需求,对 mp 来说可能真就是一个 select 标签的事。


    我不能说 mp 就比 jpa 强大,但有些反人类的 sql 出来了,用 mp 就有种无论什么 sql 我都不怕,不管你是几张表 join 、union 、group,对我来说就一个 select 标签。(也有可能是我 jpa 功夫不到位)
    liyhu
        45
    liyhu  
       2020-12-17 20:25:17 +08:00
    日经贴, 爱用不用
    hyqCrystal
        46
    hyqCrystal  
       2020-12-18 16:21:21 +08:00
    我想了解 楼主 之前用什么
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2810 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 45ms · UTC 00:48 · PVG 08:48 · LAX 16:48 · JFK 19:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.