求助大神，数据库的多表大数据连接查询应如何优化？

Question

本帖最后由 xylcxyfc 于 2014-10-20 11:18:18 编辑

Answer 1

各个表在cust_id上建索引，400万数据量不是太大，用索引查询速度应该还可以
前台显示所有信息也是一个客户一个客户的显示吧，每次需要在前台显示的数据量应该也不会太大的

Answer 2

你的意思是直接在前台查询吗，不会吧，内存32G，我试了一下，两张400w的表连接就要42s，那么多张表连接效率很慢的

Answer 3

1、各个表在cust_id上建索引
2、如果担心速度，可以单个查，得到10个datatable，然后组建一个新datatable

Answer 4

现在每张表已经有其他字段的索引了，可以建立多个索引吗，而且有几张表是按照日期进行表分区的，好像无法再根据cust_id建立索引了？

Answer 5

一个表可以建多个索引的，如果每个表都有cust_id的索引，速度应该挺快的

Answer 6

另外不明白你为啥要做表连接，10个表不都是单独的数据吗？
不应该是给定一个cust_id，然后去这个10个表分别查询相关数据吗？

Answer 7

上午的问题可能没说明白，现在上班补充一下环境吧，您再分析一下。
首先，有些业务并不是所有客户都有，所以我们需要用一张客户信息主表去左连接各业务表，按你所说就需要连接9次，每次单独连接一次400w+的数据，感觉都一样？其次，有些业务信息表的cust_id不是主键，可能会重复，所以在此过程中需要先对cust_id进行分组汇总，然后再去依次连接，如果单独去查的话，每次查一个客户都要先汇总再去取，会不会很浪费？还有，这个生成全景表的过程，将在每天的客户业务表加载完后运行，这样能够充分利用空闲时间，和前台直接查询相比就没有浪费插入表的时间浪费了。最后，由于用的是左连接，你所说的10的10次方应该是指full join吧，这方面不太清楚，左连接的话也是10？

Answer 8

临时表肯定查询很快的，关键是生成这个临时表需要多少时间，服务器是否有那么长的空闲时间来做这些
但是不管哪个方案，各个表cust_id的索引都是必需的，
建议先把相关索引建起来，然后再测试各个方案的执行效率

Answer 9

临时表肯定查询很快的，关键是生成这个临时表需要多少时间，服务器是否有那么长的空闲时间来做这些
但是不管哪个方案，各个表cust_id的索引都是必需的，
建议先把相关索引建起来，然后再测试各个方案的执行效率

前台表一边都是要建索引，只是楼主这种情况感觉先要弄个临时表。

Answer 10

临时表肯定查询很快的，关键是生成这个临时表需要多少时间，服务器是否有那么长的空闲时间来做这些
但是不管哪个方案，各个表cust_id的索引都是必需的，
建议先把相关索引建起来，然后再测试各个方案的执行效率

还没建索引，在生产上测试了下，几分钟这个合并的实表就加载完了，然后又试着在这个过程内建立多张临时表，时间要稍微长点，估计时间都浪费在插入数据上面了。
结论：这里left join因为关联后的数量和主表一致，不需要建立临时表，直接连接加载到目标表就行。首先那些客户信息都是客户的不同业务信息，我现在做的就是建立一个合并后的实表，这个实表在前面的数据加载完后加载，确实感觉和物化视图很类似。