EXPLAIN-ы как бы одинаковые.
Только я хз, почему
в первой таблице "const 1 Using temporary"
То есть выбирается по индексу 1 строка, но используются временные таблицы :)
Можно запрос переписать так:
SELECT P.ID FROM wp_posts P JOIN wp_term_relationships R ON (R.object_id = P.ID) JOIN wp_term_taxonomy T ON (T.term_taxonomy_id = R.term_taxonomy_id AND T.term_id = 685) WHERE 1 AND P.post_status = 'publish' AND P.post_type = 'post' AND P.post_date < NOW() GROUP BY P.ID
Mysql c какой-то версии имеет тип поля JSON.
То есть можно фильтровать более менее нативно.
Но вот индексов по нему не построить :)
Может все же JOIN-нить несколько таблиц?
Это самописный запрос или CMS его сама генерирует?
SELECT DISTINCT P.ID FROM wp_posts P JOIN wp_term_relationships R ON (R.object_id = P.ID) JOIN wp_term_taxonomy T ON (T.term_taxonomy_id = R.term_taxonomy_id AND T.term_id = 685) WHERE 1 AND P.post_status = 'publish' AND P.post_type = 'post' AND P.post_date < NOW()
Какой EXPLAIN у Вашего и моего запроса?
1. Запрос не полный
2. SHOW PROCESSLIST в Mysql вряд ли адекватный :)
3. Вы отключили временные таблицы в памяти, они будут создаваться сразу на диске.
4. EXPLAIN в студию
Так запросы не пишут!
Тут может быть полное объединение таблиц :)
Нужно использовать JOIN:
FROM wp_posts P JOIN wp_term_relationships R ON (R.some_field = P.some_field) JOIN wp_term_taxonomy T ON (T.some_field = R.some_field)
Если помогло, то ок. :)
У самого часто висят запросы с такой информацией в SHOW PROCESSLIST.
Дивно, что отключение временные таблиц в памяти решило проблему. :)
Блокировка сессий в php скорее всего...
Изучайте:
X-Accel-Redirect
session_write_close()
+1.
Только рынок труда диктует другое. :)
Все вакансии требуют знания фреймворков и паттернов. :)
Хотя, когда приходишь на проект, - говнокод говнокодом.
Рынок труда захватили модники. :)
Сам проходил через ООП головного мозга в начале карьеры.
Везде говорилось, что кто не пишет на ООП, тот лох. :)
А вдруг это не одиночка, а другой шаблон?
Декоратор, допустим.
Одиночка используется, если необходимо обеспечить наличие одного экземпляра или ленивую инициализацию.
Может также использоваться пул одиночек.---------- Добавлено 05.02.2017 в 12:40 ----------
Как и с любым статическим методом :)
Как эту проблему решают фреймворки? :) У них тоже статики дофига.
Можно передавать параметром. :)
Ну и это отновится к любой статике. :)
А зачем его уничтожать? :)
Если это соединение с БД, то можно просто его закрыть. :)
Хм, одиночку можно реализовать и без статического метода.
Но это будет не совсем одиночка.
Хранить одиночку в поле приложения.
Но необходима гарантия, что существует только один экземпляр приложения.
Хотя, зачем. Если будет другой экземпляр, то ему лучше дать своего одиночку. :)
А как контролировать количество соединений с mysql и memcached? :)---------- Добавлено 05.02.2017 в 12:46 ----------
Одиночка тут ни при чем.
Это называется цепочка вызовов.
Реализуется через return $this.
Хм, а это как-то ускоряет индексацию? :)
Вернее, способствует появлению страниц в выдаче в тот же день?
Хм, как раз в самописи можно настроить все как нужно :)
Вот Вы и сами ниже насоветовали. :)
+1
Правда, есть такое понятие, как слияние индексов.
Ну и не всегда планировщик выбирает оптимальный индекс.
Это не так. :)
Что это за такая теория? :)
Даже в относительно маленькой таблице (2 ГБ) инсерты начинают тупить при добавлении каждого дополнительного индекса.---------- Добавлено 25.01.2017 в 09:59 ----------
Сколько записей в таблице?
Если записей мало, то планировщик может решить, что быстрее считать таблицу, чем копаться в индексах. :)
Смотрите, короче, EXPLAIN самых частых запросов.
Товары, я так понял, все однотипные?
Характеристики однотипных товаров можно хранить в одной таблице.
Характеристики же разнотипных товаров нужно выносить в отделюную таблицу.
А также почитайте о таком понятии, как cardinality индекса.
Если поле принимает только 2 значения, то индекс ставить на него смысла нету.
Индексы нужно ставить на поля, по которым происходят JOIN.
