首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
Coding
V2EX  ›  MySQL

刚才,领导对我的 sql 提出了建议

  •  
  •   Breadykid · 104 天前 · 8414 次点击
    这是一个创建于 104 天前的主题,其中的信息可能已经有所发展或是发生改变。

    背景:

    • 应用服务器一台,数据库服务器一台
    • 公司用的 mysql
    • 一个报表查询中,我使用了 DATE(create_date)函数,导致 create_date 的索引没被使用到,造成长时间查询

    领导见状后,如是说:

    • 1.索引字段不使用函数
    • 2.sql 的 group by 优于内存处理的 list.stream.Collectors.groupingby
    • 3.联表查首选于单表查
    • 4.数据量大时,考虑分表

    对于第三点我有疑问。。。不是太认同,想问问大家的看法

    第 1 条附言  ·  104 天前
    再加个背景:
    目前单表 4200w
    41 回复  |  直到 2019-09-04 11:49:25 +08:00
        1
    optional   104 天前   ♥ 1
    看应用类型,对于高并发的互联网应用,2,3 都是 bad idea。
        2
    optional   104 天前   ♥ 1
    嗯 为了避免被喷,加一个 具体情况具体分析。
        3
    knva   104 天前
    sql 压力越小越好
        4
    notshytoday   104 天前 via Android
    你不认同肯定有自己的原因的,说说呗

    赞楼上的具体问题具体分析
        5
    Xbluer   104 天前 via iPhone
    1. oracle 中有所谓的函数索引,即针对列计算出函数的值在生成索引。mysql 好像可以使用虚列曲线救国。
        6
    airfling   104 天前
    我觉得单表查询优先于多表,单挑优先于 group by,groupby 可以不再数据库中做,完全可以自己需要的数据直接取出来,自己在内存中做。除非一次取的数据特别大,但是数据特别大这种情况你就要考虑分表了,建索引等优化措施了,而是不是 sql 优化就能解决的
        7
    LeeSeoung   104 天前   ♥ 2
    1 涉及表字段设计,设计恰当很少出现查询字段需要转换后再查询的情况
    2 是可以认同的,数据量大的情况下 请求大量数据回来,网络 IO 以及对内存都有要求
    3 我看了网上一篇文章中讲到《高性能 mysql 》有提到这个问题,从缓存、锁竞争等方面来说,单表多次查是由于联表查的
    4 完全同意
        8
    scys   104 天前   ♥ 3
    * 听领导的,先按照领导的做一遍;
    * 做完后发现没什么效果,研究下 2,3,看看哪里可以优化。

    感觉这样工作才比较有效。
        9
    a719114136   104 天前
    做个实验就知道了,如果懒得做的话我告诉你,领导说的没错
        10
    reus   104 天前
    你看别的数据库就从来没有什么单表优于多表的说法
    垃圾 mysql。
        11
    xaplux   104 天前
    很明显,不认同领导说的。但是这次你领导说的没什么问题,1 很明显,2 要看具体情况,如果是单表的 groupby 没有问题,3 JOIN 的多张表都比较大时,确实单表查询效率要高,4 没毛病
        12
    binux   104 天前
    3 看情况,如果 filter 字段都在表 1,join 表 2 取其他字段那是没问题的
        13
    Breadykid   104 天前
    @reus 同意,Postgres 就好很多
        14
    luozic   104 天前
    一切看数据量还有数据库服务器配置。
        15
    Breadykid   104 天前
    @knva 为什么领导说非多张大表连表查询的压力对于服务器来说微乎其微
        16
    Breadykid   104 天前
    @luozic
    @binux
    @xaplux
    @a719114136
    @LeeSeoung
    @airfling
    @optional

    为什么领导说非多张大表 联表查询的压力对于数据库来说微乎其微???
        17
    LeeSeoung   104 天前
    不是大表你联查还是单表查都差不多。。个位数相同,小数点后几位你还在乎多少位么。。
        18
    Raymon111111   104 天前
    2. 尽可能把压力放在业务侧. 数据库资源很宝贵. 但是 groupby 涉及返回数据大小的问题, 所以还要具体问题具体分析.

    3. 尽可能不做连表查询. 一个很重要的原因是连表的索引往往踩不对.
        19
    winglight2016   104 天前
    有索引的情况下,多表关联没有增加多少 payload。4000 多万可以开始准备分表了。报表不要用生产库来生成。
        20
    glacer   104 天前   ♥ 1
    从来没有 MySQL 不能多表联查的道理,高性能的 join 查询本身就是关系型数据库的一大优势。在一些规范中限制连表的数量是因为程序员的水平参差不齐容易写出慢查询。
    在索引命中合理的情况下,MySQL 对 Join 的处理性能是完全没有问题的,完爆将多表结果查出在内存中做聚合的做法。
    如果在索引不合理使用的情况下,将多表拆成单表来查,照样和不能命中索引。难道就对数据库的压力就比联表查小了么?
        21
    reus   104 天前 via Android
    @Breadykid mysql 8 是可以的,5 就不行
        22
    cwjokaka   104 天前
    单表查询容易看出有哪些索引被命中
        23
    xuanbg   104 天前
    大多数推崇单表查的程序员,怕是根本不知道索引为何物吧。真懂索引的程序员根本不怕多表 join。
        24
    dog82   104 天前
    第一点不是绝对,oracle 可以建基于函数的索引;
    其它表示认同。
        25
    optional   104 天前
    @Breadykid join 在使用索引的情况下,效率损失不大。
        26
    l00t   104 天前
    @dog82 #24 这有什么不绝对的。基于函数的索引那是另一种索引,索引的是字段被函数处理后的样子,而不是当前的索引字段。
        27
    jk1030   104 天前
    @xuanbg ??? 分表分库怎么处理
        28
    xaplux   104 天前
    @Breadykid 因为如果是大表 JOIN 大表,笛卡尔积很可怕的,如果小表就还好呀
        29
    wysnylc   104 天前
    1.索引字段不使用函数
    2.sql 的 group by 优于内存处理的 list.stream.Collectors.groupingby
    3.联表查首选于单表查
    4.数据量大时,考虑分表

    1 没问题
    2 看情况,比如是需要原始数据+分组后数据的用 stream 肯定好因为用 sql 的 groupBy 要查询两次
    3 煞笔
    4 没问题

    所以你领导 100 分能得 67.5 分,及格而已
        30
    sakuramanstein   104 天前 via Android
    因为 mysql 对联表查有优化啊,比自己拆成几个表分别查要好
        31
    ericls   104 天前 via iPhone
    Benchmark it
        32
    xuanbg   104 天前
    @jk1030 分表之后当然就不能 join 了呀,正常的分页查询都没法做了呢。分表后需要正常分页查询的话,就必须借助 ES 或者 MongoDB 保存索引数据了,或者通过修改交互规避问题。
        33
    Takamine   104 天前
    都丢到业务层处理,多次查询。
        34
    lolizeppelin   104 天前   ♥ 2
    2 和 3 的核心问题是一样的


    查询过程无外乎


    数据库 应用层
    从硬盘读取数据——数据库解析数据——复制到网路层 ~~~~~~~~ 网络层复制到应用程序——应用程序解析


    数据库开销
    硬盘读取开销~解析开销~复制 /传输开销


    应用层开销
    解析开销~传输开销

    这些省不了的开销,无非是放在哪里而已

    用数据库解析, 数据库 cpu 消耗大,但是传输开销小
    应用解析,数据库 cpu 小,应用服务器 cpu 开销大,传输开销大
    但是数据量大起来以后,传输开销自然就不能忽视了

    如果 group by/join 前的数据远远大于处理后,思考两点
    1.应用层来 group/join,数据库计算量的虽然降低,但是好处是否会被大量传输抵消?
    2.一定量级上数据库层的 group/join 的否效率是否远远好于应用层?
    3.上述一定量级是如何判断?
    4.数据库层的 group/join 是否能降低硬盘 IO ?
    5.应用层 group/join 事务问题怎么解决


    -------------------------------------------------------------------------------------
    1.其他数据库要用函数索引,也需要索引函数对象,例如 index(int(column))
    2.mysql 不能多核并行查询,这个是死穴,当然少量数据肯定比你自己做强多了
    3.mysql 没有 hash join 和 merge join 稍微大的数据 join 起来肯定要死翘翘,但是少量数据又有索引肯定比应用层做好得多.
    至于到底多少数据量算大这个嘛............
    4.分表是下策,mysql 的表分区也是个残疾...上策嘛....换数据库!!

    所以说!!早点换 PG,压根就不纠结这些问题...真要纠结这些问题的时候,就是你换大数据的时候!!
    PG 一统江湖!
        35
    akira   103 天前
    @Breadykid 3 要针对性的看。没有性能问题的时候 ,该连表连表 , 该怎么写还是怎么写。
        36
    babedoll   103 天前
    联表优于单表,我考虑是老板觉得便于修改。如果做冗余,很可能内容在其他地方已经改了,但是这里还没改,就很麻烦。如果是通过外键联表,能保证数据正确。

    当然我感觉我 sql 学的比较浅,哪个老哥有更好的方法欢迎探讨。
        37
    micean   103 天前
    就一台服务器+一台数据库
    楼里的兄弟就别谈互联网应用、nosql 了……
        38
    leonme   103 天前 via Android
    看 profile,进行性能分析啊,理论指导实践,但是实践的效果还是要具体问题具体分析的,尤其是 sql
        39
    Breadykid   103 天前
    @Raymon111111 连表索引问题我可以去哪看,explain 的哪个字段,或者有啥学习资料安利吗
        40
    Breadykid   103 天前
    @lolizeppelin pg 党握爪!!!
        41
    lywaei   103 天前
    第三点 根本不是从性能上考虑至少不完全从性能考虑(更多的是维护上)
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2636 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 26ms · UTC 13:31 · PVG 21:31 · LAX 05:31 · JFK 08:31
    ♥ Do have faith in what you're doing.