MySql, SELECT * FROM with Indexed columns

Question

I'm working with a table in MySql that has an int indexed column called "serial". This table has around 2 million rows.

If I apply a select statement with this column in this way:

 SELECT serial FROM Table WHERE Serial=12345

this returns the data in around < 1 sec.

However, if I use a SELECT * query in this same table, this query takes around 78 seconds...

I know it is not useful to apply indexes to all the columns in the table, how can I optimize/minimize the query response time if I need to get all the columns from a specific serial?

 SELECT * FROM Table WHERE serial= 12345

The results from EXPLAIN :

SELECT serial:

1 SIMPLE tableName index idx_tablename_serial 5 6686620 Using index

SELECT * :

1 SIMPLE agsensepivotreadings ALL (null values) 6686620

Please, any sugggestion or guide will be very appreciated.

Let's say there are 20 columns and I need to return 18 columns, these are properties read from a device every 5 minutes. — Alberto Montellano, Nov 12 '15 at 12:44
The first query is fast, because the table itself doesn't have to be read at all, ast the whole information needed is in the index. As to the second query: How many records share a serial number? (Mininum, Maximum, avarage, typical.) — Thorsten Kettner, Nov 12 '15 at 12:52

score 1 · Answer 1 · answered Nov 12 '15 at 12:47

1

Even limiting how many columns you need to read by a few will help. Just limit it even more and IF indexing a few more columns helps then go ahead but they'd need to be used in the WHERE clause.

answered Nov 12 '15 at 12:47

score 1 · Answer 2 · edited Jan 08 '22 at 04:27

It is rather unlikely that the columns are causing the problem. This could happen if one (or more) of the columns are really, really large objects. To get to 78 seconds, you need to be thinking in terms of many megabytes or gigabytes, although even 1 Gbyte might not take that long in many environments.

The use of the index versus the non-index is easy to explain. The first query is covered by the index, so the original data pages are not needed. The second query is not covered by the index. Because so many rows are being selected, all the data may need to be read, in order to find a matching row. This is an optimization to prevent thrashing. It might explain what is going on, although 78 seconds for loading a table into memory seems like a long time -- unless the rows are very wide.

Another possibility is that other operations are locking the table. In many environments, this would be the most likely culprit.

Finally, if the queries were subtly different (such as one having an order by or the constant being enclosed in single quotes), then that might account for some difference.

I would check the explain to see what is happening. Even searching through a table with a few million rows should not take 78 seconds.

score 1 · Accepted Answer · edited May 23 '17 at 12:07

1

There is part answer for your question.

https://stackoverflow.com/a/3211164/2957840

But also, maybe you should consider partitioning your table: https://dev.mysql.com/doc/refman/5.7/en/partitioning.html

edited May 23 '17 at 12:07

Community

1
1

answered Nov 12 '15 at 12:53

z48o0

98
7

score 0 · Answer 4 · answered Nov 28 '15 at 05:11

0

If Serial is VARCHAR, you have a typing problem. Put quotes around "123456".

PARTITION will not help that query.

Please provide SHOW CREATE TABLE if you need to discuss this further.

answered Nov 28 '15 at 05:11

Rick James

135,179
13
127
222

MySql, SELECT * FROM with Indexed columns

4 Answers4