Тонкости работы БД MySQL при одновременной записи и считывании данных из одной таблицы?

у меня писатель работает реально долго, его работу нужно оптимизировать

И это не имеет абсолютно никакого отношения к транзакционной работе.
Если работа с базой из приложения не проектировалась с оглядкой на конкурентный транзакционный доступ - у вас ситуация номер два. Читатель будет получать что-то. Что-то согласованное во времени или какие интересные аномалии - уж как ему повезёт.

sim3x, а что это изменит? Если писатель не учитывает конкурентный доступ - то читатель будет получать аномалии в любой реализации СУБД (и на любом уровне изоляции транзакций). СУБД не будет мешать делать запросы если специально не просить СУБД считать, что вот эта группа запросов должна быть читателям или полностью видна или полностью незаметна.

Егор Казанцев, ACID требует определённое поведение транзакций. Получать интересные аномалии как побочный эффект не учитывающего конкурентный доступ приложения ACID не мешают. Ну а по-умолчанию или нет - утешение слабое и учитывать что речь может быть об этой куче бинарного мусора под видом данных - стоит.

Тонкости работы БД MySQL при одновременной записи и считывании данных из одной таблицы?

К слову, учитывайте что я описал не все возможные варианты, а случайные 3.
Первый вариант наименее вероятный из трёх описанных.

Почему МФУ сканирует только часть листа?

или формат документа не А4 указан

Как сделать ограничение доступа к базе данных в Mysql?

Нет, базы не изолированы. Даже не в пределах компьютера. Что mysql что postgresql - клиент-серверные системы и позволяют в том числе осуществлять доступ по сети.
Корректно настроить доступ к базам - это задача системного администратора и дба (если последний есть)

Плюс необходимо помнить про особо доверенных людей - суперпользователей, для которых проверка прав доступа вообще не производится. И обычно создавать новые базы может как раз суперпользователь, но не обычные пользователи (хотя по mysql лучше уточнить, но в postgresql права на создание новых баз надо явно выдавать)

$_POST принимает NULL при AJAX запросе и мешает использовать PDO, как исправить?

Посмотрите в инструментах разработчика в браузере, какой именно запрос отправляется.

Сколько жетских дисков потребуется?

Да, 11. Не рекомендую, впрочем, raid5 на большом числе дисков (этак больше 6-8), лучше raid6 на 12 дисках.

PHP PDO Как добиться синхронной работы COMMIT?

Первая строчка однозначно выполняет COMMIT (см yii2). Вам придется поверить мне на слово.

Я лучше поверю исходнику:
https://github.com/yiisoft/yii2/blob/master/framew...
Может коммит, а может и не коммит. Не знаю, надо смотреть остальной ваш код или это конкретное место дебаггером, есть ли тут коммит.

PHP PDO Как добиться синхронной работы COMMIT?

Мне эти две строки не говорят ни о чём. Я даже не могу знать вызывается ли у вас коммит вообще - или это какая-то обёртка.

Работа коммутатора в сети. Как проходят запросы от рабочей станции до другого коммутатора?

На самом деле для ответа недостаточно информации, даже если считать все устройства расположенными в одном L2 домене (т.е. узел 1 выполняет коммутацию между 2 и 3, но не роутинг).
Один очень хитрый момент: таблица заполняется при получении пакета из порта.
Если узел E не ответит на пакет от B (и от него нет другой сетевой активности) - то узла E в таблицах коммутации свичей всё так же не будет и последующие пакеты от B до E всё равно будут рассылаться по всем портам и их будут получать все.
Но после прохождение любого пакета от E до свича 2 этот свич будет предполагать что знает на каких портах расположены оба адресата и переправлять пакеты с порта на порт не прибегая к рассылке по всем портам. То есть 4 эти пакеты уже получать не будет.

Пожалуй, сразу поясню "будет предполагать что знает": если вы переключите кабель узла E из узла 3 в 4 - то E не будет получать адресованные ему пакеты пока не будут удалены соответствующие записи из таблицы либо пока E не отправит какие-то пакеты.

Получается такая цепочка: станция В --> свитч 6 --> хаб 5 --> свитч 2 -->(хаб 4 (нет совпадений) и маршрутизатор 1) --> свитч 3 --> станция Е

На всякий случай два уточнения:
- у хабов в принципе нет таблицы коммутации. В жизни вам это знание пригодится разве только на собеседовании, потому что хабы давно уже не используются - я даже не сразу признал обозначение.
- первый отправленный в сети пакет (т.е. пока у всех свичей пустая таблица маков) получат вообще все в этом L2 сегменте. И каждый хост будет сверять по MAC'у, относился пакет ему или кому другому.

А вот хост I может совершенно незаметно подслушивать коммуникацию между B и E, т.к. получает эти пакеты из-за использования всего-лишь хаба.

Хотя скорее всего я просто вас запутал =) Представляйте поведение каждого узла в отдельности, на самом деле ни один из них не знает, к чему подключён. Напрямую пк к пк, через хаб или свитч или долгим путём через кучу устройств - на L2 у них у всех достаточно простая логика работы.

Блокировки в mysql, есть ли альтернатива?

Опишите сначала что должно происходить, затем уже надо думать, что при этом пойдёт не так в конкурентной среде и как это избежать.
Пока что мне кажется что вам нужен уникальный индекс и insert on duplicate key update

Почему незафисксированная транзакция 1-ым юзером отображается у 2-го?

Лентюй, в мануале написано что да, потому что нет вложенных транзакций (но есть savepoint). Мне претит вся идея неявного коммита, я бы предпочёл получать ошибку. Но уж что есть.

Почему незафисксированная транзакция 1-ым юзером отображается у 2-го?

JackShcherbakov, , я не вполне понял к каким соединениям относится какая транзакция в вашем тесте.
Если в одном соединении последовательно сделать:

begin;
insert into ...
begin; -- implicit commit here
insert another row
rollback;

то будет неявно закоммичен первый insert, несмотря на то, что коммита для него не было. rollback откатит только свою транзакцию из второго insert

Сможет ли другое соединение увидеть изменения незафиксированной транзакции - зависит от уровня изоляции транзакций. На READ UNCOMMITTED возможно читать то, что находится ещё в транзакции.
Неявный коммит же остаётся всё равно коммитом. После него все изменения будут видны новым транзакциям. (при read commited изоляции - и уже запущенным транзакциям тоже)

Почему незафисксированная транзакция 1-ым юзером отображается у 2-го?

нигде ничего автоматом не коммитится никогда

Эти бы слова, да в ядро mysql... https://dev.mysql.com/doc/refman/5.7/en/implicit-c...
Да, если вы уже в транзакции и пытаетесь сделать ещё раз begin - предыдущая транзакция будет неявно закоммичена.

Какую утилиту лучше использовать для реорганизации таблиц PostgreSQL (например: pg_repack vs pgcompactor vs подстройка автовакума)?

Как раз дописывал пару слов. Must have. Дефолтные настройки базы для того чтобы запуститься на любом калькуляторе, а не для работы.

Как вы измеряете профиль нагрузки (соотношение кол-ва чтений/кол-ву записей) в PostgreSQL?

Потому что соотношение чтения к записи не делают по числу запросов. Знаете ли, select одной строки по первичному ключу и половины таблицы seqscan'ом - это всё ещё один запрос с кардинально разными затратами io.

А с переносом части чтения на реплики - берёте topN отчёт и так и говорите:

ребята, смотрите: у нас дофига нагрузки вот от этих пары oltp запросов. Они же вроде не критичны к мелкому лагу? Давайте их на реплику скинем.
А вот этот милый запрос на 20% суточной нагрузки - это же вообще аналитика за прошлые сутки для менеджеров, давайте на аналитическую slow реплику перенесём, нафиг оно нам на мастере автовакууму мешает

Как вы измеряете профиль нагрузки (соотношение кол-ва чтений/кол-ву записей) в PostgreSQL?

Бессмысленная метрика. Нет, отдельных счётчиков нет.
Осмысленная метрика - сколько таплов читали-писали: n_tup_ins/n_tup_upd/n_tup_del/n_tup_hot_upd/seq_tup_read/idx_tup_fetch в pg_stat_all_tables.
И другая осмысленная метрика - topN запросов по времени выполнения из pg_stat_statements.

Процессор греется под водянкой до 100 градусов. Есть эксперты?

Хладагент-то циркулирует?

Как оптимизировать проверку на уникальность ID?

600к записей добавлялись 5 часов. Это нормально?

Если вы коммитили каждую запись отдельно, да ещё на дефолтном конфиге - могло было быть и хуже чем ~33 tps.
Если прочитать bulk insert раздел - то будет совсем другой результат.

TINYINT vs ENUM: в ситуации, когда возможных целочисленных значений всего несколько?

(1,60) зависит от strict sql_mode
(2,5) у меня на 5.5 работает, может запретили в 5.7 (хотя буду удивлён).

Если вам не кажется странным - то используйте. Я бы предпочёл не исследовать удивительные фокусы типизации enum и его взаимодействия с и без того мягкой типизации mysql.
Жаль что в mysql check constraint нет - вот это было бы реальное решение задачи без странных фокусов.

TINYINT vs ENUM: в ситуации, когда возможных целочисленных значений всего несколько?

Ммм, примера было недостаточно для описания причин?