I a rookie, there is now a requirement is:
There is a user table is the main table t_user
There are a lot of the relationship between the users table, such as between users have any attention t_follow table, is there any access t_visit table and so on, probably more than a dozen states,
Then I now as a user, pull 30 users user information, and at the same time according to t_follow, t_visit exterior-interior relationship between data acquisition users such as compared to my state,

Now my practice is to pull out 30 users first, and then in the service layer according to the relationship between each corresponding data table, and then fill in the model, as a result of such processing interface can be slow, probably close to 1 s can be processed, a great god can give a optimization method or way of thinking?

Thank you,

CodePudding user response:

Can watch LianZha more, as the main table t_user, through the join on connecting the rest of the child table, and find out the corresponding field,

CodePudding user response:

Above said with a left join then indexed, basically all soon

CodePudding user response:

Save the redis

CodePudding user response:

reference 1 O f the name so much reply:

can watch LianZha more, as the main table t_user, through the join on connecting the rest of the child table, and find out the corresponding fields,

Thank you for your answer, consider using multiple tables LianZha, user table and other properties such as user_detail etc. The join table used, but the actual effect but no quick query many times later, they so this place not used, and according to join the best not many articles have said?

CodePudding user response:

refer to write diary 3 floor of the Yangtze river water response:

save the redis

User information is on the inside of the redis, but even the relationship in redis inside the data quantity will not too big? And the relationship is often change, seems a little inappropriate

CodePudding user response:

I think you said in the model, the separation of front and back side is not? Then use ajax asynchronous processing. Another redis, with id primary key, put all the focus on the user's id, then use atomic inc method visited don't have any problem, redis high performance

CodePudding user response:

App backend, I do not web, fill in model refers to the dao layer in SQL detected results, then the service layer, the results were assembled into usermodel the status inside, I try again is redis faster or join some quick, because these status will often change, put redis feel strange, like visits, each visit will change, the redis inside corresponding also want to change every time, so you feel no redis cache effect

CodePudding user response:

Education, I also have this problem

CodePudding user response:

refer to 7th floor CMWSSSSS response:

I'm in the app back end, not the web, fill in model refers to the dao layer in SQL detected results, then the service layer, the results were assembled into usermodel the status inside, I try again is redis faster or join some quick, because these status will often change, put redis feel strange, like visits, each visit will change, the redis inside corresponding also want to change every time, so you feel no redis had the effect of the cache

Access number changed, must be changed in the redis, faster than operating table data in hard disk, because I think your company table structure design is unreasonable, along with the API of the redis unfamiliar problems. How can access to penetrate to the database every time? This is not a joke?

CodePudding user response:

refer to the eighth floor weixin_13316459763 response:

instructed, I also have such problems

you have indexed database table? Need in the current query columns with index can greatly improve efficiency, avoid global query, details you can check the SQL statement optimization, generally unless you particularly large amount of data, or left the join of query speed,

CodePudding user response:

Indexed, with even the table later do have faster, it turns out the interface need 1 s, now is about 0.5 s, but there's no better way of optimization, now my practice is a state of all users associated found out, this is very fast, probably around 10 ms, is faster than the original table to check one by one, but the interface to a secondary return to 30 users, is on behalf of my basic information to the user first found out, one by one to check again 30 users corresponding associated states, is there any way to optimize this kind of circumstance?