Why MySQL query is faster the second time I run it?

Question

I have a very strange question coming from a observation I just made, that might actually help me understand better my database behaviour and design it better .

First of all, this is a MySQL database we are talking about. There is an index on User_ID field.

Here is the code I run :

query3 =("SELECT Content FROM Twit "
          "WHERE User_ID = %s "
          "limit 25 ")

for userid, c_word in user22_list:
    cursorSQL.execute(query3, (userid,))

For some reason that I don't understand when I run it for the 200 fisrt users for example, then stop it, it would take arround 1sec per 10 users, pretty slow.

But if few minutes later I run it for the 1000 first user, it'll reach 200 in less than a sec, then slow down to the 10user/sec speed after that, and so on if I run it for 5000 after that (very fast until 1000, slow after that).

Questions:

• Could the query be temporarily stored somewhere (in my server's RAM?) explaining its speed?
• Do you see any ways to speed up the process ?

***** Edit1 : As requested :

The output of SHOW CREATE TABLE Twit

  Table Create Table Twit CREATE TABLE `Twit` ( `ID_num` bigint(45) NOT NULL, `Content` varchar(250) COLLATE utf8mb4_unicode_ci DEFAULT NULL, `User_ID` bigint(24) NOT NULL, `Location` varchar(70) COLLATE utf8mb4_unicode_ci DEFAULT NULL, `Date_create` datetime NOT NULL, `Retweet_count` int(7) NOT NULL, `isRetweet` tinyint(1) NOT NULL, `hasReetweet` tinyint(1) NOT NULL, `Original` bigint(45) DEFAULT NULL, `Url` varchar(150) COLLATE utf8mb4_unicode_ci DEFAULT NULL, `Favorite_count` int(7) NOT NULL, PRIMARY KEY (`ID_num`), KEY `User_ID` (`User_ID`), KEY `Date_create` (`Date_create`), KEY `User_ID_2` (`User_ID`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci 

The Output of EXPLAIN SELECT Content From...

• id = 1
• select_type = 'SIMPLE'
• "table" = 'Twit'
• partitions = null
• type = 'ref'
• possible_keys = 'User_ID,User_ID_2'
• "key" = 'User_ID'
• key_len = '8'
• ref = 'const'
• "rows" = 298
• filtered = 100
• Extra = 'Using index condition';

Variables:

• 'innodb_buffer_pool_size', Value = '4294967296';

To make it clearer I am calling the SELECT request in a python loop. Every iteration is very fast if I have already ran the SELECT request for this user, very slow otherwise. Doesn't matter if the RAM has be wiped (server reboot) or not.

Thanks.

Answer 1

There are two "caches" that may explain the timing "speedup".

• InnoDB uses its "buffer pool" to avoid reloading stuff from disk.
• If the "Query cache" is on, then the second run could return "instantly" because the QC caches the result set.

"then slow down to the 10user/sec speed after that" -- smells like the data is not yet cached.

Don't use a LIMIT without an ORDER BY , unless you don't care which rows you get back.

What is cursorSQL ? Different clients do things differently; it may be important to understand what language you are using.

Please provide SHOW CREATE TABLE Twit and EXPLAIN SELECT ... so we can get into more details.

Please explain what you mean by "run it for the 1000 first user". Is that 1000 selects? One select with LIMIT 1000? Something else?

How much RAM do you have? What is the value of innodb_buffer_pool_size ?