| Цитата |
| Это только костыль, данные часто меняются |
Дополню. Это называется
введение избыточности.
Zzepish
1.03.2016 - 14:19
Serg86
Ты переименовывал поля\таблицы?
Zzepish
1.03.2016 - 14:24
Zzepish
1.03.2016 - 14:34
Хотя я вообще не вижу проблемы. Выпилил индексы - результат тот-же
Zzepish
1.03.2016 - 14:40
Да. Первый запрос идет долго (1.5 секунд). Последующие - 0.0005
| Цитата |
| Да. Первый запрос идет долго (1.5 секунд). Последующие - 0.0005 |
Это эффект чтения таблицы с диска в буфер. Если таблица часто обновляется и запросов одинаковых много с разными переменными то не спасет, они вытесняются
| Цитата |
| Дополню. Это называется введение избыточности. |
Да сразу уже на мануал мускула кидайте. Есть конкретная проблема с сартировкой после выборки которая в разы увеличивает время отдачи, предложите решение если таковое имеется. А забить в гугле почему не работают индексы я и сам могу. (Не хотел грубить, вырвалось)
Zzepish
1.03.2016 - 14:51
Сейчас эксперементирую с типами бд. Кстати - полю id добавь primary key
Zzepish
1.03.2016 - 14:53
Смени таблицу на MyISAM. Скорость увеличилась в 5 раз
Zzepish
1.03.2016 - 15:01
Ну как там?
| Цитата |
| Смени таблицу на MyISAM. Скорость увеличилась в 5 раз |
Думал над этим, но думаю что это не решение проблемы в данном случае. По таблице не только этот запрос работае, а изменения могут повлеч кучу последствий от которых икать буду не один день.
Zzepish
1.03.2016 - 15:05
Serg86
Если у тебя в базе такая-же структура, как ты мне скинул (без индексов и т.д.) то нифига не повлечет
| Цитата |
| (Не хотел грубить, вырвалось) |
Ты просто не замечаешь советы )
1. Создай отдельную таблицу для полнотекстового поиска по полю catfull и внешний ключ для связки с таблицей site_db
2. Добавь составной индекс в таблицу site_db: status, raised, date_add
3. Используй match against с использованием JOIN
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.