Несколько дней назад один фанат рассказал мне о вопросах, которые ему задавали, когда он проходил собеседование при приеме на работу на большой завод, потому что во время эпидемии очень сложно найти работу. Он сказал, что вопросы для собеседования также более сложные, и это, как правило, вопросы для собеседования с опытом работы в один или два года.
Он сказал, что когда его спросили о вопросах на собеседовании по Mysql, он был удовлетворен ответом на индекс, но был сбит с толку, когда его спросили о механизме блокировки Mysql.
Поскольку я обычно не обращаю внимания на механизм блокировки Mysql, когда меня спрашивают, как механизм блокировки обеспечивает согласованность данных и изоляцию транзакций в сценариях с высокой степенью параллелизма.
Он поделился со мной своим интервью.Вопрос о механизме блокировки высокой степени параллелизма в Mysql задавали почти все крупные производители.Как Mysql контролирует одновременный доступ в условиях высокой степени параллелизма?
Я тщательно все обдумал, механизм блокировки Mysql действительно очень важен, поэтому я сделаю здесь исчерпывающее резюме для дальнейшего использования, а также поделюсь им с читателями.
Механизм блокировки Mysql все еще немного сложен для понимания, поэтому в этой статье используется комбинация изображений и текстов для объяснения трудностей, чтобы помочь всем понять.
Карта мозга из этой статьи
тип замка
Классификацию блокировок в Mysql можно разделить на разные блокировки в соответствии с разными типами делений."блокировка детализации"Дивизию можно разделить на:"Блокировки таблицы, блокировки страниц, блокировки строк";в соответствии с"как пользоваться"Дивизию можно разделить на:"общий замок"и"эксклюзивный замок"; по разделению идей:"оптимистическая блокировка"и"пессимистический замок".
Далее мы дадим подробное объяснение и введение этих типов замков.Понимая концепцию замков, разработанных дизайнерами, мы также можем глубоко понять дизайнерские идеи дизайнеров.
"блокировка стола"Это блокировка с наибольшей степенью детализации, с низкими накладными расходами, быстрой блокировкой и отсутствием взаимоблокировок.Однако из-за слишком большой детализации вероятность конфликта блокировок высока, а производительность параллелизма низка.
Mysql"Механизм хранения MyISAM поддерживает блокировки таблиц", MyISAM имеет два режима блокировки таблицы:"общая блокировка чтения таблицы"и"Эксклюзивная блокировка записи таблицы".
Когда поток получает блокировку чтения для таблицы MyISAM, он блокирует операции записи других пользователей в таблицу, но не блокирует операции чтения других пользователей для пользователя.
И наоборот, когда поток получает блокировку записи в таблице MyISAM, он блокирует операции чтения и записи других пользователей, которые являются исключительными для других потоков.
"блокировка страницы"Гранулярность — это своего рода блокировка между блокировками строк и блокировками таблиц, поскольку блокировки страниц — это механизм блокировки, поддерживаемый в BDB, и редко упоминается и используется, поэтому здесь представлен обзор, а не подробное объяснение.
"блокировка строки"Это механизм блокировки с наименьшей степенью детализации.Накладные расходы на блокировку блокировок строк высоки, блокировка выполняется медленно и могут возникать взаимоблокировки, но вероятность конфликтов блокировок блокировок строк низкая, а производительность параллелизма высока.
Блокировка строки — это механизм блокировки по умолчанию, поддерживаемый InnoDB.MyISAM не поддерживает блокировку строки, что также является одним из различий между InnoDB и MyISAM.
Рядные замки можно разделить на:"Общая блокировка чтения (блокировка S)"и"Эксклюзивная блокировка записи (блокировка X)".
Когда транзакция добавляет блокировку S к строке данных в Mysql, текущая транзакция не может изменять строку данных и может выполнять только операцию степени Другие транзакции могут добавлять только блокировку S к строке данных, но не блокировку X.
Если транзакция добавляет блокировку X к строке данных, транзакция может выполнять операции чтения и записи строки данных, а другие транзакции не могут добавлять какие-либо блокировки к строке данных, ни чтение, ни запись.
"Пессимистическая блокировка и оптимистичная блокировка — это тип мышления, существующий во многих фреймворках, не думайте, что они являются механизмом блокировки определенного фреймворка в узком смысле.".
В системе управления базами данных для управления параллелизмом и обеспечения согласованности данных и изоляции транзакций при выполнении нескольких транзакций для решения проблем в параллельных сценариях используются пессимистические блокировки и оптимистичные блокировки.
Mysql"Реализация пессимистичных блокировок основана на собственном механизме блокировки Mysql, в то время как оптимистичные блокировки требуют, чтобы программисты сами реализовали механизм блокировки.", наиболее распространенной реализацией оптимистичной блокировки является механизм блокировки"Реализовано с использованием номеров версий".
Оптимистичные идеи дизайна замка вCASПрименение CAS также является относительно классическим, я уже писал статью о CAS, если вам интересно, вы можете обратиться к этой статье [].
Из приведенного выше введения описывается концепция каждого типа блокировки, но трудно сказать, какой тип замка является лучшим.Нет лучшего замка, только какой тип бизнес-сценария наиболее подходит для какого типа замка, и подробно анализируется конкретный бизнес.
Далее мы подробно проанализируем применение и реализацию каждой блокировки в механизме хранения на основе механизма хранения на основе Mysql.
MyISAM
В MyISAM по умолчанию поддерживаются два типа блокировок на уровне таблиц:"общая блокировка чтения"и"Эксклюзивная блокировка записи". Блокировки на уровне таблицы поддерживаются как в MyISAM, так и в механизмах хранения InnoDB, но InnoDB по умолчанию поддерживает блокировки строк.
В Mysql обычные операции чтения и записи неявно блокируются и разблокируются.Mysql автоматически помог нам реализовать операции блокировки и разблокировки.Если мы хотим протестировать механизм блокировки, мы должны отобразить собственный контроль над механизмом блокировки.
В Mysql для явного выполнения операций блокировки и разблокировки в транзакции можно использовать следующий sql:
// 显式的添加表级读锁
LOCK TABLE 表名 READ
// 显示的添加表级写锁
LOCK TABLE 表名 WRITE
// 显式的解锁（当一个事务commit的时候也会自动解锁）
unlock tables;
Давайте протестируем механизм блокировки на уровне таблицы в MyISAM, сначала создадим тестовую таблицу.employee, чтобы указать механизм хранения как MyISAM и вставить две части тестовых данных:
CREATE TABLE IF NOT EXISTS employee (
id INT PRIMARY KEY auto_increment,
name VARCHAR(40),
money INT
)ENGINE MyISAM
INSERT INTO employee(name, money) VALUES('黎杜', 1000);
INSERT INTO employee(name, money) VALUES('非科班的科班', 2000);
Проверьте это, результаты таблицы показаны на следующем рисунке:
Блокировка записи на уровне таблицы MyISAM
(1) В то же время откройте окно сеанса, затем выполните следующий sql в первом окне и добавьте блокировку записи в таблицу в сеансе1:
LOCK TABLE employee WRITE
(2) Вы можете запросить, вставить или обновить данные таблицы в сеансе2, и вы можете обнаружить, что все они находятся в состоянии ожидания, то есть сеанс1 блокирует всю таблицу, поэтому сеанс2 может только ждать:
(3) Запрос, вставка и обновление данных в session1 могут выполняться успешно:
"Суммировать:"Из приведенных выше результатов испытаний видно"Когда поток получает блокировку записи на уровне таблицы, только этот поток может читать и записывать таблицу, а другие потоки должны ждать, пока поток снимет блокировку, прежде чем они смогут работать.".
Разделяемая блокировка чтения на уровне таблицы MyISAM
(1) Затем проверьте общую блокировку чтения на уровне таблицы, а также используйте приведенные выше тестовые данные.Первый шаг — добавить блокировку чтения в таблицу в сеансе1.
(2) Затем попробуйте вставить и обновить данные в session1 и обнаружите, что будет сообщено об ошибке, и можно будет запросить только данные.
(3) Наконец, если вы попытаетесь вставить и обновить данные в сеансе2, программа войдет в состояние ожидания, и вы сможете только запрашивать данные, пока сеанс1 не разблокирует таблицу сеанса2 для вставки и обновления данных.
"Суммировать:"Из приведенных выше результатов испытаний видно"Когда поток получает блокировку чтения на уровне таблицы, этот поток может только читать данные и не может изменять данные.Другие потоки могут только добавлять блокировки чтения, но не блокировки записи.".
Конкуренция за блокировку на уровне таблицы MyISAM
В механизме хранения MyISAM вы можете проверить конфликт блокировок в параллельных сценариях, запрашивая переменные.В частности, выполните следующие операторы SQL:
show status like 'table%';
в основном для просмотраtable_locks_waitedиtable_locks_immediateРазмер значения анализирует конфликт блокировок.
Table_locks_immediate: указывает количество запросов на блокировку, которые могут немедленно получить блокировки на уровне таблицы;Table_locks_waitedУказывает на анализ количества запросов на блокировку, которые необходимо дождаться блокировки на уровне таблицы, которая не может быть получена немедленно,"Чем выше значение, тем серьезнее конкуренция".
одновременная вставка
В приведенной выше демонстрации операции подробно описаны характеристики общих блокировок на уровне таблицы и блокировок записи на уровне таблицы. Но при обычном выполнении sql эти"Разблокировка и снятие блокировок выполняются неявно базовым Mysql.".
Приведенная выше демонстрация предназначена только для демонстрации функций блокировки и разблокировки общих блокировок и блокировок записи на уровне таблицы в процессе явного выполнения транзакций, что на самом деле не выполняется.
Когда мы обычно выполняем оператор select, мы неявно добавляем блокировки чтения и неявно выполняем блокировки записи при добавлении, удалении и изменении операций.
В механизме хранения MyISAM, хотя операции чтения и записи сериализованы, он также поддерживает параллельную вставку, для чего требуется установка внутренних переменных.concurrent_insertзначение .
Его значение имеет три значения0、1、2. Его можно просмотреть через следующий sqlconcurrent_insertЗначение по умолчанию"АВТО (или 1)".
Значение concurrent_insert равноNEVER (or 0)Указывает, что одновременные вставки не поддерживаются; значение равноAUTO(或者1）Указывает строки, которые не были удалены в таблице MyISAM, и запускает другой поток для вставки данных с конца таблицы; значение равноALWAYS (or 2)Указывает, что данные можно вставлять в конец таблицы независимо от наличия удаленных строк.
планирование блокировки
В механизме хранения MyISAM"Если запрос на чтение и запрос на запись приходят одновременно, он сначала обработает запрос на запись.", потому что подсистема хранения MyISAM считает запросы на запись более важными, чем все запросы.
Это приведет к,"Если приходит большое количество запросов на чтение и запись, это приведет к длительному ожиданию запроса на чтение или «голоданию потока», поэтому MyISAM не подходит для сценариев с большим количеством операций чтения и записи.", что приведет к тому, что пользовательские данные не будут считаны в течение длительного времени, и пользовательский опыт будет крайне плохим.
Конечно, установивlow-priority-updatesПараметр устанавливает приоритет ссылки запроса, так что Mysql сначала обрабатывает запрос на чтение.
InnoDB
Разница между InnoDB и MyISAM заключается в том, что InnoDB поддерживает"блокировка строки"и"дела", Концепция блокировок на уровне строк упоминалась ранее и не будет повторяться здесь.Обзор четырех характеристик транзакций и принципов реализации см. в этой статье [].
InnoDB помимо наличия"блокировка стола"и"блокировка уровня строки"концепции, а также Gap Lock (замок промежутка), Next-key Lock,"Гэп-блокировки в основном используются для запросов диапазона, чтобы заблокировать диапазон запроса, а гэп-блокировки также являются решением для фантомных чтений.".
Блокировки на уровне строк в InnoDB"Когда блокировка добавляется в индекс, когда данные не запрашиваются через индекс, InnoDB будет использовать блокировку таблицы.".
"А вот использовать ли индекс при запросе по индексу зависит от плана выполнения Mysql", оптимизатор Mysql определит наилучшую стратегию выполнения SQL.
Если Mysql считает, что выполнение индексного запроса не так быстро, как полное сканирование таблицы, то Mysql будет использовать для запроса полное сканирование таблицы, а это означает, что даже если индекс используется в операторе sql, в конечном итоге он выполняется как полный просмотр таблицы. сканирование таблицы с блокировкой таблицы.
Если вы не знакомы с принципом выполнения sql в Mysql, вы можете обратиться к этой статье []. Был ли индексный запрос выполнен в конце, можно сделать с помощьюexplainПриходите и проверьте, думаю, эта команда всем знакома.
Блокировки строк и таблиц InnoDB
Блокировки строк InnoDB также делятся на"Общая блокировка чтения (блокировка S)"и"Эксклюзивная блокировка записи (блокировка X)", основные функции такие же, как у режимов блокировки на уровне таблицы MyISAM.
Если вы хотите явно добавить блокировку чтения на уровне строки и блокировку записи в таблицу, вы можете выполнить следующую инструкцию SQL:
// 给查询sql显示添加读锁
select ... lock in share mode;
// 给查询sql显示添加写锁
select ... for update；
(1) Теперь мы непосредственно переходим к этапу тестирования механизма блокировки или создаем тестовую таблицу и вставляем две части данных:
// 先把原来的MyISAM表给删除了
DROP TABLE IF EXISTS employee;
CREATE TABLE IF NOT EXISTS employee (
id INT PRIMARY KEY auto_increment,
name VARCHAR(40),
money INT
)ENGINE INNODB;
// 插入测试数据
INSERT INTO employee(name, money) VALUES('黎杜', 1000);
INSERT INTO employee(name, money) VALUES('非科班的科班', 2000);
(2) В созданной таблице видно, что только поле id в таблице добавляется с индексом первичного ключа, а затем выполняется в окне session1beginЗапустите транзакцию и выполните следующую инструкцию sql:
// 使用非索引字段查询，并显式的添加写锁
select * from employee where name='黎杜' for update;
(3) Затем выполните оператор обновления в сеансе 2. Строка данных с идентификатором = 1 в приведенном выше запросе и строка данных с идентификатором = 2 в приведенном ниже обновлении обнаружат, что программа также войдет в состояние ожидания:
update employee set name='ldc' where id =2;
Видно, что если"Использование неиндексированных запросов напрямую связано с блокировкой на уровне таблицы.", который блокирует всю таблицу.
(4) Если session1 использует идентификатор для запроса, как показано на следующем рисунке:
(5) Тогда сессия2 может успешно обновлять другие строки данных, но здесь я рекомендую использовать для тестирования таблицу с большим объемом данных, потому что я сказал ранее"Необходимость выполнения индекса зависит от плана выполнения Mysql.Для некоторых операций с небольшими таблицами можно напрямую использовать полное сканирование таблицы.".
(6) Существует другая ситуация: если мы также добавим общий индекс в поле имени, затем запросим данные через общий индекс и запросим несколько строк данных, нужно ли заблокировать несколько строк данных или заблокировать всю таблицу?
Давайте проверим это, сначала дайте"Добавьте общий индекс в поле имени",Как показано ниже:
(6) И вставьте новое значение имени данных, совпадающее со значением id=2, и явно заблокируйте его следующим образом:
(7) Когда значение имени других строк данных в обновлении не равно ldc, оно также войдет в состояние ожидания, и через объяснение, чтобы проверить, имеет ли name='ldc' индекс выполнения, вы можете увидеть, что оператор sql имеет условие выполнения индекса.
Вывод: Из приведенной выше демонстрации механизма тестового замка можно сделать следующие выводы:
- При выполнении неиндексного условного запроса выполняется блокировка таблицы.
- Является ли выполнение индексного запроса блокировкой строки, зависит от плана выполнения Mysql, который можно проверить с помощью ключевого слова объяснения.
- Запросы, использующие индекс общего ключа и встречающие одно и то же значение индекса, также повлияют на другие строки данных операции.
Блокировка разрыва InnoDB
Когда мы используем условный запрос диапазона вместо эквивалентного условного запроса, InnoDB заблокирует индекс диапазона, который соответствует условиям, а записи, которые не существуют в условном диапазоне, называются «пробелом (GAP)».
Все, наверное, знают, что среди четырех уровней изоляции транзакций неповторяющиеся чтения будут вызывать фантомные чтения, разрешить которые можно только повышением уровня изоляции до сериализации.
Тем не менее, неповторяемость в Mysql решила проблему фантомного чтения.Фантомное чтение решается за счет внедрения блокировки промежутков.Блокировка квалифицированных промежутков предотвращает возникновение проблемы фантомного чтения при повторном запросе новых данных.
Например, если мы выполним следующую инструкцию sql, записи с идентификатором больше 100 будут заблокированы, а в записях с идентификатором > 100 должны быть пробелы:
Select * from employee where id> 100 for update;
(1) Затем проверьте блокировку промежутка, добавьте новое поле num, добавьте num в качестве общего индекса и измените предыдущие данные, чтобы между значениями num был разрыв, Операция показана в следующем SQL:
alter table employee add num int not null default 0;
update employee set num = 1 where id = 1;
update employee set num = 1 where id = 2;
update employee set num = 3 where id = 3;
insert into employee values(4,'kris',4000,5);
(2) Затем откройте транзакцию в окне session1 и выполните следующие операции:
(3) Одновременно откройте окно session2 и выполните новый оператор:
insert into employee values(5,'ceshi',5000,2); // 程序出现等待
insert into employee values(5,'ceshi',5000,4); // 程序出现等待
insert into employee values(5,'ceshi',5000,6); // 新增成功
insert into employee values(6,'ceshi',5000,0); // 新增成功
"Из приведенных выше результатов теста видно, что между интервалом (1,3]U[3,5) добавляется блокировка и невозможно добавить строки данных, поэтому добавление num=2 и num= 4 не удается, но строки данных за пределами этого интервала не блокируются, и можно добавлять новые строки данных.".
Согласно порядку индекса, а обычные индексы могут иметь повторяющиеся значения, то при запросе первого сеанса появляется только один фрагмент данных num=3.Чтобы решить фантомное чтение во время второго запроса, то есть два Элементы или дополнительные данные для условий запроса, например num=3.
Mysql в случае выполнения условия where дайте（1,3]U[3,5)Интервал плюс блокировка не позволяют вставлять строки данных с числом = 3, что устраняет фантомное чтение.
Вот несколько случаев для проверки гэп-блокировок. Будет ли индекс первичного ключа (уникальный индекс) добавлять пробел? Будут ли запросы диапазона добавлять блокировки пробелов? Добавляет ли использование несуществующего условия извлечения гэп-блокировку?
Давайте начнем с:"Будет ли индекс первичного ключа (уникальный индекс) добавлять пробел?"
Поскольку индекс первичного ключа уникален и дублирование не допускается, при выполнении эквивалентного запроса с id=3 может быть только одна и только одна часть данных, а вторая часть данных с id=3 невозможна. появиться.
Следовательно, пока он блокирует эти данные (блокирует индекс), они не будут удалены при следующем запросе текущего чтения или будет обновлена строка данных с id=3, что обеспечивает согласованность данных, поэтому индекс первичного ключа уникален благодаря своей уникальности. Причина в том, что нет необходимости добавлять блокировку пробела.
Давайте поговорим о втором вопросе:"Будут ли запросы диапазона добавлять блокировки пробелов?"
Выполните следующую инструкцию sql непосредственно в сеансе 1 и добавьте данные внутри и вне условия запроса num>=3 в сеансе 2:
select * from employee where num>=3 for update;
insert into employee values(6,'ceshi',5000,2); // 程序出现等待
insert into employee values(7,'ceshi',5000,4); // 程序出现等待
insert into employee values(8,'ceshi',5000,1); // 新增数据成功
Давайте проанализируем следующие принципы: когда одиночный запрос num>=3, строки данных, которые удовлетворяют условиям в существующей таблице сотрудников, следующие:
| id | num |
|---|---|
| 3 | 3 |
| 4 | 5 |
| 5 | 6 |
Затем, с точки зрения дизайнера, чтобы решить проблему фантомного чтения: при условии num>=3 необходимо добавить блокировку пробела.
В случае, когда число меньше 3, следующая строка данных имеет номер = 1. Чтобы предотвратить добавление строки данных с числом = 3 в диапазон (1, 3), к этому также добавляется блокировка. разрыв, который добавляет num=2 строки данных, по-видимому, является причиной ожидания.
Наконец, позвольте мне сказать:"Добавляет ли использование несуществующего условия извлечения гэп-блокировку?"
Что делать, если запрашивается строка данных с num>=8? Поскольку в таблице сотрудников нет строки данных с num=8, максимальное num равно 6, поэтому для решения фантомного чтения (6, 8] и num>=8 также будет добавлена блокировка.
Говоря об этом, я считаю, что многие люди имеют четкое и глубокое понимание гэп-локов, можно сказать, что они опытны и могут разговаривать с интервьюером.
Если вы впервые соприкасаетесь с механизмом блокировки Mysql, вы должны быть в неведении в первый раз.Рекомендуется прочитать его несколько раз более внимательно, следить за делом, чтобы понять его глубоко, и медленно понять Это.
тупик
Взаимоблокировки будут возникать только в InnoDB, но MyISAM не будет иметь взаимоблокировок, потому что MyISAM поддерживает блокировки таблиц.Все блокировки устанавливаются одновременно, а другие потоки могут только ждать в очереди.
InnoDB поддерживает блокировки строк по умолчанию, и получение блокировок выполняется поэтапно, не все блокировки устанавливаются одновременно, поэтому взаимоблокировки будут возникать, когда блокировки будут конкурировать.
Хотя InnoDB будет иметь взаимоблокировки, это не повлияет на самый популярный механизм хранения InnoDB.MyISAM можно понимать как сериализованные операции, а операции чтения и записи упорядочены, поэтому поддерживаемая производительность параллелизма низкая.
Случай тупика 1
Например, теперь в таблице сотрудников базы данных есть шесть фрагментов данных, а именно:
Среди них есть две части данных с именем = ldc, а поле имени является общим индексом, который представляет собой строки данных с идентификатором = 2 и идентификатором = 3. Теперь предположим, что есть две транзакции, которые выполняют следующие два SQL-запроса. заявления:
// session1执行
update employee set num = 2 where name ='ldc';
// session2执行
select * from employee where id = 2 or id =3;
Среди них строки данных, полученные SQL, выполняемым сеансом 1, представляют собой две строки данных Предположим, что первая строка данных с id = 2 получена первой, а затем процессорное время выделяется для другой транзакции, а другая транзакция выполняет операцию запроса для получить вторую строку Данные - это строка данных с идентификатором = 3.
Когда транзакция 2 продолжает выполняться, получается строка данных с идентификатором = 3, а строка данных с идентификатором = 3 блокируется.В это время ЦП выделяет время для первой транзакции, и первая транзакция выполняется для подготовки к получению вторая строка данных.Обнаружено, что блокировка была получена другими транзакциями, и она находится в состоянии ожидания.
Когда процессор выделяет время для второй транзакции, вторая транзакция готова получить блокировку первой строки данных и обнаруживает, что блокировка была получена первой транзакцией, поэтому возникает взаимоблокировка, и две транзакции ждут друг друга.
Случай тупика 2
Вторая тупиковая ситуация заключается в том, что когда транзакция запускается и обновляет строку данных с идентификатором = 1, блокировка записи успешно получена.В это время, когда другая транзакция выполняется и обновляет другую строку данных с идентификатором = 2, она также успешно получает блокировку записи. блокировка записи Блокировка записи (идентификатор в качестве первичного ключа).
В это время ЦП выделяет время транзакции 1, а транзакция 1 также является строкой данных с идентификатором обновления = 2. Поскольку транзакция 2 заблокировала строку данных с идентификатором = 2, транзакция уже находится в состоянии ожидания. .
Транзакция 2 получила время, такое как выполнение строки данных с идентификатором обновления = 1, но в это время блокировка с идентификатором = 1 получена транзакцией 1, а транзакция 2 также находится в состоянии ожидания, что приводит к взаимоблокировке.
| session1 | session2 |
|---|---|
| begin;update t set name='test', где id=1; | begin |
| update t set name='test', где id=2; | |
| update t set name='test', где id=2; | |
| ждать..... | update t set name='test', где id=1; |
| ждать..... | ждать...... |
тупиковое решение
Прежде всего, необходимо решить проблему взаимоблокировки.При разработке программы, когда обнаруживается, что программа имеет много одновременных доступов к таблице, попытайтесь сериализовать операцию таблицы или обновить блокировку и получить все ресурсы блокировки одновременно.
Затем вы также можете установить параметрыinnodb_lock_wait_timeout, период ожидания и параметрinnodb_deadlock_detectОткрытый, при обнаружении взаимоблокировки происходит автоматический откат одной из транзакций.
Суммировать
Реализация механизма блокировки механизмов хранения MyISAM и InnoDB подробно описана выше и протестирована.
Блокировки таблиц MyISAM делятся на два режима:"общая блокировка чтения"и"эксклюзивная блокировка записи". Поток, который получает блокировку чтения, может только читать строку данных и не может ее изменять, а другие потоки могут только добавлять блокировки чтения к строке данных.
Поток, получивший блокировку записи, может как читать, так и записывать строку данных, а также имеет монопольный доступ к другим потокам для чтения и записи строки данных.
По умолчанию запись в MyISAM имеет приоритет над операциями, поэтому MyISAM вообще не подходит для программ с большим количеством операций чтения и записи.
Хотя блокировка строк InnoDB может привести к взаимоблокировке, параллельная производительность, поддерживаемая InnoDB, лучше, чем у MyISAM, а степень детализации блокировки строк является наименьшей.Определенные методы и меры могут устранить возникновение взаимоблокировки и максимизировать производительность InnoDB.
InnoDB представляет концепцию гэп-блокировок для решения проблемы фантомного чтения, а также вводит характеристики транзакций.Благодаря четырем уровням изоляции транзакций количество конфликтов блокировок уменьшается, а производительность параллелизма повышается.