There is a request such

SELECT t.id AS `t_id`, t.title AS `t_title`, t.status AS `t_status`, u.login AS `u_login`, a.login AS `a_login` FROM `tickets` t LEFT JOIN `users` u ON u.id = t.creator_id LEFT JOIN `ticket_msgs` tm ON tm.ticket_id = t.id LEFT JOIN `users_admin` a ON a.id = tm.admin_id WHERE t.creator_id = :creator_id

So I thought about the question, can I better use one request instead, 4 requests? .. Just by breaking this request into 4 parts.

 SELECT t.id AS `t_id`, t.title AS `t_title`, t.status AS `t_status` FROM `tickets` t WHERE t.creator_id = :creator_id; SELECT login FROM users WHERE id = $query_1_res->creator_id; И остальные 2...

Does it make sense to do so? Just a man looked, said the request is very heavy, and it is worth breaking into several requests.

Indices are arranged in tables by id .

  • 3
    As he determined that the request is heavy. If there are indexes, there should be nothing heavy in it (of course, you can see the execution plan). And 4 separate requests are usually much slower, because each of them must be further disassembled by the DBMS plus the overhead of the transfer driver - Mike
  • So I began to doubt, because in any case, 4 requests work longer for me longer .. - user190134
  • Is it necessary to LEFT join? Does the logic allow for the absence of records in related tables? - Akina
  • No, records must be in tables. - user190134
  • one
    I understand that formally the idea of ​​the reviewer was such that there was no need to select data from users N-times in the general data set, since Is there always the same thing? In general, if the sample is large, then maybe it makes sense. In general, if we have a lot of tickets, and a lot of messages in them, then it makes no sense to multiply all this and drag everything all too special. The request may not be "heavy" just illogical to pull everything at once in one heap. - teran

0