Я знаю, что есть одна проблема в MySQL с одновременным SELECT и INSERT. Тем не менее, мой вопрос: если я открою два соединения с MySQL и продолжу загружать данные, используя оба из них, MySQL принимает данные одновременно или ждет завершения одного перед загрузкой другого?
Я хотел бы знать, как MySQL ведет себя в обоих случаях. Например, когда я пытаюсь загрузить данные в одну и ту же или в разные таблицы одновременно при открытии отдельных соединений.
Если вы создадите новое соединение с базой данных и выполните вставки по обеим ссылкам, то с точки зрения базы данных оно все равно будет последовательным.
Документация Concurrent Inserts на странице документации MySQL гласит:
Если имеется несколько операторов INSERT, они ставятся в очередь и выполняются последовательно, одновременно с инструкциями SELECT.
Помните, что нет никакого контроля над порядком, в котором будут происходить две одновременные вставки. Порядок в этом параллелизме зависит от множества различных факторов. Чтобы обеспечить порядок, по умолчанию вам придется пожертвовать параллелизмом.
Вы спрашиваете об обнаружении Deadlock, ACID и особенно MVCC, блокировке и транзакциях:
Обнаружение и откат тупика
InnoDB автоматически обнаруживает блокировки транзакций и откатывает транзакции или транзакции, чтобы выйти из тупика. InnoDB пытается выберите небольшие транзакции для отката, где размер транзакции определяется количеством вставленных, обновленных или удаленных строк. Когда InnoDB выполняет полный откат транзакции, все блокировки установленные транзакцией. Однако, если только один SQL оператор откатывается в результате ошибки, некоторые из замков установленный утверждением, может быть сохранен. Это происходит потому, что InnoDB хранит блокировки строк в таком формате, чтобы впоследствии не знать, какие блокировка была установлена с помощью инструкции.
https://dev.mysql.com/doc/refman/5.6/en/innodb-deadlock-detection.html
Блокировка
Система защиты транзакции от просмотра или изменения данных который запрашивается или изменяется другими транзакциями. Блокировка стратегия должна сбалансировать надежность и согласованность базы данных (принципы философии ACID) против производительность, необходимая для хорошего concurrency. Точная настройка блокировки стратегия часто предполагает выбор уровня изоляции и обеспечение всех ваши операции с базой данных безопасны и надежны для этой изоляции уровень.
http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_locking
ACID
Акроним, обозначающий атомарность, последовательность, изоляцию и долговечность. Эти свойства все желательны в системе баз данных, и все они тесно связаны с понятием транзакции. транзакционные особенности InnoDB соответствуют принципам ACID. Сделки - это атомные единицы работы, которые могут быть совершены или свернуты назад. Когда транзакция делает несколько изменений в базе данных, либо все изменения будут успешными при совершении транзакции, либо все изменения отменены, когда транзакция отменяется. база данных остается в постоянном состоянии во все времена - после каждого фиксация или откат, а также транзакции. Если данные обновляются в нескольких таблицах, запросы видят либо все старые значения или все новые значения, а не сочетание старых и новых значений. Транзакции защищены (изолированы) друг от друга, пока они в ходе выполнения; они не могут вмешиваться друг в друга или видеть друг друга незафиксированные данные. Эта изоляция достигается за счет блокировки механизм. Опытные пользователи могут настроить уровень изоляции, торговать меньше защиты в пользу повышения производительности и concurrency, когда они могут быть уверены, что транзакции действительно не мешают друг с другом.
http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_acid
MVCC
InnoDB - это многопользовательский механизм хранения данных (w532) (MVCC) что означает, что многие версии одной строки могут существовать в одном и том же время. На самом деле может быть огромное количество таких версий строк. В зависимости от выбранного режима изоляции, InnoDB, возможно, придется сохраните все версии строк, возвращаясь к самому раннему активному виду чтения, но по крайней мере, он должен будет сохранить все версии, возвращаясь к запуск запроса SELECT, который в настоящее время выполняется
https://www.percona.com/blog/2014/12/17/innodbs-multi-versioning-handling-can-be-achilles-heel/
Но подходы для одновременного чтения/записи зависят от используемого вами механизма хранения.
MySQL использует блокировку на уровне строк для таблиц InnoDB для поддержки одновременного доступа к записи несколькими сеансами, что делает их подходящими для многопользовательских, высококонкурентных и OLTP-приложений.
MySQL использует блокировку на уровне таблиц для таблиц MyISAM, MEMORY и MERGE, позволяя обновлять эти таблицы одновременно только в одном сеансе, делая их более подходящими для приложений только для чтения, в основном для чтения или для однопользовательских приложений.
Но, упомянутый выше поведение таблиц MyISAM может быть изменена путем concurrent_insert системной переменной для того, чтобы достичь параллельной записи. Пожалуйста, обратитесь к этой ссылке для деталей.
Следовательно, фактически, MySQL поддерживает одновременную вставку для InnoDB и механизма хранения MyISAM.
Это зависит от клиента - некоторые клиенты допускают одновременный доступ; некоторые будут сериализовать доступ, тем самым потеряв ожидаемый выигрыш. Вы даже не указали PHP против Java против... или Apache против... или Windows против... Многие комбинации просто не обеспечивают параллелизма.
В случае разных таблиц существует только общий конфликт для ввода-вывода, ЦП, мьютексов в buffer_pool и т.д. Возможен разумный объем параллелизма.
Если та же таблица, это зависит от индексов и шаблонов доступа. В некоторых случаях потоки будут блокировать друг друга. В некоторых случаях это даже приведет к "тупику" и откату одной из транзакций. Тупики не только замедляют, но и заставляют повторить вставки.
Если вы ищете высокоскоростное проглатывание большого количества строк, смотрите мой блог. В нем излагаются методы и указывается на несколько разветвлений, таких как репликация, выбор движка, многопоточность.
Несколько потоков, вставляемых в одни и те же таблицы - это во многом зависит от значений, которые вы предоставляете для любых PRIMARY или UNIQUE ключей. Это зависит от того, были ли предприняты другие действия в той же транзакции. Это зависит от того, насколько сильно задействован ввод/вывод. Это зависит от того, выполняете ли вы однострочную вставку или пакетирование. Это зависит от... (Извините, что расплывчато, но ваш вопрос не очень конкретный.)
Если вы хотите представить особенности двух или трех проектов, мы можем обсудить их.