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

@Breadykid mysql 8 是可以的，5 就不行

单表查询容易看出有哪些索引被命中

大多数推崇单表查的程序员，怕是根本不知道索引为何物吧。真懂索引的程序员根本不怕多表 join。

第一点不是绝对，oracle 可以建基于函数的索引；
其它表示认同。

@Breadykid join 在使用索引的情况下，效率损失不大。

@dog82 #24 这有什么不绝对的。基于函数的索引那是另一种索引，索引的是字段被函数处理后的样子，而不是当前的索引字段。

@xuanbg ？？？ 分表分库怎么处理

@Breadykid 因为如果是大表 JOIN 大表，笛卡尔积很可怕的，如果小表就还好呀

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

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

所以你领导 100 分能得 67.5 分,及格而已

因为 mysql 对联表查有优化啊，比自己拆成几个表分别查要好

Benchmark it

@jk1030 分表之后当然就不能 join 了呀，正常的分页查询都没法做了呢。分表后需要正常分页查询的话，就必须借助 ES 或者 MongoDB 保存索引数据了，或者通过修改交互规避问题。

都丢到业务层处理，多次查询。

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 一统江湖！

@Breadykid 3 要针对性的看。没有性能问题的时候 ，该连表连表 , 该怎么写还是怎么写。

联表优于单表，我考虑是老板觉得便于修改。如果做冗余，很可能内容在其他地方已经改了，但是这里还没改，就很麻烦。如果是通过外键联表，能保证数据正确。

当然我感觉我 sql 学的比较浅，哪个老哥有更好的方法欢迎探讨。

就一台服务器+一台数据库
楼里的兄弟就别谈互联网应用、nosql 了……

看 profile，进行性能分析啊，理论指导实践，但是实践的效果还是要具体问题具体分析的，尤其是 sql

@Raymon111111 连表索引问题我可以去哪看，explain 的哪个字段，或者有啥学习资料安利吗

@lolizeppelin pg 党握爪！！！