есть запрос который работает очень медленно...
нужно его ускорить
вот запрос который выполняется 30 секунд
UPDATE `userlist` SET `status` = 'tested', `limit` = '0' WHERE `status` = 'works' AND (SELECT COUNT(*) FROM `visitors` WHERE `where` = `userlist`.`url` AND DATE(datetime) = ADDDATE(DATE(NOW()),-1) LIMIT 0 , 3) < 3
написал вот такой запрос упростив, но запускать боюсь
правильно ли я сделал или можно как то подругому еще сделать???
UPDATE `userlist` AS `u`
LEFT JOIN (
SELECT `where`, COUNT(*) AS `count`
FROM `visitors`
WHERE DATE(`datetime`) = ADDDATE(DATE(NOW()), -1)
GROUP BY `where`
ORDER BY NULL
) AS `v` ON `u`.`url` = `v`.`where`
SET `u`.`status` = 'tested', `u`.`limit` = '0'
WHERE `u`.`status` = 'works' AND IFNULL(`v`.`count`, 0) < 3
может есть другие варианты
база растет и все медленнее и медленнее работает...
:(
Спустя 13 минут, 8 секунд (16.03.2011 - 01:18) Oyeme написал(а):
1.Проиндексировать все поля,по которым идёт поиск.(Кеширование)
2.Типы полей проверить.
3.Используй count(id) где id - колонка в таблице,при count(*)ты подсчитываешьвсе все поля которые находятся в таблице.
2.Типы полей проверить.
3.Используй count(id) где id - колонка в таблице,при count(*)ты подсчитываешьвсе все поля которые находятся в таблице.
Спустя 5 минут, 52 секунды (16.03.2011 - 01:24) imbalance_hero написал(а):
Oyeme
ты не прав, основное заблуждение про COUNT(`id`), стоит почитать тебе про это. Надо COUNT(*).
lrlr
Может 2 отдельных запроса? Один UPDATE, второй SELECT?
ты не прав, основное заблуждение про COUNT(`id`), стоит почитать тебе про это. Надо COUNT(*).
lrlr
Может 2 отдельных запроса? Один UPDATE, второй SELECT?
Спустя 4 минуты, 16 секунд (16.03.2011 - 01:29) lrlr написал(а):
нет в том то и дело...
нужен именно один, а как по вашему 2 то тут получится.
есть только один вариант как то объединить таблицы в одну и то это фантастика
короче блин если бы в блокноте делал то и то быстрее работало чем этот скюрл корявый
похоже его писали косо типа цикла в цикле, если это так то блокнот намного быстрее бы пахал, это конечно ппц
нужен именно один, а как по вашему 2 то тут получится.
есть только один вариант как то объединить таблицы в одну и то это фантастика
короче блин если бы в блокноте делал то и то быстрее работало чем этот скюрл корявый
похоже его писали косо типа цикла в цикле, если это так то блокнот намного быстрее бы пахал, это конечно ппц
Спустя 3 минуты, 7 секунд (16.03.2011 - 01:32) Oyeme написал(а):
imbalance_hero
Сравним 2 запроса:
SELECT COUNT(*) FROM message WHERE user_id = $user_id
и
SELECT COUNT(id) FROM message WHERE user_id = $user_id
Для выполнения первого запроса нам достаточно просто пробежаться по
индексу user_id и подсчитать кол-во записей, удовлетворяющих условию -
такая операция достаточно быстрая, т.к., во-первых, индексы у нас
упорядочены и ,во-вторых, часто находятся в буфере.
Для выполнения второго запроса мы сначала проходим по индексу, для
отбора записей удовлетворяющих условию, после чего если запись
попадает под условие, то вытаскиваем ее (запись скорее всего будет на
диске) чтобы получить значение id и только потом инкриментим счетчик.
В итоге получаем, что при большом кол-ве записей скорость первого
запроса будет выше в разы.lrlr
Сравним 2 запроса:
SELECT COUNT(*) FROM message WHERE user_id = $user_id
и
SELECT COUNT(id) FROM message WHERE user_id = $user_id
Для выполнения первого запроса нам достаточно просто пробежаться по
индексу user_id и подсчитать кол-во записей, удовлетворяющих условию -
такая операция достаточно быстрая, т.к., во-первых, индексы у нас
упорядочены и ,во-вторых, часто находятся в буфере.
Для выполнения второго запроса мы сначала проходим по индексу, для
отбора записей удовлетворяющих условию, после чего если запись
попадает под условие, то вытаскиваем ее (запись скорее всего будет на
диске) чтобы получить значение id и только потом инкриментим счетчик.
В итоге получаем, что при большом кол-ве записей скорость первого
запроса будет выше в разы.lrlr
Спустя 7 минут, 53 секунды (16.03.2011 - 01:40) lrlr написал(а):
Oyeme
это все классно, но и я не дурак
методы ускорения не эффектывны
раньше запрос работал 40 сек
я его похожим способом уже упрощал
он заработал со скоростью 5 сек
но база выросла и опять 40
это не эффективно,каждый раз находить чтото что упростить и в итоге все нахрен выкинуть...
это все классно, но и я не дурак
методы ускорения не эффектывны
раньше запрос работал 40 сек
я его похожим способом уже упрощал
он заработал со скоростью 5 сек
но база выросла и опять 40
это не эффективно,каждый раз находить чтото что упростить и в итоге все нахрен выкинуть...
Спустя 7 минут, 34 секунды (16.03.2011 - 01:47) Trianon написал(а):
это самое v.url - не уникальное поле?
какие индексы на полях созданы?
Вообще, как так получилось, что таблицы связаны полем, шириной, очевидно, в не один десяток байт?
какие индексы на полях созданы?
Вообще, как так получилось, что таблицы связаны полем, шириной, очевидно, в не один десяток байт?
Спустя 3 минуты, 37 секунд (16.03.2011 - 01:51) lrlr написал(а):
индексов нет вообще
может один и есть уникальный id но он тут нафиг нужен
может один и есть уникальный id но он тут нафиг нужен
Спустя 2 минуты, 33 секунды (16.03.2011 - 01:53) imbalance_hero написал(а):
Oyeme
1. Сравнивал, так вот COUNT(*) быстрее!
2. Почитай в инете про оптимизацию поиска. Везде одно и то же написано. Не могу ссылку найти ,видимо в избранное не занёс, зайти в гугл и поищи сам!
1. Сравнивал, так вот COUNT(*) быстрее!
2. Почитай в инете про оптимизацию поиска. Везде одно и то же написано. Не могу ссылку найти ,видимо в избранное не занёс, зайти в гугл и поищи сам!
Спустя 1 минута, 36 секунд (16.03.2011 - 01:55) Trianon написал(а):
url/where, как сущность, просится в отдельную таблицу.
Спустя 36 минут, 20 секунд (16.03.2011 - 02:31) lrlr написал(а):
итак...
второй запрос набрался смелости и проверил
мозг не подвел
он работает и время его выполнения 0.1 сек
напомню что первый выполнялся 30-40 сек
но вот на счет того правильно ли он в базе все обновил понять не могу потому что слишком большая база
нужен ответ на вопрос правильно ли я составил второй запрос?
прошу потратить свое время всем кто хорошо знает данную тему, потому как вопрос не детский...
второй запрос набрался смелости и проверил
мозг не подвел
он работает и время его выполнения 0.1 сек
напомню что первый выполнялся 30-40 сек
но вот на счет того правильно ли он в базе все обновил понять не могу потому что слишком большая база
нужен ответ на вопрос правильно ли я составил второй запрос?
прошу потратить свое время всем кто хорошо знает данную тему, потому как вопрос не детский...
Спустя 35 минут, 45 секунд (16.03.2011 - 03:07) Trianon написал(а):
похоже.
Спустя 5 часов, 28 минут, 57 секунд (16.03.2011 - 08:36) Семён написал(а):
Если вы спорите что быстрее COUNT(*) или COUNT(primary_key), смею огорчить COUNT(1) ещё быстрее 
А тормоза будут ещё больше изза GROUP By в запросе (это касается 2-ого запроса))
Для тестов приведи хотябы EXPLAIN запроса...
А тормоза будут ещё больше изза GROUP By в запросе (это касается 2-ого запроса))
Для тестов приведи хотябы EXPLAIN запроса...
Спустя 1 час, 20 минут, 52 секунды (16.03.2011 - 09:57) VELIK505 написал(а):
всё дедаметодами пользуетесь щас уже нет как такового массивных запросов попробуйте погрузиться поглубже в sqllite и memcached
Спустя 4 минуты, 56 секунд (16.03.2011 - 10:02) Семён написал(а):
VELIK505, просто ляпнул? так чтобы было? причём здесь sqllite? и memcache?!
Спустя 13 минут, 42 секунды (16.03.2011 - 10:15) VELIK505 написал(а):
| Цитата (Семён @ 16.03.2011 - 07:02) |
| VELIK505, просто ляпнул? так чтобы было? причём здесь sqllite? и memcache?! |
Ты тупой видать. Я вел всё к тому что можно обойтись вообще без базы. Или в кеш записывать который sqllit будет выдавать и в memcached записываться.
Ты просто видать не работал над большими высоконагружаемыми проектами. Сначало думай а потом ставь минусы человеку в репутацию.
Спустя 5 минут, 20 секунд (16.03.2011 - 10:21) Семён написал(а):
VELIK505
Тупой не тупой, не твоему синичкину мозгу судить об этом.
Тут речь шла не о SQLlite, и memcache, который предполагает как минимум наличие VPS.
И чтобы вообще не позориться как-то не уместно говорить о SQLlite и highload-e.
Тупой не тупой, не твоему синичкину мозгу судить об этом.
Тут речь шла не о SQLlite, и memcache, который предполагает как минимум наличие VPS.
И чтобы вообще не позориться как-то не уместно говорить о SQLlite и highload-e.
Спустя 1 минута, 55 секунд (16.03.2011 - 10:23) VELIK505 написал(а):
Ты внатуре не сечёшь. Поясняю можно сделать так чтобы вообще база не использоволась!
Чтобы этого запроса тупо не было грубо говоря!
Чтобы этого запроса тупо не было грубо говоря!
Спустя 26 секунд (16.03.2011 - 10:23) inpost написал(а):
| ! |
inpost |
Спустя 2 минуты, 41 секунда (16.03.2011 - 10:26) inpost написал(а):
lrlr
Результат этого запроса кешируй на сервере, и обращайся непосредственно к кешу страницы. Под кешем я позразумеваю создание одной html страницы результата этого действия. Можешь всю страницу в кеш, можешь лишь часть выполненную.
Кеш обновляй раз в небольшой период, нагрузка сразу спадёт с сервера, это будет лучший вариант, чтобы не портить то, что имеем.
Результат этого запроса кешируй на сервере, и обращайся непосредственно к кешу страницы. Под кешем я позразумеваю создание одной html страницы результата этого действия. Можешь всю страницу в кеш, можешь лишь часть выполненную.
Кеш обновляй раз в небольшой период, нагрузка сразу спадёт с сервера, это будет лучший вариант, чтобы не портить то, что имеем.
Спустя 2 минуты, 22 секунды (16.03.2011 - 10:28) VELIK505 написал(а):
Я не когда не ругаюсь первый! Вообще не люблю ругаться!
Семен если есть своё мнение держи его при себе на крайний случай напиши комент но не порти человеку репутацию! Если она у тебя испорчена за то что ты не умеешь общаться с людьми это не значит что должен её портить другим!
Семен если есть своё мнение держи его при себе на крайний случай напиши комент но не порти человеку репутацию! Если она у тебя испорчена за то что ты не умеешь общаться с людьми это не значит что должен её портить другим!
Спустя 1 минута, 23 секунды (16.03.2011 - 10:29) inpost написал(а):
| ! |
inpost |
Спустя 14 минут, 9 секунд (16.03.2011 - 10:44) Семён написал(а):
По теме: автор обязательно расставь индекс, придётся во втором подзапросе заюзать скорее всего USE INDEX (название-индекса), сделай обязательно EXPLAIN и выведи его, помогу с созданием индексов.
VELIK505 - репу занизил справедливо.
- Кто не согласен с тем, что человек нёс чушь на счёт SQLlite и репа занижена несправедливо. аргументируйте.
inpost - а ты не последние китайские предупреждения давай, а наказывай - суд должен быть справедливым, а не предвзятым.
Стоит обратить внимание на ответное понижение репутации с оскорблением в комментариях.
VELIK505 - репу занизил справедливо.
- Кто не согласен с тем, что человек нёс чушь на счёт SQLlite и репа занижена несправедливо. аргументируйте.
inpost - а ты не последние китайские предупреждения давай, а наказывай - суд должен быть справедливым, а не предвзятым.
Стоит обратить внимание на ответное понижение репутации с оскорблением в комментариях.
Спустя 6 минут, 38 секунд (16.03.2011 - 10:50) alex12060 написал(а):
Семён
Зря ты так) Человек пытается помочь, а ты сразу кидаешься на него.
Насчет SQLlite конечно, странно сказанно, но насчет memcashed не плохо, но его целесообразно использовать при большой нагрузке на сервак и большом кол-ве просмотров страницы.
VELIK505
ТС придется перелопатить свою базу полностью тогда, и вдобавок, изучить все это подобное, а это, минимум, месяца так 3.
Вывод, используйте кеширование, индексы в таблицах и все будет работать как часы
Зря ты так) Человек пытается помочь, а ты сразу кидаешься на него.
Насчет SQLlite конечно, странно сказанно, но насчет memcashed не плохо, но его целесообразно использовать при большой нагрузке на сервак и большом кол-ве просмотров страницы.
VELIK505
ТС придется перелопатить свою базу полностью тогда, и вдобавок, изучить все это подобное, а это, минимум, месяца так 3.
Вывод, используйте кеширование, индексы в таблицах и все будет работать как часы
Спустя 7 минут, 11 секунд (16.03.2011 - 10:57) alex12060 написал(а):
Все, разобрались, все пис пасаны