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

[Breadykid]

背景：

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

领导见状后，如是说：

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

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

[optional]

看应用类型，对于高并发的互联网应用，2，3 都是 bad idea。

[optional]

嗯 为了避免被喷，加一个 具体情况具体分析。

[knva]

sql 压力越小越好

[notshytoday]

你不认同肯定有自己的原因的，说说呗

赞楼上的具体问题具体分析

[Xbluer]

1. oracle 中有所谓的函数索引，即针对列计算出函数的值在生成索引。mysql 好像可以使用虚列曲线救国。

[airfling]

我觉得单表查询优先于多表，单挑优先于 group by，groupby 可以不再数据库中做，完全可以自己需要的数据直接取出来，自己在内存中做。除非一次取的数据特别大，但是数据特别大这种情况你就要考虑分表了，建索引等优化措施了，而是不是 sql 优化就能解决的

[LeeSeoung]

1 涉及表字段设计，设计恰当很少出现查询字段需要转换后再查询的情况
2 是可以认同的，数据量大的情况下 请求大量数据回来，网络 IO 以及对内存都有要求
3 我看了网上一篇文章中讲到《高性能 mysql 》有提到这个问题，从缓存、锁竞争等方面来说，单表多次查是由于联表查的
4 完全同意

[scys]

* 听领导的，先按照领导的做一遍；
* 做完后发现没什么效果，研究下 2，3，看看哪里可以优化。

感觉这样工作才比较有效。

[a719114136]

做个实验就知道了，如果懒得做的话我告诉你，领导说的没错

[reus]

你看别的数据库就从来没有什么单表优于多表的说法
垃圾 mysql。

[xaplux]

很明显，不认同领导说的。但是这次你领导说的没什么问题，1 很明显，2 要看具体情况，如果是单表的 groupby 没有问题，3 JOIN 的多张表都比较大时，确实单表查询效率要高，4 没毛病

[binux]

3 看情况，如果 filter 字段都在表 1，join 表 2 取其他字段那是没问题的

[Breadykid]

@reus 同意，Postgres 就好很多

[luozic]

一切看数据量还有数据库服务器配置。

[Breadykid]

@knva 为什么领导说非多张大表连表查询的压力对于服务器来说微乎其微

[Breadykid]

@luozic
@binux
@xaplux
@a719114136
@LeeSeoung
@airfling
@optional

为什么领导说非多张大表 联表查询的压力对于数据库来说微乎其微？？？

[LeeSeoung]

不是大表你联查还是单表查都差不多。。个位数相同，小数点后几位你还在乎多少位么。。

[Raymon111111]

2. 尽可能把压力放在业务侧. 数据库资源很宝贵. 但是 groupby 涉及返回数据大小的问题, 所以还要具体问题具体分析.

3. 尽可能不做连表查询. 一个很重要的原因是连表的索引往往踩不对.

[winglight2016]

有索引的情况下，多表关联没有增加多少 payload。4000 多万可以开始准备分表了。报表不要用生产库来生成。

[glacer]

从来没有 MySQL 不能多表联查的道理，高性能的 join 查询本身就是关系型数据库的一大优势。在一些规范中限制连表的数量是因为程序员的水平参差不齐容易写出慢查询。
在索引命中合理的情况下，MySQL 对 Join 的处理性能是完全没有问题的，完爆将多表结果查出在内存中做聚合的做法。
如果在索引不合理使用的情况下，将多表拆成单表来查，照样和不能命中索引。难道就对数据库的压力就比联表查小了么？