| |
|
|
| | В логе о медленных запросах, у меня есть очень странные строчки в стиле
# Time: 070809 13:19:26
# User@Host: muzx_e78[muzx_e78] @ localhost []
# Query_time: 2 Lock_time: 0 Rows_sent: 0 Rows_examined: 0
UPDATE e107_mcom SET mcom_recip_read='1' WHERE mcom_recip_read='0' AND mcom_cs LIKE '%.1';
# Time: 070809 13:19:32
# User@Host: muzx_e78[muzx_e78] @ localhost []
# Query_time: 2 Lock_time: 0 Rows_sent: 0 Rows_examined: 0
DELETE FROM e107_mcom WHERE mcom_sender_hide='1' AND mcom_recip_hide='1';
|
Ладно что первый запрос например берёт 2 секунды, пугает то что в нём написанно Rows_examined: 0 и как при этом он вообще какое то время работы занял? А второй запрос тоже уж никак 2 секунды длиться не должен..
Кто нибудь знает в чём может быть проблема? | |
| |
|
|
| |
|
|
| |
для: offline15
(09.08.2007 в 14:32)
| | | >пугает то что в нём написанно Rows_examined: 0 и как при этом он вообще какое то время
>работы занял?
Долго искал соответствие перебирая строку за строкой - отсюда и время.
>А второй запрос тоже уж никак 2 секунды длиться не должен..
Этот запрос скорее всего ждал окончания предыдущего. Можно попробовать использовать либо отложенные запросы, либо предварительно искать SELECT-ом имеются ли записи в таблице для обновления и удаления. Если индексов и таких запросов (которые на самом деле ничего не делают) много это может дать эффект ускорения, хотя на первый взгляд работы будет выполнятся много. | |
| |
|
|
| |
|
|
| |
для: cheops
(09.08.2007 в 16:40)
| | | А разве перебирая строку строку оно не должно было написать что мол перебрало там 100 тыщ строк, но ничего не нашло? Или это только при запросе select? Я знаю что при select если что то найдёт то увеличивается Rows_sent и заодно Rows_examined пишется сколько проверило.. Ещё есть мысль что не перебирало если есть индексы на это, ну тут то как раз вряд ли есть индекс, правда не знаю как проверить. | |
| |
|
|
