|
|
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
Привет. Есть таблица пользователей. Мне нужно реализовать поиск пользователей по нескольким полям. Получается приблизительно такой запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Разумеется из всех этих полей создан составной индекс 'search' Таблица InnoDB. Записей 1 000 000. Запрос выполняется 1,6 секунды. Лимит использовать не могу, т.к. все юзеры должны равновероятно находиться поиском в 1 запрос. Что можно придумать? Может стоит использовать какой-то другой инструмент и хранилище для подобного поиска? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 14:06:11 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
ДанилкоРазумеется из всех этих полей создан составной индекс 'search'Набор полей в поиске всегда один и тот же? Порядок полей в индексе какой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 14:10:22 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
miksoftДанилкоРазумеется из всех этих полей создан составной индекс 'search'Набор полей в поиске всегда один и тот же? Порядок полей в индексе какой? Набор в запросе всегда одинаков. Порядок в индексе играет роль? У меня такой: user_last_active 204171 A Нет user_hide 204171 A Нет user_is_bot 204171 A Нет user_id 1020859 A Нет user_rate 1020859 A Нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 14:14:16 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
ДанилкоПорядок в индексе играет роль?Еще как играет. Начинать надо с тех полей, по которым происходит точное сравнение на равенство. А дальше "не все так однозначно". Попробуйте создавать индекс с разным порядком полей, возможно, что-то получится. А сейчас индекс используется только как покрывающий индекс, не более того. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 14:23:24 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
miksoftДанилкоПорядок в индексе играет роль?Еще как играет. Начинать надо с тех полей, по которым происходит точное сравнение на равенство. А дальше "не все так однозначно". Попробуйте создавать индекс с разным порядком полей, возможно, что-то получится. А сейчас индекс используется только как покрывающий индекс, не более того. Как-то не спасает. Выкинул пока проверку NOT IN по user_id. Построил: user_is_bot 2 A Нет user_rate 1004 A Нет user_last_active 1020859 A Нет user_hide 1020859 1.2 секунды, но это за счет выкидыша user_id. С лимитом запрос летает. Т.е. если поставить LIMIT 100, то время выполнения этого же запроса 0.001. Может проблема как раз в количестве данных выборки? Без лимита их около 500к ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 15:24:49 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
ДанилкоМожет проблема как раз в количестве данных выборки? Без лимита их около 500кТогда и "1.2 секунды" - очень неплохое время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 15:27:09 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
miksoftДанилкоМожет проблема как раз в количестве данных выборки? Без лимита их около 500кТогда и "1.2 секунды" - очень неплохое время. Т.е. более быстрее выполнить этот запрос в mysql у меня не получится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 15:31:17 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
Данилкоmiksoftпропущено... Тогда и "1.2 секунды" - очень неплохое время. Т.е. более быстрее выполнить этот запрос в mysql у меня не получится?По крайней мере, я сходу не вижу, как можно это кардинально улучшить. Улучшить чуть-чуть можно попробовать изменяя порядок и состав полей в индексе (он в любом случае будет использоваться как покрывающий, но не для ускорения фильтрации). Или даже вовсе отказаться от индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 15:35:42 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
miksoft, В каком смысле отказаться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 15:36:50 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
Данилкоmiksoft, В каком смысле отказаться?В прямом. Удалить его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 15:37:36 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
miksoft, ну если составной не юзать, а просто повешать индексы на все поля, то еще медленнее выполняется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 15:41:00 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
Данилкоmiksoft, ну если составной не юзать, а просто повешать индексы на все поля, то еще медленнее выполняетсяЯ имел в виду совсем без индекса, даже без по отдельным полям. Все равно же выполняется сканирование всего индекса. А сканировать индекс или таблицу - разница уже невелика, если, конечно, в таблице еще не 100500 полей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 15:51:17 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
miksoft, еще +35 :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 15:55:23 |
|
||
|
Выборка из большой таблицы по большому количеству полей
|
|||
|---|---|---|---|
|
#18+
Данилкоmiksoft, еще +35 :)Еще 35 полей? Тогда, вероятно, исходный индекс имеет смысл оставить. Еще хорошо бы убедиться, что innodb_buffer_pool_size достаточен, чтобы в него влезли все используемые таблицы и их индексы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2014, 15:59:46 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38721276&tid=1834360]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
81ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 196ms |
| total: | 345ms |

| 0 / 0 |
