|
|
|
Помогите разобратся с оптимизацией запроса в mysql!
|
|||
|---|---|---|---|
|
#18+
Есть таблица: -- Структура таблицы `work` CREATE TABLE IF NOT EXISTS `work` ( `id` int(11) NOT NULL, `first_name` int(11) DEFAULT NULL, `last_name` int(11) DEFAULT NULL, `bdate` date DEFAULT NULL, `day` tinyint(2) NOT NULL, `month` tinyint(2) NOT NULL, `year` int(5) NOT NULL, `country` int(11) DEFAULT NULL, `city` int(11) DEFAULT NULL, `data` longtext, `pr` tinyint(1) NOT NULL, PRIMARY KEY (`id`), KEY `bdate` (`bdate`), KEY `pr` (`pr`), KEY `day` (`day`), KEY `month` (`month`), KEY `year` (`year`), KEY `first_name` (`first_name`), KEY `last_name` (`last_name`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; В таблице 10 миллионов записей. Делаю выборку исключительно по цифровым полям, которые проиндексированы: SELECT id FROM work where first_name = '11' AND last_name = '22' AND day = '5' AND month = '10' AND year = '2001'" В результате по времени такой запрос работает так: Поиск записи: 3 sec. Поиск записи: 0 sec. Поиск записи: 1 sec. Поиск записи: 0 sec. Поиск записи: 28 sec. Поиск записи: 3 sec. Поиск записи: 112 sec. Поиск записи: 1 sec. Поиск записи: 2 sec. Поиск записи: 0 sec. Поиск записи: 34 sec. Поиск записи: 11 sec. Соответственно поиск 1000 записей занимает несколько часов! Никаких update и delete параллельно не ведётся. При этом mysql совсем не занимает процессор – меньше 1%!!! Mysql установлена на локальной машине WIN 7. Вопросы: 1. Что я сделал не так, почему так долго проходит поиск, почему такой разброс по времени и что делать? 2. Почему совсем не занят процессор, как заставить mysql пользоваться для поиска всеми ресурсами ПК? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2015, 15:00:40 |
|
||
|
Помогите разобратся с оптимизацией запроса в mysql!
|
|||
|---|---|---|---|
|
#18+
Валентин2015, 1) зачем-то дату разбил на порции и хранишь отдельно каждый её фрагмент, вместо того, чтобы иметь одно поле с дата-временным типом. сравниваешь в запросе числовые поля со строковыми константами, но не анализируешь планы запроса на предмет использования или неиспользования индексов. 2) если у тебя идет полное сканирование таблицы, то процессору особо и делать нечего, ибо производительность жесткого диска куда меньше, чем возможности процессора по обработке данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2015, 15:59:25 |
|
||
|
Помогите разобратся с оптимизацией запроса в mysql!
|
|||
|---|---|---|---|
|
#18+
у вас 8 отдельных индексов, а форма запроса "WHERE условие AND еще_1_условие AND и_еще_условие AND ...." не умеет работать с сразу с несколькими индексами. Соответственно вся эта наиндексированная хренотень - ему до лампочки. mysql выбирает какой-то 1 индекс, потом смотрит - все равно ж надо смотреть всю таблицу. И его тоже может отбросить. Если хочется использовать индекс для подобных запросов эффективно, надо делать составной индекс - по полям перечисленным в where. Причем, сразу скажу, покрывающих индексов делать ненадо. Т.е., если у вас есть индекс KEY(a, b), то нет смысла делать KEY(a) (за исключением мега-редких ситуаций) И предыдщий коментатор тоже все правильно написал. Вопрос про 1% у вас от недопонимания как работают базы данных и что влияет на их скорость. Можно иметь мегасупербыстрый cpu, но если диск медленный и база не вмещается в ОЗУ, то будут тормоза, связанные с тем, что мускулу надо прочитать данные с диска. В это время проц будет ненагружен. Под линуксом я бы посоветовал вам глянуть вместо top - iotop. Вы бы увидели там 100%. Под виндой я незнаю как смотреть iotop, но если вы сами найдете как это сделать - то вероятно увидите такую картину. Если mysql запущен на домашней машине, то iotop проще всего смотреть по светодиоду винчестера :) Соответственно, есть 3 пути убыстрения - правильно индексировать/проектировать базу, наращивать память (возможно - просто переконфигурить mysql, если ему дали мало), наращивать быстродействие диска. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2015, 12:16:42 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38954715&tid=1833225]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
34ms |
get tp. blocked users: |
1ms |
| others: | 231ms |
| total: | 349ms |

| 0 / 0 |
