Индексы у тебя один ужаснее другого
Тут надо тебе понимать что так просто в один день одним советом не получится стать профи.
На вопрос нельзя ответить в формате форума.
Могу только посоветовать узнать про индексы
Узнай что такое Btree.
Составной индекс.
Покрывающий индекс.
В таком порядке
Почитай потом приходи.
Не, ну я понимаю что блондинка, но мозги еще есть. Я просто примеров КОНКРЕТНЫХ не видела в сети, все те, что или непонятно написаны, или мне не подходят.
удалено..
Замечательно ускорилось, так и оставьте. Что тут ещё сказать. (до редактирования было приведено время выполнения explain)
(Добавление)
Аллилуйя, explain. И даже понятно какой субд, хоть это так и назвали.
Покажите индексы. Впрочем план адекватный, на порядок производительность уже не улучшить будет.
Я ничего не делала, только запрос ввела в пых-админ с добавлением эксплан вначале и всё.
А как индексы увидеть именно для этой связки?
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE s ref snatch,downloaded,finished,mulct finished 1 const 187 Using index condition; Using where
1 SIMPLE u eq_ref PRIMARY,user PRIMARY 4 amegahd.s.userid 1 Using index condition
1 SIMPLE t eq_ref PRIMARY,id PRIMARY 4 amegahd.s.torrent 1
Если конечно это то, что я поняла.
вот скриншот из пых-админа, там запрос ввела:
это в секундах время запроса.
запрос 49 сделан за 0.0070509910583496 секунды времени сервера. И он у меня показывается как "НЕ оптимизированный, требуется оптимизация, ибо слишком большое время исполнения запроса".
[49]=> 0.0070509910583496 [SELECT s.id AS ids, s.torrent AS tid, t.name AS tname, t.free AS free, s.uploaded AS uploaded, s.downloaded, s.userid AS userid, u.username, u.class, u.uploaded AS upload, UNIX_TIMESTAMP()- UNIX_TIMESTAMP(s.last_action) AS last_action, s.seed_time AS st, s.mulct AS ls, u.enabled, s.finished FROM snatched AS s INNER JOIN users AS u ON u.id = s.userid INNER JOIN torrents AS t ON t.id = s.torrent WHERE s.finished ='yes' AND s.mulct ='no' AND s.downloaded > 0]
[50]=> 0.0018861293792725 [SELECT s.id AS ids, s.torrent AS tid, t.name AS tname, t.free AS free, s.uploaded AS uploaded, s.downloaded, s.userid AS userid, u.username, u.class, u.uploaded AS upload, UNIX_TIMESTAMP()- UNIX_TIMESTAMP(s.last_action) AS last_action, s.seed_time AS st, s.mulct AS ls, u.enabled, s.finished FROM snatched AS s INNER JOIN users AS u ON u.id = s.userid INNER JOIN torrents AS t ON t.id = s.torrent WHERE s.finished ='no' AND s.seeder ='no' AND s.mulct ='no' AND s.downloaded >0]
Но хотелось бы, если возможно, на более шустрый вариант перевести.
Есть запрос, который сильно много берет по времени - тяжелый. Вроде и правильно прописан, но хотелось бы немного модернизивать. Есть куда его улучшать?
время срабатывания:
[56] => 0.011683940887451
SELECT s.id AS ids, s.torrent AS tid, t.name AS tname, t.free AS free, s.uploaded AS uploaded, s.downloaded, s.userid AS userid, u.username, u.class, u.uploaded AS upload, UNIX_TIMESTAMP()- UNIX_TIMESTAMP(s.last_action) AS last_action, s.seed_time AS st, s.mulct AS ls, u.enabled, s.finished FROM snatched AS s INNER JOIN users AS u ON u.id = s.userid
INNER JOIN torrents AS t ON t.id = s.torrent WHERE s.finished ='yes' AND s.mulct ='no' AND s.downloaded >0 AND u.enabled ='yes' ORDER BY userid
ищет по таблице юзверов(~1000) и взятых файлов (файлов ~1500). Эти две таблицы связаны по ID юзера, то-есть users.id = snatched.userid. Сортировку по userid если убрать, запрос будет еще больше времени обрабатываться, LEFT JOIN еще больше время показывает.
Lolya, код из последнего вашего поста как-то связан с вашим вопросом? Я лично не смог разглядеть работу с константами...
Да, я страницу юзера на две разделила, так меньше запросов бьет. В табах информация о юзере пишется, под ИД=***
То-есть, связка страниц по ИД идет, ну и по ссылке что в коде. Так вот, если ссылку открыть так: details_id.php?id=4&info=info2
то покажется информация о юзере с ИД=4, которая должна подгружаться именно на странице details.php. Вот и хотелось этим кодом закрыть просмотр тем, кто хочет посмотреть минуя основную страницу.
<script type="text/javascript">var lang_click_here='нажмите сюда';$(function(){$("#tabs").tabs({ajaxOptions:{error: function(xhr, status, index, anchor){$(anchor.hash).html("Не удалось загрузить эту вкладку. Мы постараемся исправить как можно скорее.");}},collapsible:true, cache:true, fx:{opacity:'toggle'}});});</script>
Есть такая функция, позволяющая связать два файла вместе, если открыть другой, то выбьет ошибку. Это в теории. На практике у меня почему-то все время ошибка выскакивает. Что не так я делаю?
Два файла у меня, один главный - userdetails.php
второй, который подтягивается через главный - user_details.php
Соответственно я ставлю в файле userdetails.php код:
Всё, вопрос решен. Чуть раньше в коде была ошибка, которая заставляла обходить стороной первый запрос, или сверху переписывать.. не важно, вопрос решен. Тему можно закрыть. Спасибо.
вам нужно один раз или все время эту операцию делать? Потому что, если один раз, то я вчера такую тему создала и мне ответили с верным решением.
Если много-разовое у вас "вписывание", то надо брать данные из самого поста и вписывать их в новую и старую таблицу, если вы хотите чтобы и там и там были эти данные.
Не выйдет, это анонс.пых файл, там такое не пройдет к сожалению.
Мускуль работает и будет дальше работать в виде мискль. Не у всех есть версии скрипта под пых-7, многие еще на пых-5.4 сидят. Вот именно под них и пишется скрипт. Но блин ошибочка за каким-то лешим выходит.
Запрос на удаление (второй) - срабатывает! А вот запрос об изменении данных в таблице snatched (первый) - не хочет. Я не пойму - где ошибка??? Сам запрос:
Делаю запрос обновления данными из одной таблицы в другую. Что не так, почему ошибку бьет?
Заранее спасибо за помощь.
Таблица peers имеет те-же данные что и snatched, а именно:
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 69
