# optimizer and use of indices

**URL:** https://forums.percona.com/t/optimizer-and-use-of-indices/1091
**Category:** Other MySQL® Questions
**Created:** [February 21, 2009, 4:12pm UTC](https://forums.percona.com/t/optimizer-and-use-of-indices/1091 "2009-02-21T16:12:39Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![mm1259748](https://avatars.discourse-cdn.com/v4/letter/m/2bfe46/32.png) [@mm1259748](https://forums.percona.com/u/mm1259748)
#### Post date: [February 21, 2009, 4:12pm UTC](https://forums.percona.com/t/optimizer-and-use-of-indices/1091/1 "2009-02-21T16:12:39Z")

</div>

Hi,

I would like to know how indices are used by the mysql optimizier:

is rather slow compared to

by a factor of 100.

It seems that the fast index\_merge is only used when there are no other conditions in the where clause.  
[LIST]  
[_] What ist the correct approach to optimize complex cases like “OR (b AND C) OR x AND y OR z […]”?  
[_] If i use combined indices (eg: ord+approved) does it matter if I write the query (ord=20 and approved=‘Y’) or the other way round (approved=‘Y’ and ord=20) Are combined indices considered for OR queries?  
[/LIST]  
thank you  
Manfred

technical background:

I have the folowing Innodb table with ca. 70000 records.

CREATE TABLE `mynews` (  
`id` int(20) NOT NULL auto\_increment,  
`ts` timestamp NOT NULL default CURRENT\_TIMESTAMP on update CURRENT\_TIMESTAMP,  
`created` datetime NOT NULL default ‘0000-00-00 00:00:00’,  
`changed` datetime NOT NULL default ‘0000-00-00 00:00:00’,  
`ord` double(11,0) NOT NULL default ‘0’,  
`owner` varchar(30) collate latin1\_german1\_ci NOT NULL default ‘’,  
`sections` varchar(255) collate latin1\_german1\_ci NOT NULL default ‘’,  
`approved` char(1) collate latin1\_german1\_ci default ‘N’,  
`title` varchar(250) collate latin1\_german1\_ci NOT NULL default ‘’,  
PRIMARY KEY (`id`),  
) ENGINE=InnoDB AUTO\_INCREMENT=53418 DEFAULT CHARSET=latin1 COLLATE=latin1\_german1\_ci PACK\_KEYS=1 COMMENT=‘InnoDB free: 10240 kB’

ord is an order column and contains (nearly) unique numbers, id is autoincrement and approved is char(1) where nearly all records contain ‘Y’.

The following query takes quite long:

Explain says 44910 rows scanned.

same result - no wait, instant results  
Explain says 11 rows scanned.  
Different indices make no difference.

---

<div class="post-metadata">

### Author: ![xaprb](https://avatars.discourse-cdn.com/v4/letter/x/49beb7/32.png) [@xaprb](https://forums.percona.com/u/xaprb)
#### Post date: [December 25, 2009, 7:21am UTC](https://forums.percona.com/t/optimizer-and-use-of-indices/1091/2 "2009-12-25T07:21:25Z")

</div>

The optimizer’s use of indices in cases like this is limited. At times you might need to resort to UNION to make the conditions simple enough to be efficient.
