mysql multiple column index

Това е таблицата:

CREATE TABLE `geo` (
`ipFrom` int(10) unsigned zerofill NOT NULL default '0000000000',
`ipTo` int(10) unsigned zerofill NOT NULL default '0000000000',
`Country` varchar(64) NOT NULL default '',
`State` varchar(128) NOT NULL default '',
`City` varchar(128) NOT NULL default '',
PRIMARY KEY (`ipTo`,`ipFrom`)
) TYPE=MyISAM;

а това е случая:

mysql> explain SELECT * FROM geo WHERE ipTo >= 3645610104 AND ipFrom <= 3645610104;
+----------+-------+---------------+---------+---------+------+-------+-------------+
| table | type | possible_keys | key | key_len | ref | rows | Extra |
+----------+-------+---------------+---------+---------+------+-------+-------------+
| geo | range | PRIMARY | PRIMARY | 4 | NULL | 41914 | Using where |
+----------+-------+---------------+---------+---------+------+-------+-------------+
1 row in set (0.00 sec)

mysql> explain SELECT * FROM geo WHERE ipTo >= 1108966761 AND ipFrom <= 1108966761;
+----------+------+---------------+------+---------+------+---------+-------------+
| table | type | possible_keys | key | key_len | ref | rows | Extra |
+----------+------+---------------+------+---------+------+---------+-------------+
| geo | ALL | PRIMARY | NULL | NULL | NULL | 1601606 | Using where |
+----------+------+---------------+------+---------+------+---------+-------------+
1 row in set (0.00 sec)


защо при първата заявка използва индекс, а при втората не при положение че са еднакви?:)

unF ..

Заради статистиката.

Зависи от това колко реда има в таблицата и какъв процент от тези редове Оптимизаторът очаква да отговарят на условието. Когато попаденията са "много" няма смисъл от индекса - четенето от данните е по-бързо.

Колко много е много е една много дълга тема ...

salle.online.bg/sig

Някъде бях чел, че "много" попадения за MySQL са над 30%. Т.е. ако данните, отговарящи на условието, съставляват повече от 30% от всички, се минава на последователно сканиране ("sequential scan"). Май беше в "High Performance MySQL".

А вече дали 30% са достатъчно много, зависи доста и от скоростта на диска и от разни други неща.

Everything louder than everything else...

В 4.0 е по-скоро някъде около 25%

Нещата наистина са доста сложни. Идеята за индексирането е много стара и в днешно време се оказва, че презумпциите на които тази идея е базирана далеч не винаги са верни.

Един много "изненадващ" пример е когато четенето на цяла таблица е по-бързо от четенето на индекс въпреки, че от индекса се извличат само част от стойностите. "Нелогичността" идва от основната презумпция, че четенето на данните и индекса е еднакво бавно. Е да ама обаче когато се чете от диска данните могат да се четат последователно а при индекса винаги четенето е "случайно". А пък съвременните дискове и контролери дават много по-висока скорост при последователно четене.
И изведнъж установяваш например 1GB данни се прочитат по-бързо от 200M индекс.

Пък ако индексът е кеширан или пък ако не е и т.н.

Изобщо от оптимизатора се иска хем да разъсждава изключително много хем да го прави страшно бързо а двете едновременно е трудно да се съвместят. Няма особен смисъл от перфектна оптимизация която може да свали изпълнението от 20 сек. на 1 сек. обаче за да се намери оптималния план трябват 10 мин.

Не е тайна, че оптимизаторът на MySQL никога не е бил особено хитър, но за сметка на това е бърз. Е в 5.0 има добавени някои хитрини, които не би трябвало да забавят а само да ускоряват, но засега няма много отзиви.

salle.online.bg/sig