SELECT p.*, COUNT(*) as c_count FROM pages p LEFT JOIN comments c ON c.el_id=p.id GROUP BY p.id
SUM + GROUP BY
Те же грабли /ru/forum/876967
Вам же один раз говорили, что эти функции и конструкции используют для смещения один байт, тогда как UTF-8 это многобайтовая кодировка. Вынужден констатировать что вы так ничего и не усвоили и прошлой темы.
Наверное через str_split. Автор видимо забыл что это однобайтовая функция.
Символы замены нужно кодировать в UTF-8. Также смотреть какие символы таким образом заменяются и сравнить их байты.
PRIMARY KEY + KEY `keyword_id`
SELECT item_id FROM table WHERE keyword_id = ID
не просто используется, а еще является покрывающем. Другой вопрос, что есть другой ключ - первичный + короче, такой же структуры и mysql явно предпочтет его.
SELECT item_id FROM table WHERE keyword_id = ID ORDER BY ctr
Index (Primay key) + filesort
Возможно. За то по скорости в запросе SELECT item_id WHERE keyword_id=ID выигрывает PRIMARY KEY. И смею предположить что даже с добавлением ORDER BY использования этого индекса будет быстрее простого.
А чего он должен перекидывать, если там проверяется REQUEST_URI? Единственная возможность это проверять HTTP_HOST через RewriteCond, но если вы говорите что не работает - значит никак.
Зачем? Если там уже и так есть два индекса по этому полю. Как раз если смотреть на этот запрос, то здесь нужен составной индекс для WHERE и ORDER.
Шифровать прямую ссылку надо на стороне сервера а не клиента - толку от этого мало.
kalim, вам уже сказали в чем ваша проблема - локалхост. Переведите тесты на рабочий сервер и тогда можно будет говорить.
