Mysql in a faster way?

Question

I have a table in MySQL database:

  CodeNo Block
   a1     a
   a2     a
   b1     b
   b2     b
   c1     c
   c2     c 

I can query by using one of the two alternatives:

select codeno from mytab where block='b' and codeno like 'b%'

alternatively

select codeno from mytab where codeno like 'b%'

Which one is faster in an actual scenario when there are millions of records in mytab? Also could anyone explain the way it is actually stored in the database?

Answer 1

I think both will take same time because execution plan for both is same

1. Select data

2. Table scan 100%

and also look execution plan details

Answer 2

Without seeing the Execution plan i would guess that the first filter would reduce the amount of records on which the second filter is set, which makes the first option faster, specially that the like operator is a string comparision one ,which is not really as effective as numbers or binary comparison.

To know more about this you can generate the execution plan of both statements and compare running times, take a look a the documentation

Answer 3

First query should be faster, it limits the result by using block filter.

I would say: apply an index on block to increase speed.

ALTER TABLE mytab ADD INDEX blockindex(block);

see sqlfiddle and compare the execution plans: http://sqlfiddle.com/#!9/317d6/1

Answer 4

See @juergend comment about explain. The problem is "it depends". If no indexes on either field, the DB will do full table scan so no real difference. If codeno has index and block does not then the two statement would still be roughly equivalent since it would use the index on codeno in either case. If index on both fields the one with two conditions COULD be faster if the DB decided it is more beneficial to use the block index for first access. But the explain should show you what the DB decided to use for access plan.

Answer 5

In case you do not have any indexes on the table, the first query will take slightly more time, it is because nothing can be taken from memory, but you have to check two fields instead of one.

But this kind of denormalization is indeed very useful when you can add your own indexes. You can add just (block) index, so that the equality check would be done in memory, and the data for the second condition would be taken from the disk, but only for those rows that matched the first condition. This is especially useful when most of the rows the match the first condition match the second as well.

From the other side, you can add (codeno(1)) index, and the index would be used for the prefix check like codeno like 'b%' (be sure to specify the long enough prefix in the index), and this would take almost the same time. In this case the condition block='b' is not required, and even impedes.