Макс

существует. посмотрите Стахановец, как вариант. ну или тут
писать видео дело безперспективное. 100 компов - 900 часов видео ежедневно. Даже абстрагировавшись от размера - чтобы просмотреть это видео с 10-и кратной скоростью Вам потребуется 90начальнико-часов в ДЕНЬ.
Или 10 начальников, которые будут только и делать, что смотреть видео.

в нормальных БД аудит действий есть и так- и его только надо настроить.
в остальных можно повесить тригггер. Или разрешить работу только через процедуры, в которых реализовать протоколирование.

вероятнее всего косяк в бродкастах. Сделайте маску /23 - все станет одной подсетью.

идентифицируйте по куки. в БД пишите ID из куки, datetime голоса. при формировании страницы проверяйте, был ли уже сегодня голос от этого ID.

сразу отмечу - это защита "от пионеров". куки лежат на стороне клиента, ничто не мешает ему их стереть. Более надежно авторизация.

[OK] Query cache efficiency: 29.6% (17M cached / 57M selects)
[!!] Query cache prunes per day: 91403

- на вскидку. кеш запросов не эффективен. Наверное много апдейтов в таблицах.
в кеш попадает всего 29,6% запросов, а вот очисток кеша за день 91К.

ну и индексы - каждый третий запрос без индекса.
всего Query cache efficiency: 29.6% (17M cached / 57M selects) - 57 млн запросов
из них без индексов Joins performed without indexes: 20 729 886 - почти 21 млн.
вообще при Ваших объемах

[--] Data in MyISAM tables: 838M (Tables: 1133)
[--] Data in InnoDB tables: 277M (Tables: 483)

и объеме памяти все должно летать - все влезает в память несколько раз.

а можно по-подробнее про цель действа? Может проще сделать правльный SQL запрос (что-то мне подсказывает, что тут попахивает JOINом)?

И завязывайте с mysql_query. оно скоро умрет.

PS выполнят второй запрос в консоли mysql пробовали? может у вас нет ни одной записи в user с id = 1

инструкция.
Или я Вас неправильно понял, и Вас беспокоит именно даунтайм при первоначальной синхронизации?

Управление ИБ - суть работа технолога. Ваша основная задача будет грамотно построить и описать процесс.
Кто когда и что делает, какие точки контроля, какими документами все это подтверждается.

По опыту - кроме прочего(СТО БР ИББС/382-П/152ФЗ) "качайте" SQL/Excel/скриптовые языки. Очень поможет при обработке всяких логов/сверке списков при проверках.

пгостите, а меня одного убунта при установке спрашивает, накатывать ли автоматом секьюрити апдейты?
Оно конечно не супер-идея, но в любом случае вариантов ровно 2 - накатывать автоматом или накатывать руками. Руками - надо как-то получать алерты о выходе обновлений.
а уж запустить apt-get update / upgrade руками или через веб-морду - это вопрос уровня лени.
даже имея супер-удобную кнопку "обновить ВСЁ" - ее ведь надо догадаться нажать.

Документ, описывающий порядок предоставления доступа, у Вас есть? вот на основании его и напишите памятку. Памятка - суть краткое изложение Вашего процесса. А он может быть уникальным.

К примеру на одном из заводов, где я работал, он в виде блок-схемы.

1. нет, не правильно.
блокировка либо READ, либо WRITE.
MySQL.
READ - все(как сам процесс, так и другие) могут только читать.
WRITE - процесс, который вызвал блокировку, может читать и писать, остальные курят.
2. попробовать из другой сессии произвести запрещенное действие (INSERT/UPDATE/DELETE для READ, что угодно для WRITE) - запрос "зависнет" до разблокировки. Или до таймаута.
3. Будет ждать до таймаута.

ну и xml = туда-же

и снова OK Google

CREATE INDEX NAME_OF_MY_INDEX ON NAME_OF_MY_TABLE (NAME_OF_FIELD(3));

- создаете индекс только по первым трем символам поля.