Эт я уже про другой запрос. тот слишком огромный для моих небольших мозгов. Вот эксплейн пишет в первой строчке:
1 SIMPLE c const PRIMARY PRIMARY 4 const 1 Using temporary; Using filesort
сам запрос-
SELECT p.stars, COUNT(DISTINCT p.id_product) nbr , m.name, psi.price_min, psi.price_max, avb.name as avbname FROM ps_product p INNER JOIN ps_product_shop product_shop
ON (product_shop.id_product = p.id_product AND product_shop.id_shop = 1)
INNER JOIN ps_category_product cp ON (cp.id_product = p.id_product)
INNER JOIN ps_category c ON (c.id_category = cp.id_category AND
c.id_category = 759
AND c.active = 1) LEFT JOIN `ps_stock_available` sa
ON (sa.id_product = p.id_product AND sa.id_shop = 1) LEFT JOIN `ps_manufacturer` m ON (m.id_manufacturer = p.id_manufacturer)
INNER JOIN `ps_layered_price_index` psi
ON (psi.id_product = p.id_product AND psi.id_currency = 1 AND psi.id_shop=1) LEFT JOIN `ps_availability` avb ON (avb.id_availability = p.id_availability)
WHERE p.`active` = 1 AND p.`visibility` IN ("both", "catalog")
GROUP BY p.stars ORDER BY p.stars DESC;
таблица :
CREATE TABLE IF NOT EXISTS `ps_category_product` (
`id_category` int(10) unsigned NOT NULL,
`id_product` int(10) unsigned NOT NULL,
`position` int(10) unsigned NOT NULL DEFAULT '0',
KEY `id_product` (`id_product`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
вот я и не понимаю. эта "с" она же ps_category_product . в ней всего 1600 записей, в ней есть первичный ключ и он используется. Так ПОЧЕМУ я имею для этого простого запроса "Using temporary; Using filesort"
Андрей: в случае использования JS вы вообще не трогаете серверный код.
Ну, или (если решите делать изменения на сервере) редактируете ту его часть , которая формирует список ссылок.
просто общая идея , например на JS (jquery)
$( "a" ).each(function() // перебираем все ссылки на странице
{
var my_href = $( this ).attr( "href" ); // это текст ссылки
далее вы определяете какое там расширение в конце, модифицируете ее ...
например, добавляете нужный класс :
$( this ).addClass( "pdf" );
Спасибо за ответ! Вот здесь и хочу разобраться. Я думал у нас создается нечто вроде хэша по двум столбцам, а следовательно этот общий хэш для поиска по одному из друх столбцов входящих в него не может быть полезным.
Значит если мы ищем id_product - индекс id_product & id_shop нам подходит. А если бы мы например искали бы id_shop , то данный индекс на бы не пригодился. И следовало бы использовать либо чистый id_shop индекс , либо тот где id_shop идет первым номером?
А если мы имеем дело не с PRIMARY индексом, а с другим, тоже составным?
а по поводу индексов столбцов участвующих в JOIN. нужен индекс именно по этому столбцу (в данном случае mage_shop.id_image ). составной ведь это не то?
tmpfs ram буду гуглить - спасибо!!!
Я вообще вижу что MySQL активно использует диск при том, что все возможные кэш имеется приличный. Специально увеличил innodb_log_file_size , чтобы меньше на него отвлекаться, а результат пока никакой )
Пума Тайланд: Спасибо за ответы.
Это магазин. К примеру, главная страница. если она будет в кэше, то ведь отдаваться будет моментально, без запросов к БД? Насчет файлового кэша - вроде бы рейтинге систем кэширования файловый был ниже, ибо к нему доступ с диска, а в мемкэшед из памяти . в любом случае, конечно, файловый тоже включал - эффект тот же. Все работает немного медленнее. Кешер опкода не установлен. Это одна из возможных опций в PRESTASHOP, исключающая мемкешед
Затык именно во времени формирования страницы- чуть более секунды : https://dl.dropboxusercontent.com/u/19954007/asks/... (иногда чуть быстрее 0,8 секунды).
А вообще, пожалуй, вы правы. В принципе, после установки и запуска memcached все могло начать "летать", но раз не запустилось , и требуется более серьезная настройка, следует умыть руки и просто читать матчасть.
ясно, что знаний много не бывает. но в данном случае есть готовый сайт на престашоп (написанный более квалифицированными программистами , нежели я). У этого сайта есть готовый инструмент, который ОБЫЧНО приводит к ускорению работы. Сервер не самый паршивый, мягко говоря. Нагрузка по идее, не убийственная, это не амазон ком. Я просто пытаюсь воспользоваться готовым инструментом.
В идеале помимо PHP, нужно и запросы профилировать и индексы создавать и JS запускать асинхронно и картинки собирать в спрайты и CSS собирать в кучу и GZIPить контент можно заранее и NGINX настроить для отдачи статики (а можно и вовсе выкинуть апач). Очень много всего можно сделать.
Но я пытаюсь рассуждать логично. Понимаю, что в полном объеме все перечисленное сейчас сделать я не смогу. "Мопед" не мой , это процесс - на годы обучения. А я вчера впервые копировал/правил логи/смотрел статистику на сервере через ssh. Жуть!))
Пока я просто ужал в 10 раз огроменные картинки, убедил выключить сторонние модули которые по 2 секунды грузили свои ресурсы, произвел простейшую настройку MYSQL по статье c хабра. Главная страница стала в 2,5 раза меньше, грузится все в 3 раза быстрее, НО сам процесс ожидания ответа от сервера в случае с главной и другими страницами от 0,9 до 2,8 секунд. Если вся эта петрушка будет кэшироваться - скорость отдачи увеличится и цель будет достигнута.
Пума Тайланд: я думал достаточно подключить эту штуку и немного настроить конфиги в соответствии с рекомендациям. А как еще можно кэшировать полностью?
1 SIMPLE c const PRIMARY PRIMARY 4 const 1 Using temporary; Using filesort
сам запрос-
SELECT p.stars, COUNT(DISTINCT p.id_product) nbr , m.name, psi.price_min, psi.price_max, avb.name as avbname FROM ps_product p INNER JOIN ps_product_shop product_shop
ON (product_shop.id_product = p.id_product AND product_shop.id_shop = 1)
INNER JOIN ps_category_product cp ON (cp.id_product = p.id_product)
INNER JOIN ps_category c ON (c.id_category = cp.id_category AND
c.id_category = 759
AND c.active = 1) LEFT JOIN `ps_stock_available` sa
ON (sa.id_product = p.id_product AND sa.id_shop = 1) LEFT JOIN `ps_manufacturer` m ON (m.id_manufacturer = p.id_manufacturer)
INNER JOIN `ps_layered_price_index` psi
ON (psi.id_product = p.id_product AND psi.id_currency = 1 AND psi.id_shop=1) LEFT JOIN `ps_availability` avb ON (avb.id_availability = p.id_availability)
WHERE p.`active` = 1 AND p.`visibility` IN ("both", "catalog")
GROUP BY p.stars ORDER BY p.stars DESC;
таблица :
CREATE TABLE IF NOT EXISTS `ps_category_product` (
`id_category` int(10) unsigned NOT NULL,
`id_product` int(10) unsigned NOT NULL,
`position` int(10) unsigned NOT NULL DEFAULT '0',
KEY `id_product` (`id_product`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
вот я и не понимаю. эта "с" она же ps_category_product . в ней всего 1600 записей, в ней есть первичный ключ и он используется. Так ПОЧЕМУ я имею для этого простого запроса "Using temporary; Using filesort"