MySql постоянно падает

Вместо жизни в своем маленьком сказочном мире, ответьте на вопрос:

key_buffer_size=1М, используется 100%, создаем новую табличку с большим индексом. Что будет с индексом? Как он будет использоваться?

Я вам помогу, так как в принципе этот пример описан в документации, которую вы также игнорируете как и все прочее, - получите filesort.

Так что пока документацию не переписали под правила вашего мира, ваши теории так и останутся мифами.

Хорошо, последний раз попытаюсь донести мысль теперь по вашим правилам ведения дискуссии. Мне ничего не жалко ради истины.

Ответ на ваш вопрос таков :

в терминах, которыми оперирует оптимизатор, он будет использоваться или не будет использоваться независимо от значения key_buffer_size.

Разумеется, маленький буфер будет менее эффективен, но вывод explain от этого не изменится.

Вот я попробовал воспроизвести проблему ТС и легко ее повторил.

CREATE TABLE phones(

  id INT(11) NOT NULL AUTO_INCREMENT,

  abonentname VARCHAR(255) NOT NULL,

  phone VARCHAR(64) NOT NULL,

  abonentid VARCHAR(64) NOT NULL,

  PRIMARY KEY (id)

)

ENGINE = MYISAM;





-- тут я запустил генератор. но я могу просто выложить дамп. 



mysql> \s

--------------

C:\mysql\bin\mysql.exe  Ver 14.14 Distrib 5.1.43, for Win32 (ia32)



mysql> show global variables like '%key_buff%';

+-----------------+---------+

| Variable_name   | Value   |

+-----------------+---------+

| key_buffer_size | 1048576 |

+-----------------+---------+



mysql> explain SELECT abonentname, abonentid, phone FROM phones ORDER BY id ASC LIMIT 2270,100;

+----+-------------+--------+------+---------------+------+---------+------+--------+----------------+

| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows   | Extra          |

+----+-------------+--------+------+---------------+------+---------+------+--------+----------------+

|  1 | SIMPLE      | phones | ALL  | NULL          | NULL | NULL    | NULL | 100000 | Using filesort |

+----+-------------+--------+------+---------------+------+---------+------+--------+----------------+





mysql> set global key_buffer_size=1*1024*1024*1024;

Query OK, 0 rows affected (0.09 sec)



mysql> explain SELECT abonentname, abonentid, phone FROM phones ORDER BY id ASC LIMIT 2270,100;

+----+-------------+--------+------+---------------+------+---------+------+--------+----------------+

| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows   | Extra          |

+----+-------------+--------+------+---------------+------+---------+------+--------+----------------+

|  1 | SIMPLE      | phones | ALL  | NULL          | NULL | NULL    | NULL | 100000 | Using filesort |

+----+-------------+--------+------+---------------+------+---------+------+--------+----------------+

1 row in set (0.00 sec)

Видно, что план не поменялся даже когда я я увеличил значение key_buffer_size с 1мб до 1 Гб.

http://yadi.sk/d/oL6LnJRv8VYHU файл со сгенерированными "телефонами" .

Ну и чтобы убедиться что план не всегда отражает реально сделанные операции, еще один эксперимент, который показывает что на выборку запланировано 98474 строк, а реально считывается 100 :

mysql> explain SELECT abonentname, abonentid, phone FROM phones WHERE id>=1473 ORDER BY id ASC LIMIT 100;

+----+-------------+--------+-------+---------------+---------+---------+------+-------+-------------+

| id | select_type | table  | type  | possible_keys | key     | key_len | ref  | rows  | Extra       |

+----+-------------+--------+-------+---------------+---------+---------+------+-------+-------------+

|  1 | SIMPLE      | phones | range | PRIMARY       | PRIMARY | 4       | NULL | 98474 | Using where |

+----+-------------+--------+-------+---------------+---------+---------+------+-------+-------------+





SELECT abonentname, abonentid, phone FROM phones WHERE id>=1473 ORDER BY id ASC LIMIT 100;



-- тут разумеется пропущен вывод мусора



mysql> show session status like 'handler%';

+----------------------------+-------+

| Variable_name              | Value |

+----------------------------+-------+

| Handler_commit             | 0     |

| Handler_delete             | 0     |

| Handler_discover           | 0     |

| Handler_prepare            | 0     |

| Handler_read_first         | 0     |

| Handler_read_key           | 1     |

| Handler_read_next          | 99    |

| Handler_read_prev          | 0     |

| Handler_read_rnd           | 0     |

| Handler_read_rnd_next      | 0     |

| Handler_rollback           | 0     |

| Handler_savepoint          | 0     |

| Handler_savepoint_rollback | 0     |

| Handler_update             | 0     |

| Handler_write              | 0     |

+----------------------------+-------+

Как видите, у меня индекс используется

---------- Добавлено 30.08.2013 в 19:30 ----------

Но должен таки признать свою неправоту по запросам ТС. Пересмотрел повторно циферки в запросах. EXPLAIN не показывает использование индекса, когда в LIMIT выбирается более 1% строк от общего количества в индексе.

Если вы не смогли повторить эксперимент - значит вы что-то не правильно делаете. Я для кого версию mysql написал? Поставьте 5.1 и у вас тоже не будет использоваться.

А дальше попытайтесь весь свой бред переосмыслить.

Прочтите последние мои фразы (под скрином).

И на 5.1 также, проверил. Причину написал ^^. Там же и ответ почему у вас не используется (1473/100тыс > 1%).