Как разбить выполняемую работу на удобоваримые сервером куски? - страница 3 - Разработка расширений для Joomla

А дальше, зная это время, можете рассчитать примерно, сколько запросов выполнится в течении 1 сек, либо сколько строк лучше брать из базы, что бы уложиться в период менее 1 сек

Всем доброго утра! Продолжаю:скриншот прикладываю. Пошел читать, что это означает

Почитал, пока мало что понял

SELECT 
  `file_title`,
  `file_url`,
  `published`,
  `virtuemart_media_id`
FROM `#__virtuemart_medias`
WHERE `file_type` = 'product'
AND `virtuemart_media_id` NOT IN (SELECT `virtuemart_media_id` FROM `#__virtuemart_product_medias`)

Было бы интересно узнать, сколько будет выполняться это:

Код: sql

SELECT 
  `file_title`,
  `file_url`,
  `published`,
  `virtuemart_media_id`
FROM `#__virtuemart_medias`
WHERE `file_type` = 'product'
AND `virtuemart_media_id` NOT IN (SELECT `virtuemart_media_id` FROM `#__virtuemart_product_medias`)

Если оперативки гига 2 имеется (а кстати, сколько у Вас её?)

root@server:~# free
             total       used       free     shared    buffers     cached
Mem:       1048576     592860     455716          0          0     129332
-/+ buffers/cache:     463528     585048
Swap:       524288      49180     475108

1 сек. взял от балды, т.к. вам нужно, что бы прогресс-бар двигался. Можно и 2 сек поставить, и 5.

Дело в том, чтобы отрисовывать прогресс бар, надо сначала знать, сколько строк всего вернётся. При такой тяжести получения ответа на вышеприведенный sql-запрос предварительно запрашивать, сколько всего записей вернётся, станет удручающей ситуацией для пользователя. Сначала 1,5 минуты ожидает ответа о том, сколько всего, а потом каждые 90сек/130шт секунд он будет получать данные по новому файлу, которые он потом будет галочками отмечать на удаление. Итого 1,5+1,5=3 минуты... Наверно от бара придется отказаться.

Вопрос. Как все полученные строки представить в формате с пагинацией и устроить навигацию без перезагрузки страницы? Или без разницы для браузера, можно все тысячу, к примеру, строк пустить вертикально вниз и он не зависнет?

Для этого запросите у базы общее количество строк, которые предстоит перелопатить

Так вот это действие займёт 1,5 минуты, как я понимаю на моём сервере.

SELECT COUNT(*) 
FROM `#__virtuemart_medias`
WHERE `file_type` = 'product'
AND `virtuemart_media_id` NOT IN (SELECT `virtuemart_media_id` FROM `#__virtuemart_product_medias`)

SELECT 
  `file_title`,
  `file_url`,
  `published`,
  `virtuemart_media_id`
FROM `#__virtuemart_medias`

Поэтому вы и работаете с LIMIT и в параметрах указываете, что выбирать не всю базу, а только с Х по У.

Точно не отследил, но результаты запроса с COUNT(*) вернулись не ранее чем через 30 сек.

С хостингом или настройками сервера у вас явно что-то не так: ваш запрос должен срабатыватъ за доли секунды.

А если запрос не в phpMyAdmin делать, а в консоли?

mysql> SELECT COUNT( * )
    -> FROM  `ytgb1_virtuemart_medias`
    -> WHERE  `file_type` =  'product'
    -> AND  `virtuemart_media_id` NOT
    -> IN (
    ->
    -> SELECT  `virtuemart_media_id`
    -> FROM  `ytgb1_virtuemart_product_medias`
    -> );
+------------+
| COUNT( * ) |
+------------+
|        130 |
+------------+
1 row in set (1 min 5.04 sec)

select `file_title`,`file_url`,`published`,m.virtuemart_media_id
from ytgb1_virtuemart_medias m
left JOIN ytgb1_virtuemart_product_medias pm 
	ON pm.virtuemart_media_id = m.virtuemart_media_id
where pm.virtuemart_media_id IS NULL
	AND file_type = 'product'

130 rows in set (1 min 21.33 sec)

Хм, а без JOIN?

select `file_title`,`file_url`,`published`,m.virtuemart_media_id
from ytgb1_virtuemart_medias m
where 
	file_type = 'product'

22659 rows in set (0.12 sec)

mysql> SELECT COUNT(*)
    -> FROM ytgb1_virtuemart_medias m
    -> LEFT JOIN ytgb1_virtuemart_product_medias pm
    -> ON pm.virtuemart_media_id = m.virtuemart_media_id
    -> WHERE pm.virtuemart_media_id IS NULL
    -> AND file_type = 'product';
+----------+
| COUNT(*) |
+----------+
|      130 |
+----------+
1 row in set (1 min 10.44 sec)

у вас количество строк в выборке - почти 100% от общего количества строк в таблице. согласно документации MySQL не будет использовать в таком случае индексы, будет полный скан таблицы. что у вас и происходит. исходя из этого - никаких left join

похоже, что не для этого VPS

character-set-server = utf8 
collation-server = utf8_general_ci 
character_set_server = utf8 
collation_server = utf8_general_ci 
init-connect = 'SET NAMES utf8'

key_buffer_size = 250M

innodb_buffer_pool_size = 650M
innodb_log_file_size = 64M
innodb_log_buffer_size = 4M
innodb_flush_log_at_trx_commit = 0
innodb_thread_concurrency = 8
innodb_flush_method = O_DIRECT
innodb_file_per_table

table_cache=512

query_cache_type = 1
query_cache_limit = 1M
query_cache_min_res_unit = 2k
query_cache_size = 80M

Какая разница?

огромная

согласно документации MySQL не будет использовать в таком случае индексы

вы сначала попробуйте, а потом рассуждайте. даю 99% что 2 запроса и перебор с проверкой будут менее 1 секунды. только проверка не in_array, это будет медленно, а isset. т.е. второй массив надо выгрузить с ключами = virtuemart_media_id