Я в начале лета попробовал поработать в коворкинге - пару раз по несколько часов посидел, затем воодушивившись купил месячный абонемент, и что?.. Как отрезало, кажется два раз ещё пришёл и все. В последний день вечером с женой и ребёнком проходили мимо, вспомнил, что там у меня ещё осталось енное количество сендвичей и кофе в тарифе - зашёл, а мне говорят - сендвичи у нас сегодня закончились :)
Я у них счет как предприниматель открывал, уже через несколько дней после открытия зашёл свифт без проблем.
Если я правильно понял, то эта штука работает не во всех процах, более того для тех процов, где она есть - это стандартная штука для удаленного управления компами, но исследователи нашли как подключаться к процу обходя требования логина/пароля.
А то что нашли - это наоборот, отключение данного функционала.
Dram, задача стала немного яснее, но не до конца. :)
Вам нужно в таблицу раз в месяц заносить количество работников для каждой компании? Почему для компании не сделать счётчик, который обновляется по факту добавления/удаления работника? Это обычный вариант для того, чтобы не юзать ресурсоемкий count.
Dram, этот запрос делается в скрипте через PHP или разово через Mysql (например, через PHPMyAdmin)?
Если первый случай, то здесь проблема в том, что для каждой строки из x55_cl_items подзапрос выполняется отдельно (то есть, условно count(id) будет подсчитываться 1000-и раз, а это уже сам по себе не медленный запрос). Поэтому его лучше выполнить отдельно, а затем уже делать запрос на обновление полей присвоив полученной значение.
Ну и лучше использовать count(*) вместо count(id) - с таким запросом база будет работать быстрее.
индекс по x55_do_working.cl_id
и примари индекс по x55_cl_items.id
Если случай второй - то набросайте php-скрипт, который запускайте, чтобы сделать выше описанное :)
revered, подскажите, чем Вам не подошёл запрос, который описан в ответе Оптимизайка?
Мой совет ниже будет практически на 100% аналогичен:
Сразу оговорюсь, что с Mysql не работал достаточно давно, если не учитывать небольшие пересечения с mysql-подобным синтаксисом в SphinxQL, то наверное, лет 6-7, больше с MongoDB стыкался, ну и последние несколько месяцев часть функционала на PostgreSQL перевели на проекте.
Поэтому может я что-то не то понимаю в задаче. Но из тех запросов, что выше есть, можно сделать вид, что будет достаточно простенького объединения и нескольких индексов.
ALTER TABLE `organization_category` ADD INDEX `organization_id` (`organization_id`);
ALTER TABLE `organization_category` ADD INDEX `category_id_organization` (`category_id`);
ALTER TABLE `organization` ADD INDEX `city_organization` (`city`);
ALTER TABLE `organization` ADD INDEX `com_organization` (`id`,`status`);
Теоретически может понадобится индекс по name.
Ну и предполагается, что у вас уже есть PRIMARY-индекс на `organization`. `id`
SELECT * FROM `organization`, `organization_category` WHERE `organization_category`.`organization_id` = `organization`.`id` AND `organization_category`.`category_id`=90 AND`organization`.`city`=518 AND `organization`.`status`=1 ORDER BY `name` ASC LIMIT 0,20
Четвертый индекс непонятно нужен или нет, но если одобрённых (? `status`=1) очень много, то это может приводить к скану всей таблицы, поэтому уменьшаем количество записей в индексе, которые нам нужно просмотреть через объединённый индекс по `id` и `status`.
`id` мы уже перед этим и так уже получаем в ходе работы запроса
p.s. В Mysql не хватает хорошего аналога EXPLAIN ANALYZE из PostgreSQL, он был бы не лишним.
в чем риски?
У нас в прошлом году перестала откачиваться вода, вызвали мастера, оказалось забилась какая-то трубка, которую сходу видно не было или что-то типа того. В итоге посудомойка ожила за условно небольшие деньги. Поэтому диагностика не будет лишней.
тут не та ситуация, когда в t2 очень много значений с текущим t1.object_id?
в точку! Я читаю на 175%, иначе все мелкое на 27" монике. :)
