Общие вопросы на собеседовании по MySQL / сводка знаний! (последняя версия 2021 г.) | JavaGuide

задняя часть
Общие вопросы на собеседовании по MySQL / сводка знаний! (последняя версия 2021 г.) | JavaGuide

Связанное чтение:2,7 Вт слов! Java основные вопросы интервью / резюме очков знаний! (последняя версия 2021 г.)

Этот пост был опубликован ранее, однако недавно я провел его рефакторинг до совершенства и исправил множество мелких проблем. Итак, давайте снова синхронизируемся!

Контент жесткий! Настоятельно рекомендуется прочитать ее примерно за 10 минут!

Основы MySQL

Введение в реляционные базы данных

Как следует из названия, реляционная база данных — это база данных, построенная на реляционной модели. Реляционная модель выражает связи (один-к-одному, один-ко-многим, многие-ко-многим) между данными, хранящимися в базе данных.

В реляционных базах данных наши данные хранятся в различных таблицах (например, пользовательских таблицах), и каждая строка в таблице хранит часть данных (например, информацию о пользователе).

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

Каковы общие реляционные базы данных?

MySQL, PostgreSQL, Oracle, SQL Server, SQLite (SQLite используется для хранения записей локального чата WeChat) ......

Введение в MySQL

MySQL — это реляционная база данных, в основном используемая для постоянного хранения некоторых данных в нашей системе, таких как информация о пользователях.

Поскольку MySQL является бесплатной и относительно зрелой базой данных с открытым исходным кодом, MySQL широко используется в различных системах. Любой желающий может скачать его под лицензией GPL (General Public License) и модифицировать в соответствии со своими потребностями. Номер порта по умолчанию для MySQL:3306.

механизм хранения

Команды, связанные с механизмом хранения

Просмотреть все механизмы хранения, предоставляемые MySQL

mysql> show engines;

查看MySQL提供的所有存储引擎

Из приведенного выше рисунка видно, что текущим механизмом хранения MySQL по умолчанию является InnoDB, и среди всех механизмов хранения в версии 5.7 только InnoDB является механизмом хранения транзакций, что означает, что только InnoDB поддерживает транзакции.

Просмотр текущего механизма хранения MySQL по умолчанию

Мы также можем просмотреть механизм хранения по умолчанию с помощью следующей команды.

mysql> show variables like '%storage_engine%';

Просмотр механизма хранения таблицы

show table status like "table_name" ;

查看表的存储引擎

Разница между MyISAM и InnoDB

До MySQL 5.5 механизм MyISAM был механизмом хранения MySQL по умолчанию, и это было хорошо.

Хотя производительность MyISAM неплохая, и различные функции неплохие (такие как полнотекстовое индексирование, сжатие, пространственные функции и т.д.). Однако MyISAM не поддерживает транзакции и блокировку на уровне строк, и самый большой недостаток заключается в том, что его нельзя безопасно восстановить после сбоя.

После версии 5.5 MySQL представила InnoDB (механизм транзакционной базы данных).Механизмом хранения по умолчанию после MySQL версии 5.5 является InnoDB. Ребята, обязательно запомните эту InnoDB.Вы используете этот механизм хранения каждый раз, когда используете базу данных MySQL, верно?

Ближе к дому! Кратко сравним их:

1. Поддерживать ли блокировку на уровне строк

MyISAM имеет блокировку только на уровне таблицы, в то время как InnoDB поддерживает блокировку на уровне строки и блокировку на уровне таблицы.По умолчанию используется блокировка на уровне строки.

То есть MyISAM блокирует всю таблицу одной блокировкой, что так глупо в случае параллельной записи! Вот почему InnoDB работает лучше при параллельной записи!

2. Поддерживать ли транзакции

MyISAM не обеспечивает поддержку транзакций.

InnoDB обеспечивает поддержку транзакций с возможностью фиксации и отката транзакций.

3. Поддерживать ли внешние ключи

MyISAM не поддерживает его, а InnoDB поддерживает.

🌈 Разверните его:

Как правило, мы не рекомендуем использовать внешние ключи на уровне базы данных, и это можно решить на уровне приложения. Однако это представляет угрозу для согласованности данных. Использовать внешние ключи или нет, зависит от вашего проекта.

4. Поддерживать ли безопасное восстановление после аварийного сбоя базы данных

MyISAM не поддерживает его, а InnoDB поддерживает.

После аварийного сбоя базы данных, использующей InnoDB, база данных будет восстановлена ​​до состояния, предшествующего сбою, при перезапуске базы данных. Этот процесс восстановления зависит отredo log.

🌈 Разверните его:

  • Механизм MySQL InnoDB используетжурнал повторовгарантированный бизнесУпорство,использоватьжурнал отмены (журнал отката)для обеспечения бизнесаатомарность.
  • Механизм MySQL InnoDB череззамок механизм,MVCCи другие средства для обеспечения изоляции транзакций (поддерживаемый уровень изоляции по умолчанию —REPEATABLE-READ).
  • Согласованность может быть гарантирована только после того, как будут гарантированы надежность, атомарность и изоляция транзакций.

5. Поддерживается ли MVCC

MyISAM не поддерживает его, а InnoDB поддерживает.

Честно говоря, это сравнение немного нонсенс, ведь MyISAM даже не поддерживает блокировки на уровне строк.

MVCC можно рассматривать как модернизацию блокировок на уровне строк, которая может эффективно сократить операции блокировки и повысить производительность.

Выбор MyISAM и InnoDB

Большую часть времени мы используем механизм хранения InnoDB, а в некоторых случаях с интенсивным чтением также подходит использование MyISAM. Однако предпосылка заключается в том, что ваш проект не возражает против недостатков MyISAM, не поддерживающих транзакции, аварийное восстановление и т. д. (но ~ мы обычно делаем!).

В «Высокой производительности MySQL» есть предложение, в котором говорится:

Не легко поверить в опыт «MyISAM быстрее, чем InnoDB», этот вывод часто не является абсолютным. Во многих известных сценариях скорость InnoDB может сделать MyISAM непревзойденной, особенно для приложений, использующих кластеризованные индексы, или данные, к которым необходимо получить доступ, могут быть помещены в память.

В обычных условиях у нас нет проблем с выбором InnoDB, но в некоторых случаях вас не волнуют масштабируемость и параллелизм, и вам не нужна поддержка транзакций, и вы не заботитесь о восстановлении безопасности после сбоя. тоже хороший выбор.. Но в целом мы все должны учитывать эти вопросы.

Поэтому для бизнес-систем, которые мы ежедневно разрабатываем, вы вряд ли найдете причину использовать MyISAM в качестве механизма хранения для вашей собственной базы данных MySQL.

Механизм блокировки и алгоритм блокировки InnoDB

Блокировки, используемые механизмами хранения MyISAM и InnoDB:

  • MyISAM использует блокировку на уровне таблицы.
  • InnoDB поддерживает блокировку на уровне строки и блокировку на уровне таблицы, по умолчанию используется блокировка на уровне строки.

Сравнение блокировок на уровне таблицы и блокировок на уровне строк:

  • Блокировки на уровне таблицы:Блокировка в MySQLМаксимальная детализацияРазновидность блокировки, которая блокирует всю таблицу текущей операции, проста в реализации, потребляет меньше ресурсов, блокируется быстро и не вызывает взаимоблокировок. Он имеет наибольшую степень детализации блокировки, наибольшую вероятность возникновения конфликтов блокировок и наименьший уровень параллелизма.Оба механизма MyISAM и InnoDB поддерживают блокировки на уровне таблицы.
  • Блокировка уровня строки:Блокировка в MySQLнаименьшая степень детализацииТип блокировки, которая блокирует только строку, над которой в данный момент выполняется операция. Блокировки на уровне строк могут значительно уменьшить количество конфликтов в операциях базы данных. Его степень детализации блокировки является наименьшей, а параллелизм высоким, но накладные расходы на блокировку также самые большие, а блокировка выполняется медленно и могут возникать взаимоблокировки.

Существует три алгоритма блокировки для механизма хранения InnoDB:

  • Блокировка записи: блокировка записи, блокировка записи одной строки
  • Блокировка промежутка: Блокировка промежутка, блокирует диапазон, исключая саму запись
  • Блокировка следующей клавиши: блокировка клавиши записи + промежутка, блокирует диапазон, включая саму запись.

кэш запросов

При выполнении запроса сначала запрашивается кэш. Однако он был удален после MySQL 8.0, поскольку эта функция не очень практична.

my.cnfДобавьте следующую конфигурацию, перезапустите MySQL, чтобы включить кеш запросов.

query_cache_type=1
query_cache_size=600000

MySQL также может открыть кеш запросов, выполнив следующую команду

set global  query_cache_type=1;
set global  query_cache_size=600000;

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

После создания кэша система кэширования запросов MySQL будет отслеживать каждую таблицу, участвующую в запросе.Если эти таблицы (данные или структура) изменятся, то все кэшированные данные, относящиеся к этой таблице, станут недействительными.

Хотя кеш может повысить производительность запросов к базе данных, кеш также создает дополнительные накладные расходы.После каждого запроса необходимо выполнить операцию с кэшем, которая должна быть уничтожена по истечении срока ее действия.Поэтому включайте кеш запросов с осторожностью, особенно для приложений, интенсивно использующих запись. Если он включен, обратите внимание на разумное управление размером кэш-памяти, вообще говоря, целесообразнее установить размер в несколько десятков МБ. также,Вы также можете контролировать необходимость кэширования оператора запроса с помощью sql_cache и sql_no_cache:

select sql_no_cache count(*) from usr;

дела

Что такое бизнес?

Одним словом,Транзакция — это логический набор операций, либо все операции, либо ни одна из них.

Можете ли вы привести пример?

В качестве примера перевода часто используется самая классическая транзакция. Если Сяомин хочет перевести 1000 юаней Сяохуну, этот перевод будет включать две ключевые операции:

  1. Уменьшите баланс Сяо Мина на 1000 юаней.
  2. Увеличьте баланс Сяохун на 1000 юаней.

Транзакции могут обрабатывать эти две операции как логическое целое, и операции, содержащиеся в этом целом, могут быть успешными или неудачными.

Таким образом, не будет ситуации, когда баланс Сяомина уменьшается, а баланс Сяохун не увеличивается.

Что такое транзакции базы данных?

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

Обычно, когда мы говорим о делах, если нет конкретногоРаспределенная транзакция, часто ссылаясь натранзакция базы данных.

Какова роль транзакций базы данных?

Проще говоря: транзакции базы данных могут гарантировать, что несколько операций с базой данных (то есть операторов SQL) образуют логическое целое. Операции с базой данных, составляющие это логическое целое, следующие:Либо все они выполняются успешно, либо все они не выполняются.

# 开启一个事务
START TRANSACTION;
# 多条 SQL 语句
SQL1,SQL2...
## 提交事务
COMMIT;

Кроме того, реляционные базы данных (например:MySQL,SQL Server,Oracleи т.д.) дела естьACIDхарактеристика:

事务的特性

Что такое функция ACID?

  1. атомарность(Atomicity): транзакция является наименьшей единицей выполнения и не допускает разделения. Атомарность транзакций гарантирует, что действия либо завершатся, либо вообще ничего не сделают;
  2. последовательность(Consistency
  3. изоляция(Isolation): при одновременном доступе к базе данных транзакция пользователя не зависит от других транзакций, и база данных независима от параллельных транзакций;
  4. Упорство(Durabilily): после фиксации транзакции. Его изменения данных в базе данных являются постоянными и не должны иметь никакого влияния на базу данных, даже если произойдет сбой.

Каков принцип реализации транзакции данных?

Здесь мы возьмем движок MySQL InnoDB в качестве примера, чтобы кратко рассказать о нем.

Механизм MySQL InnoDB используетжурнал повторовгарантированный бизнесУпорство,использоватьжурнал отмены (журнал отката)для обеспечения бизнесаатомарность.

Механизм MySQL InnoDB череззамок механизм,MVCCи другие средства для обеспечения изоляции транзакций (поддерживаемый уровень изоляции по умолчанию —REPEATABLE-READ).

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

Какие проблемы приносят параллельные транзакции?

В типичном приложении несколько транзакций выполняются одновременно, часто работая с одними и теми же данными для выполнения соответствующих задач (несколько пользователей работают с одними и теми же данными). Хотя параллелизм необходим, он может вызвать следующие проблемы.

  • Грязное чтение:Когда транзакция обращается к данным и вносит изменения в данные, и это изменение не было зафиксировано в базе данных, другая транзакция также получает доступ к данным, а затем использует данные. Поскольку эти данные являются незафиксированными, данные, считанные другой транзакцией, являются «грязными данными», и операции, основанные на «грязных данных», могут быть неверными.
  • Потеряно для изменения:Это означает, что когда транзакция читает данные, другая транзакция также получает доступ к данным, а затем после изменения данных в первой транзакции вторая транзакция также изменяет данные. Таким образом, результат модификации в первой транзакции теряется, поэтому это называется потерянной модификацией. Например: транзакция 1 считывает данные A=20 в таблице, транзакция 2 также считывает A=20, транзакция 1 изменяет A=A-1, транзакция 2 также изменяет A=A-1, окончательный результат A=19, транзакция модификация 1 утеряна.
  • Неповторимое чтение:Относится к чтению одних и тех же данных несколько раз в рамках транзакции. Пока эта транзакция не завершена, другая транзакция также обращается к данным. Затем между двумя чтениями данных в первой транзакции данные, дважды считанные первой транзакцией, могут не совпадать из-за модификации второй транзакции. Бывает такое, что данные, прочитанные дважды в транзакции, не совпадают, поэтому такое чтение называется неповторяющимся чтением.
  • Призрак читал:Фантомные чтения похожи на неповторяющиеся чтения. Это происходит, когда одна транзакция (T1) читает несколько строк данных, а затем другая параллельная транзакция (T2) вставляет некоторые данные. В последующем запросе первая транзакция (T1) найдет еще несколько записей, которых не было, как будто произошла галлюцинация, поэтому она называется галлюцинацией.

Разница между неповторяемым чтением и фантомным чтением:

Основное внимание при неповторяемом чтении уделяется изменению, например, многократному чтению записи и обнаружению того, что значения некоторых столбцов были изменены.

Что такое уровни изоляции транзакций?

Стандарт SQL определяет четыре уровня изоляции:

  • READ-UNCOMMITTED (чтение незафиксированных):Самый низкий уровень изоляции, позволяющий читать изменения данных, которые еще не были зафиксированы,Может вызвать грязное чтение, фантомное чтение или неповторяющееся чтение..
  • ПРОЧИТАНО:Позволяет читать данные, которые были зафиксированы параллельными транзакциями,Грязные чтения можно предотвратить, но фантомные или неповторяющиеся чтения все же могут происходить..
  • REPEATABLE-READ (повторяемое чтение):Результаты многократного чтения одного и того же поля согласуются, если только данные не изменены самой транзакцией.Грязные чтения и неповторяющиеся чтения можно предотвратить, но фантомные чтения все еще могут возникать..
  • СЕРИАЛИЗУЕМЫЙ (сериализуемый):Самый высокий уровень изоляции, полностью соответствующий уровням изоляции ACID. Все транзакции выполняются одна за другой, так что абсолютно исключена возможность вмешательства между транзакциями, т.е.Этот уровень предотвращает грязные чтения, неповторяемые чтения и фантомные чтения..

уровень изоляции грязное чтение неповторяемое чтение галлюцинации
READ-UNCOMMITTED
READ-COMMITTED ×
REPEATABLE-READ × ×
SERIALIZABLE × × ×

Каков уровень изоляции MySQL по умолчанию?

Поддерживаемые по умолчанию уровни изоляции для механизма хранения MySQL InnoDB:ПОВТОРЯЕМОСТЬ-ЧТЕНИЕ. мы можем пройтиSELECT @@tx_isolation;команда для просмотра, MySQL 8.0 команда изменена наSELECT @@transaction_isolation;

mysql> SELECT @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+

Здесь следует отметить, что отличие от стандарта SQL заключается в том, что механизм хранения InnoDBПОВТОРЯЕМОСТЬ-ЧТЕНИЕАлгоритм Next-Key Lock используется на уровне изоляции транзакций, поэтому он позволяет избежать генерации фантомных операций чтения, что отличается от других систем баз данных (таких как SQL Server). Таким образом, уровень изоляции по умолчанию, поддерживаемый механизмом хранения InnoDB, равенПОВТОРЯЕМОСТЬ-ЧТЕНИЕТребования к изоляции транзакций уже могут быть полностью гарантированы, то есть те, которые соответствуют стандарту SQL.SERIALIZABLE (сериализуемый)уровень изоляции.

🐛 Исправления:REPEATABLE-READ (повторяемое чтение) MySQL InnoDB не гарантирует отсутствие фантомных чтений, и приложения должны использовать заблокированные чтения, чтобы гарантировать это. Для этой степени блокировки используется механизм Next-Key Locks.

Поскольку чем ниже уровень изоляции, тем меньше блокировок требует транзакция, поэтому уровень изоляции большинства систем баз данных ниже.READ-COMMITTED (чтение коммитов), но вам нужно знать, что механизм хранения InnoDB использует стандартнуюПОВТОРЯЕМОСТЬ-ЧТЕНИЕШтрафа за производительность нет.

Механизм хранения InnoDBРаспределенная транзакцияобычно используется вSERIALIZABLE (сериализуемый)уровень изоляции.

🌈 Разверните его (следующее выдержки из «MySQL Technology Insider: InnoDB Storage Engine (2-е издание)», глава 7.7):

Механизм хранения InnoDB обеспечивает поддержку транзакций XA и поддерживает реализацию распределенных транзакций посредством транзакций XA. Распределенные транзакции позволяют нескольким независимым транзакционным ресурсам участвовать в глобальной транзакции. Транзакционные ресурсы обычно представляют собой реляционные системы баз данных, но могут быть и другими типами ресурсов. Глобальная транзакция требует, чтобы все участвующие транзакции либо зафиксировали, либо откатились, что улучшает исходные требования ACID к транзакции. Кроме того, при использовании распределенных транзакций уровень изоляции транзакций механизма хранения InnoDB должен быть установлен в SERIALIZABLE.

постскриптум

Наконец, я рекомендую очень хороший проект с открытым исходным кодом учебного класса Java:JavaGuide. Я создал проект JavaGuide, когда начал готовиться к осеннему собеседованию на первом курсе. В настоящее время у этого проекта более 100 000 звезд, по теме:"1049 дней, 100 тысяч! Простой обзор! 》.

Отлично подходит для изучения Java и подготовки к собеседованиям по Java! По словам автора, это:Обучение Java + руководство по собеседованию, охватывающее основные знания, которые необходимо освоить большинству Java-программистов!

связанное предложение:

Я гид, я пользуюсь открытым исходным кодом и люблю готовить. проект с открытым исходным кодомJavaGuideАвтор, Гитхаб:Snailclimb - Overview. В следующие несколько лет я надеюсь продолжать улучшать JavaGuide и стремиться помочь большему количеству друзей, изучающих Java! взаимное поощрение! Ляо!Нажмите, чтобы просмотреть мой отчет о работе за 2020 год!

Ссылаться на