不知道给位是怎么处理的？能否给一些建议?主表是 45W 左右的数据，从表大概 8W 左右。
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2709 days ago, the information mentioned may be changed or developed.
 |
moodasmoodJun 6, 2019
1
这么点数据，瞎 jb 操作都合理
|
|
moodasmoodJun 6, 2019
2
最好业务层处理，查询 3 次，数据库层面不做任何拼表
|
 |
securityCodingJun 6, 2019
3
做好索引 , 数据量不大的话单表 /连表都行的.
推荐 2 楼的做法 |
 |
desJun 6, 2019 via Android
4
看情况吧，分开了好缓存
|
 |
TianaoJun 6, 2019 via iPhone
5
#2 +1，不要在数据库层面搞骚操作，交给业务逻辑去做。
|
 |
akiraJun 6, 2019
6
a 连 b 连 c 的话 ，真不建议，一堆人搞不定的，
还不如按 2l 拆开来写 |
 |
DreamSpaceJun 6, 2019 via Android
7
@moodasmood #2 为什么要查 3 次呢？查 3 次感觉会比一次拉出来慢很多，还要消耗额外的连接数，组装数据时还会有内存和性能上的开销。
|
 |
LeamminJun 6, 2019 via Android
8
@DreamSpace 一次查询的话其实就是把应用层的性能开销转移到了数据库层，但数据库层的资源非常宝贵，所以一般都在应用层处理。
|
 |
LighferJun 6, 2019
9
@DreamSpace 数据库的可扩展性比上层应用差得多，因此资源也就要珍贵得多，上层应用开销大点问题不大，内存不够了，cpu 不够了，加机器就是了，相比较而言数据库就没那么简单了
|
 |
leon0903Jun 6, 2019
10
其实我也有一个疑问 都说在业务层自己拆开按照单表去查，但是这样的话如果有分页呢？还有就是假如第一次从 A 表中查出来有 100w 条数据，然后要把这 100w 条数据当作条件放到 B 表中去查询，这样的话生成的 sql(如 where id in(.........................................) )难道不会超出 mysql 限制吗(我知道 mysql 这个参数可以调整，但是这终究是一次很大的网络消耗，而且容易失败)？
|
 |
razertoryJun 6, 2019
12
三表 join，索引做好了没有问题的
|
 |
sonyxperiaJun 6, 2019
13
是不是问问你们的 DBA 啊
|
 |
F281M6Dh8DXpD1g2Jun 6, 2019
14
很少有人自己手写能比数据库跑的快的
mysql 除外，他的 join 本身就很烂 |
 |
jiezhiJun 6, 2019 via iPhone
15
联表查过二十多张表……
四百多行的 SQL 语句😂，不过我是搞数据的 |
 |
versionJun 6, 2019
16
如果是 api 接口的一般拆 3 个 sql 再 redis 缓存
如果是数据统计.看业务吧.有些过滤可以是 redis 存 id 或者其它方式来过滤.再 sql.都可以. 具体看业务了.没有绝对的方法..为了性能还是为了好修改好写代码 |
 |
msg7086Jun 6, 2019
17
@DreamSpace 想一想数据库的扩展性和应用程序服务器的扩展性。
数据库做一个集群代价很高，但是应用程序服务器你随便搞个几千台都不是问题。 @leon0903 你什么查询需要在 B 里查 100 万条记录？ 如果真的有那么大的数据量过滤，放到 MySQL 内部做也不会更快。 |
 |
armyskyJun 7, 2019 via Android
19
如果表之间的关联是能命中索引，当然是写表关联了
|
 |
20
还是觉得两张表 join,再处理数据好一点。
|
Select Language