There are about a million entries in the table.
You can make several queries to select rows using WHERE by index:

  1. WHERE type = ... , idUser = ..., idTouser = ... ORDER BY id DESC LIMIT 20
  2. WHERE ID IN(1,2,3,4,5...)
  3. WHERE type = ... , idUser = ..., idTouser = ...AND time > last_time_selected ORDER BY id DESC LIMIT 20

What will be optimal and under what conditions? Where can I get information?

  • 2
    Explicit listing of all id will help only if there are two or three, if there are dozens of them, then such a request will be slow, very slow. 1 and 3 queries are similar, but differ only in an additional condition. Therefore, often, one correct index can greatly improve performance. - KoVadim
  • one
    @KoVadim, 200k records. id in (<1000 values>): The request is open for 0.016c [0.003c execution, 0.013c sample] explain is also not surprising, it shows simple, range, PRIMARY ... so please explain with examples. - Yura Ivanov
  • 2
    And this is called fast? Or now slowly, if half an hour? And if the application is loaded? This is at best 67 requests (not taking into account other overhead costs). Actually, you yourself and argued. Test with other requests, compare, just do not forget, muscular has learned to cache requests well, even in the most unobvious situations. - KoVadim
  • one
    I will test - I'll post the results a bit later ... - Jony
  • @KoVadim, What’s the point of being loaded, not loaded? if there are 67 requests for one request, this is not in favor of the chosen structure of the application, that's all. > only if there are two or three, if there are dozens of them, then such a request will be slow, very slow, this statement is false. And I have already tested it for you. 3 thousandths of a second for a list of thousands of values ​​(it still needs to be looked for where this may be needed). You said it would be super slow if there are dozens of values. Will not be. Or did you look at 0.013? so is the data transfer time. - Yura Ivanov

0