grey2, число запросов, которые может выполнить диск в секунду конечно и невелико.
поскольку гарантированного разделения доступа к диску такие системы не дают, чему тут можно удивляться в этой ситуации ?
Ничего не лимитировать. Просто горевать.
Если вы не смогли повторить эксперимент - значит вы что-то не правильно делаете. Я для кого версию mysql написал? Поставьте 5.1 и у вас тоже не будет использоваться.
А дальше попытайтесь весь свой бред переосмыслить.
Хорошо, последний раз попытаюсь донести мысль теперь по вашим правилам ведения дискуссии. Мне ничего не жалко ради истины.
Ответ на ваш вопрос таков :
в терминах, которыми оперирует оптимизатор, он будет использоваться или не будет использоваться независимо от значения 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 в 11:36 ----------
только самые отмороженные и "прогрессивные".
Проблема с новыми версиями mysql в том, что этот самый оптимизатор мог измениться не только в лучшую, но и в худшую сторону. Если со старыми версиями разработчики прикладных программ уже повозились и модифицировали запросы, то если вы попадете на худший случай на новой версии, то один запрос может поставить раком весь сервер. Чем больше клиентов, тем больше шансов этому произойти.
Так что тестируйте mariadb пока на себе. А хостеры посмотрят.
Именно так.
Не до конца понятно что у вас там за аутентификация.
Если это "домашний" провайдер, то хлебнете горя с настройкой PPPOE или других способом. Но в обычном случае все будет нормально.
По-моему, в каких-то версиях там были странные особенности, типа как с помощью tcpdump под суперпользователем можно на одной машине прослушивать весь трафик соседних машин.
Но это же мелочи, да?
То есть, воспроизводимый пример вы не смогли сделать.
Мне этого достаточно чтобы быть уверенным, что я донес свою мысль.
Мне бы помогло четкое указание в документации как именно key_buffer_size влияет на решения оптимизатора. Хотя я знаю, что вы такого не найдете.
Это прикол такой у молодых хабростартаповцев и прочих недалеких специалистов. Универсальное решение когда они видят любое число параллельных запросов больше двух. Они считают, что innodb всегда быстрее работает.
В данном случае innodb можно было бы использовать только потому, что там выборка "как оно валяется" в принципе не возможна, только с использованием primary key. Хотя это и не значит что в целом запросы будут работать быстрее.
WapGraf, правильно. Не надо спорить. Просто запомните, что хостер в этой ситуации не может повлиять настройками mysql на оптимизатор.
WapGraf, с интересом посмотрю как вы заставите mysql НЕ работать. То есть, если предположительно mysql настроен неправильно, то вы сможете настройками воспроизвести ситуацию как у ТС даже на своем наборе данных.
WapGraf, нет никаких предпосылок полагать, что поведение mysql в этом случае изменилось бы от такой "настройки".
