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.
Попахивает тем, что правообладатели просто от лица ТС запугивают сайты, на которых есть трансляции.
На самом деле - это ерунда.
Говорю так, потому что сам работал в такой компании. :)
Ну так скопируй код у мордокниги. :)
