Real-time Change (daily) data from a large number of data queries, resulting in loading takes a long time, ask how to optimize
For example, the user list has a user A he invited a lot of members a1,a2,a3 ... An, member A1 also invited a lot of members a11,a12,a13 ... A1n
A2 invited a lot of members a21,a22,a23,,,,,,,,,,,,,,,,,, a2n and so on a direct member is A1, A2,A3 and other indirect members have a11,a21 ..... A21,a22 ..... And so on each member to spend, the member himself will receive the rebate, and at the same time to the superior, the higher part of the return of money, the relevant data inserted into the order form, each user received from the relevant members of the rebate within 7 days can not withdraw, is frozen funds, so calculate the freezing of funds need to query a large amount of data, Including the member's own purchase order within 7 days, but also to find out all the direct members and indirect members from the user table and then find out their consumption within 7 days, so the frozen funds in the page display will load very slowly, ask how to design and optimize the table structure or how to design and optimize the program to speed up
Reply to discussion (solution)
As long as there is no case of subordinates inviting superiors, such as A22 invited a
Use the modified pre-order traversal (left-right pre-order) algorithm to organize the data
As long as there is no case of subordinates inviting superiors, such as A22 invited a
Use the modified pre-order traversal (left-right pre-order) algorithm to organize the data
Do not appear subordinates invite superiors, can be detailed explanation of not understand
Timed run Data timing update do not load in real time. This part of the operation uses a separate server to handle
The introduction of the Internet a lot, you search yourself
This article is fairly clear http://blog.csdn.net/yaerfeng/article/details/8517479.
Timed run Data timing update do not load in real time. This part of the operation uses a separate server to handle
If there is a daily consumption, the number is larger than the time to update the time between a timing to the next time there will be data inaccuracy.
Pretreatment not real-time statistics, data big real-time calculation to go crazy early planning, lest later worry
The simplest way to add a field to the table is to record the user ID for the next layer, separated by commas. This reduces the one-layer query.