инфраструктура MySQL

Диаграмма базовой архитектуры MySQL

В целом,MySQLЕго можно разделитьServerСлой и механизм хранения состоят из двух частей.

• ServerУровни включают коннекторы, кэши запросов, анализаторы, оптимизаторы, исполнители и т. д., охватывающиеMySQLНа этом уровне реализованы большинство основных сервисных функций , а также все встроенные функции (такие как дата, время, математические функции и функции шифрования и т. д.), все функции кросс-хранилища, такие как хранимые процедуры, триггеры. , просмотры и т.д.

  • Соединитель

    Соединитель — это то, что вы используете при подключении к базе данных, и он отвечает за установление соединения с клиентом, получение разрешений, поддержку и управление соединением.
    Заказ:mysql -h$ip -P$port -u$user -p, введите пароль после нажатия Enter, либо введите пароль после -p, но есть риск утечки пароля.

    show processlist, Вы можете просмотреть состояние соединения.В колонке Command стоит Sleep, указывающий на то, что соединение находится в режиме ожидания.
    Бездействующие соединения будут отключены по умолчанию на 8 часов, что можно настроить параметром wait_timeout.

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

    Поскольку установление соединения потребляет ресурсы, рекомендуется максимально использовать длинное соединение.Однако после использования длинного соединения память, занимаемая MySQL, увеличивается очень быстро.Это связано с тем, что память, временно используемая MySQL в процессе выполнения управляется в объекте соединения. Эти ресурсы будут освобождены только при отключении соединения. Таким образом, если накапливаются длинные соединения, это может привести к чрезмерному использованию памяти и принудительному уничтожению системой (OOM).Из-за этого MySQL перезапускается ненормально.

    решение:

    1. Периодически отключайте длинные соединения. После его использования в течение определенного периода времени или после того, как будет установлено, что в программе был выполнен большой запрос, занимающий память, соединение разрывается, а затем необходимо повторно подключить запрос.
    2. Если вы используете MySQL 5.7 или новее, вы можете выполнить более крупную операцию, выполнивmysql_reset_connectionдля повторной инициализации ресурса подключения. Этот процесс не требует повторного подключения и повторной аутентификации, но восстанавливает соединение до состояния, в котором оно было только что создано.

  • кэш запросов
    Кэширование запросов — это способ хранения ранее выполненных операторов и их результатов вkey-valueФорма пары кэшируется в памяти. Ключ — это оператор запроса, а значение — результат запроса. Если ваш запрос может найти ключ непосредственно в этом кеше, то значение будет возвращено непосредственно клиенту. Кэш запросов был удален в MYSQL8, а количество попаданий было низким из-за частого аннулирования кеша запросов.

  • Анализатор
    Анализатор сначала проведет «лексический анализ», чтобы определить, что представляют собой строки внутри и что они представляют. Затем вам нужно выполнить «синтаксический анализ», чтобы определить, удовлетворяет ли введенный вами оператор SQL синтаксису MySQL.

  • оптимизатор

  • Актуатор

• Уровень механизма хранения отвечает за хранение и извлечение данных. Его архитектурный шаблон подключаемый и поддерживаетInnoDB、MyISAM、Memoryи другие механизмы хранения. На сегодняшний день наиболее часто используемым механизмом хранения являетсяInnoDB, начинается сMySQL 5.5.5Версия стала механизмом хранения по умолчанию.

одинSelectПоток выполнения инструкции

На приведенном выше рисунке в качестве примера используется механизм хранения InnoDB Процесс обработки выглядит следующим образом:

• Пользователь отправляет запрос наtomcat,пройти черезtomcatпул ссылок иmysqlПул соединений устанавливает соединение, а затем отправляет операторы SQL через соединение вMySQL;

• MySQLСуществует отдельный поток прослушивания, который считывает данные запроса и получает оператор SQL, запрошенный в соединении;

• Отправить полученные данные SQL в интерфейс SQL для выполнения;

• Интерфейс SQL отправляет SQL парсеру SQL для разбора;

• Отправьте проанализированный SQL оптимизатору запросов, найдите оптимальный путь запроса и отправьте его исполнителю;

• Исполнитель вызывает интерфейс механизма хранения в соответствии с оптимизированным планом выполнения для выполнения в определенном порядке и шагах.
  Например, например, исполнитель может сначала вызвать интерфейс механизма хранения для получения первой строки данных в таблице «users», а затем определить, равно ли значение поля «id» этих данных значение, которое мы ожидаем, Если нет, то продолжаем вызывать интерфейс механизма хранения, чтобы получить следующую строку данных в таблице «users». Основываясь на вышеизложенных идеях, исполнитель будет переходить к набору планов выполнения, сгенерированных нашим оптимизатором, а затем постоянно вызывать различные интерфейсы механизма хранения для выполнения плана выполнения оператора SQL, который примерно постоянно обновляет или извлекает какие-то данные. вне.

Здесь возникает несколько вопросов:

• Что такое драйвер MySQL? Взяв в качестве примера java, если мы хотим получить доступ к базе данных MySQL в системе Java, мы должны добавить драйвер MySQL к системным зависимостям, таким как Maven.

  <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>5.1.46</version>
  </dependency>
  

  Так что же это за драйвер MySQL?На самом деле драйвер L устанавливает сетевое соединение с базой данных на нижнем уровне.При сетевом соединении он может отправлять запросы на сервер базы данных! Позвольте системе, написанной на языке, получить доступ к базе данных через драйвер MySQL, как показано ниже.

• Для чего используется пул соединений с базой данных?
  Предполагая, что веб-служба разработана на java и развернута на tomcat, tomcat может обрабатывать запросы одновременно с несколькими потоками, поэтому первый момент заключается в том, что невозможно создать только одно соединение с базой данных (несколько запросов для захвата соединения, что очень неэффективно). ).
  Во-вторых, что, если каждый запрос создает соединение с базой данных? Это тоже очень плохо, потому что каждый раз требуется время для установления соединения с базой данных. часто вызывает проблемы с производительностью.
  Поэтому обычно используется пул соединений с базой данных, то есть в пуле поддерживается несколько соединений с базой данных, а несколько потоков используют в нем разные соединения с базой данных для выполнения операторов SQL.После выполнения операторов SQL не разрушайте соединение с базой данных, а Поместите соединение обратно в пул, и вы сможете продолжить использовать его позже. На основе такого механизма пула соединений с базой данных может быть решена проблема одновременного использования несколькими потоками нескольких соединений с базой данных для выполнения операторов SQL, а также можно избежать проблемы разрушения соединений с базой данных после использования.
  

• Для чего используется пул соединений базы данных MySQL?
  Функция пула соединений базы данных MySQL такая же, как у пула соединений на стороне приложения Java, и он играет роль мультиплексирования соединений.

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

InnoDBАнализ архитектуры

Как видно из рисунка,InnoDBмеханизм храненияпул памяти,фоновая нитьифайл на дискесостоит из трех частей

Вот еще одна картинка, которая выделяет ключевые моменты:

Но приведенные выше картинки слишком сложно запомнить, вот краткая картинка:

InnoDBМеханизм хранения, часть 1: структура памяти

Buffer Poolбуферный пул

InnoDBМеханизм хранения основан на дисковом хранилище и управляет записями в нем как страницами, но из-за разрыва между скоростью ЦП и скоростью диска дисковые системы баз данных обычно используют записи пула буферов для повышения общей производительности базы данных.

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

Для операций модификации страниц в базе данных сначала изменяются страницы в пуле буферов, а затем с определенной периодичностью сбрасываются на диск.Сброс страниц из пула буферов на диск не запускается каждый раз при обновлении страницы, но черезCheckPointмеханизм для сброса обратно на диск. Поэтому размер пула буферов напрямую влияет на общую производительность базы данных, которую можно настроить, настроив параметрыinnodb_buffer_pool_sizeЧтобы установить, буферный пул по умолчанию составляет 128 МБ, что все еще немного мало.Если ваша база данных представляет собой 16-ядерную машину 32G, вы можете указатьBuffer PoolВыделите 2 ГБ памяти.

Поскольку пул буферов не бесконечен, поскольку страницы данных на диске постоянно загружаются в пул буферов, пул буферов всегда будет использоваться. В это время можно удалить только некоторые страницы кэша. Метод исключения использует наименьший Недавно Используйте алгоритм (LRU), специально для введения нового связанного списка LRU, с помощью этого связанного списка LRU вы можете узнать, какие страницы кеша использовались наименее недавно, а затем, когда вам нужно освободить страницу кеша, чтобы сбросить на диск , Для вытеснения можно выбрать наименее использовавшуюся страницу кэша в этом списке LRU.

Типы страниц данных, кэшированных в пуле буферов:Страница индекса, страница данных, страница отмены, буфер вставки, адаптивный хэш-индекс, информация о блокировке и информация словаря данных, хранящаяся в InnoDB..

страницы данных и индексные страницы

Страница(Page)ДаInnodbСамая основная структура хранилища такжеInnodbНаименьшая единица управления дисками, все, что связано с базой данных, хранится вPageв структуре.PageРазделенные на несколько типов, страницы данных и индексные страницы являются двумя наиболее важными типами.

Вставить буфер (Insert Buffer)

существуетInnoDBПри вставке в движок обычно необходимо вставлять в порядке первичного ключа, чтобы получить более высокую производительность вставки. Когда в таблице присутствует некластеризованный неуникальный индекс, при вставке страницы данных сохраняются в порядке первичного ключа, но вставка листовых узлов некластеризованного индекса уже не является последовательной, то необходимо Дискретный доступ к некластеризованным страницам индекса приводит к низкой производительности вставки из-за случайного чтения.

такInnoDBМеханизм хранения имеет революционную конструкциюInsert Buffer, для операции вставки или обновления некластеризованного индекса он не вставляется каждый раз напрямую в страницу индекса, а сначала оценивает, находится ли вставленная некластеризованная страница индекса в буферном пуле, если да, то вставляет ее напрямую; если нет, поместите его сначала вInsert Bufferвозразить, как бы обмануть. Некластеризованный индекс базы данных был вставлен в конечный узел, но фактически не хранится в другом месте. Затем при определенной частоте и ситуацииInsert BufferОперации слияния с подузлами вторичных страниц индекса, где несколько вставок обычно можно объединить в одну операцию (потому что в одной странице индекса), что значительно повышает производительность вставок для некластеризованных индексов.

тем не мениеInsert BufferДля использования необходимо одновременное выполнение следующих двух условий:

• Индекс является вторичным индексом (secondary index);
• Индексы не уникальны.

При соблюдении двух вышеуказанных условийInnoDBМеханизм хранения будет использоватьInsert Buffer, что повышает производительность операций вставки. Но рассмотрим такую ​​ситуацию: приложение выполняет большое количество операций вставки, в которых задействованы неуникальные некластеризованные индексы, то есть используютInsert Buffer. Если база данных MySQL не работает в это время, будет большое количествоInsert BufferНе объединены с фактическим некластеризованным индексом.
Поэтому восстановление может занять много времени, в крайних случаях даже несколько часов. Вспомогательные индексы не могут быть уникальными, потому что база данных не просматривает страницу индекса, чтобы определить уникальность вставленной записи при вставке в буфер. Если пойти искать, то обязательно будут дискретные чтения, которые приведут кInsert Bufferпотерял смысл.

по командеSHOW ENGINE INNODB STATUSдля просмотра информации о буфере вставки

seg size показывает, что размер текущего буфера вставки составляет 11336×16 КБ, что составляет около 177 МБ; len списка свободных мест представляет длину списка свободных мест; size представляет количество страниц объединенных записей. И строка 2, выделенная жирным шрифтом, вероятно, действительно волнует пользователей, так как она показывает увеличение производительности вставки. Inserts представляет количество вставленных записей; merged recs представляет количество объединенных вставленных записей; merges представляет количество слияний, то есть количество фактически прочитанных страниц. слияния: объединенные записи составляют примерно 1:3, что означает, что буферы вставки сокращают дискретные логические запросы ввода-вывода для некластеризованных индексных страниц примерно на 2/3.
Как было сказано ранее, на данный момент существует проблема с Insert Buffer: в случае интенсивной записи буфер вставки будет занимать слишком много памяти буферного пула (innodb buffer pool), а по умолчанию максимум может занимать 1/2 памяти буферного пула . Ниже приведена операция инициализации буфера вставки в исходном коде механизма хранения InnoDB:

Change Buffer

InnoDBВведено с версии 1.0.xChange Buffer, что можно рассматривать какInsert Bufferобновленная версия,InnodBМеханизм хранения может работать на DML —INSERT,DELETE,UPDATEбуферизуются, они:Insert Buffer,Delete Buffer,Purge bufferконечно и раньшеInsert BufferТакой же,Change BufferПрименимые объекты по-прежнему не являются уникальными вторичными индексами. на записиUPDATEОперацию можно разделить на два процесса:

• пометить запись как удаленную;
• на самом деле удалить запись

следовательноDelete BufferсоответствоватьUPDATEПервая часть операции заключается в том, чтобы пометить запись для удаления.PurgeBufferсоответствоватьUPDATEВторой процесс операции касается записи фактического удаления. в то же время,InnoDBМеханизм хранения предоставляет параметрыinnodb_change_buffering, используется для открытия различных параметров буфера. Необязательные значения для этого параметра:Inserts,deletes,purges,changes,all,none.Inserts,deletes,purgesЭто три случая, рассмотренные выше.changesУказывает, что включеноInsertsиdeletes,all означает включить все, none означает ничего. Значение этого параметра по умолчанию — все. Начиная с версии InnoDB1.2.x, вы можете передать параметрinnodb_change_buffer_max_sizeконтролироватьChange BufferМаксимальный объем используемой памяти:

mysql> show variables like 'innodb_change_buffer_max_size';
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| innodb_change_buffer_max_size | 25    |
+-------------------------------+-------+
1 row in set (0.05 sec)

innodb_change_buffer_max_sizeЗначение по умолчанию равно 25, что означает, что используется не более 1/4 объема памяти буферного пула. Следует отметить, что максимально допустимое значение этого параметра равно 50 в MySQL 5.5 через командуSHOW ENGINE INNODB STATUS, вы можете наблюдать что-то похожее на следующее:

Вы можете увидеть, как это отображается здесьmerged operationsиdiscarded operation, и следующий конкретный дисплейChange BufferКоличество раз для каждой операции в .InsertвыражатьInsert Buffer; delete markвыражатьDelete Buffer; deleteвыражатьPurge Buffer; discarded operationsозначает, когдаChange BufferпроисходитьmergeКогда таблица удалена, нет необходимости объединять записи во вторичный индекс.

Адаптивный хэш-индекс

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

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

информация о блокировке (lock info)

мы все знаем,InnoDBМеханизм хранения блокирует данные таблицы на уровне строки, ноInnoDBОткройте таблицу, добавьте соответствующий объект в словарь данных.

Словарь данных

Набор метаинформации о данных в базе данных, библиотечных объектах, табличных объектах и ​​т. д. В MySQL содержимое информации словаря данных включает в себя структуру таблицы, имя базы данных или имя таблицы, тип данных поля, представление, индекс, информацию о поле таблицы, хранимую процедуру, триггер и т. д.INFORMATION_SCHEMAБиблиотека предоставляет метаданные, статистику и информацию о доступе к серверу MySQL (например: имя базы данных или таблицы, тип данных поля и права доступа и т. д.). Информация, хранящаяся в этой библиотеке, также может называться словарем данных MySQL.

механизм опережающего чтения

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

При каких обстоятельствах сработает механизм упреждающего чтения MySQL?

1. Одним из параметров является innodb_read_ahead_threshold, и его значение по умолчанию равно 56, что означает, что если доступ к нескольким страницам данных в области осуществляется последовательно, и количество страниц данных, к которым осуществляется доступ, превышает этот порог, будет запущен механизм упреждающего чтения, и сработает механизм forward, в кэш загружаются все страницы данных в следующем смежном экстенте.

2. Если 13 последовательных страниц данных в области кэшируются в буферном пуле и к этим страницам данных часто обращаются, механизм предварительного чтения будет запущен напрямую, и все остальные страницы данных в этой области будут автоматически загружаться в кэш. управляется параметром innodb_random_read_ahead, который по умолчанию выключен, то есть это правило выключено.

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

Преимущество механизма упреждающего чтения заключается в повышении производительности. Предположим, вы прочитали страницу данных 01 в кэш-страницу, тогда можно последовательно прочитать в кэш-страницу страницу данных 02, примыкающую к странице данных 01. В это время возможно ли прочитать страницу данных? снова инициировать дисковый ввод-вывод в 02?
Поэтому, чтобы оптимизировать производительность, MySQL разработал механизм упреждающего чтения, который означает, что если вы находитесь в какой-либо области, вы последовательно прочитали много страниц данных, например, страницы данных с 01 по 56 были прочитаны последовательно. MySQL будет судить, вы можете продолжить последовательное чтение следующих страниц данных. Затем в это время большое количество последующих страниц данных (таких как страница данных 57 до страницы данных 72) заранее считываются в пул буферов.

Управление памятью буферного пула

Здесь нужно понимать три связанных списка (Free List,Flush List,LRU List),

• Free List
  Страницы данных и страницы кэша на диске находятся во взаимно однозначном соответствии, обе по 16 КБ, и одна страница данных соответствует одной странице кэша. База данных будетBuffer Poolдизайн одинfreeСвязный список, он представляет собой структуру данных двусвязного списка, этоfreeВ связанном списке каждый узел является адресом блока данных описания свободной страницы кеша, то есть, пока одна из ваших страниц кеша свободна, его блок данных описания будет помещен в этотfreeв связанном списке. Когда база данных запускается впервые, все страницы кэша могут быть свободны, потому что в это время это может быть пустая база данных без данных, поэтому блоки данных описания всех страниц кэша в это время будут помещены в этот блок.freeсвязанный список, среди прочего, этоfreeСвязанный список имеет базовый узел, который ссылается на головной узел и хвостовой узел связанного списка, а также хранит количество узлов в связанном списке, описывающих блок данных, то есть сколько свободных страниц кэша имеется.

• Flush ListиFree ListПодобно связанному списку,flushСуть связанного списка заключается в использовании двух указателей в блоке данных описания страницы кэша, чтобы сделать блок данных описания модифицированной страницы кэша двусвязным списком. Для любой кешированной страницы, которая была изменена, ее блок данных описания будет добавлен вflushк связанному списку,flushЭто означает, что это грязные страницы, и продолжение должноflushслить на диск.

• LRU ListПоскольку размер буферного пула фиксирован, другими словамиfreeДанные свободной страницы кеша в связанном списке определены.Когда вы продолжаете загружать страницы данных на диске в свободные страницы кеша,freeСвободные страницы кеша постоянно удаляются из связанного списка, и рано или поздно наступит момент,freeВ связанном списке нет свободных страниц кеша. В настоящее время необходимо удалить некоторые страницы кеша. Кого следует удалить? Это требует использования частоты попаданий в кеш. Обычно используются те, у которых больше попаданий в кеш, а те, которые обычно не используются, могут быть исключены. Так что импортLRUСвязанный список используется для определения того, какие кэшированные страницы обычно не используются.

  Какова стратегия ликвидации связанного списка LRU?
  Предположим, что когда мы загружаем страницу данных с диска на страницу кеша, мы помещаем блок данных описания страницы кеша в заголовок связанного списка LRU, тогда пока есть страница кеша с данными, она будет находиться в LRU и загружен недавно. Кэшированные страницы данных будут помещены в начало связанного списка LRU, а затем кешированная страница будет добавлена ​​в хвост. Пока происходит запрос, он будет перемещен в голову , а затем последний хвост нужно удалить.

  Но действительно ли это возможно?

  • В первом случае нарушается механизм предварительного чтения.
    Поскольку механизм упреждающего чтения загружает в кеш соседние страницы данных, к которым еще не было доступа, фактически осуществляется доступ только к одной странице кеша, а к другой странице кеша, загруженной с помощью механизма упреждающего чтения, фактически никто не обращается. страницы кэша могут находиться перед списком LRU, как показано нижеВ это время, если свободной страницы кэша нет, то в это время необходимо загрузить новую страницу данных.Необходимо ли вынимать из конца связанного списка LRU так называемую "наименее использовавшуюся страницу кэша" и сбросить на диск?Тогда освободите свободную страницу кеша. Это, очевидно, очень неразумно.

  • Второй сценарий может привести к удалению часто используемых страниц кэша.
    Полное сканирование таблицы заставило его напрямую загрузить все страницы данных в таблице с диска в буферный пул. В это время все страницы данных этой таблицы могут быть загружены в каждую страницу кэша одна за другой! В настоящее время большая серия страниц кеша в начале связанного списка LRU может оказаться всеми страницами кеша, загруженными при полном сканировании таблицы! Так что, если данные в этой таблице практически не используются после полного сканирования таблицы? В это время хвост списка LRU может быть теми страницами кэша, к которым раньше часто обращались! Затем, когда вы захотите удалить некоторые страницы кэша, чтобы освободить место, страницы кэша, к которым часто обращались в конце связанного списка LRU, будут удалены, оставив большое количество редко используемых страниц кэша, загруженных предыдущим полным сканированием таблицы. Кэшировать страницы!

  Оптимизированный алгоритм LRU: Дизайн связанного списка LRU основан на идее разделения горячих и холодных данных.
  Когда MySQL разработала связанный список LRU, она фактически приняла идею разделения горячих и холодных данных. Связанный список LRU будет разделен на две части: одна — «горячие» данные, а другая — «холодные» Соотношение «горячих» и «холодных» данных определяетсяinnodb_old_blocks_pctДля управления параметрами он по умолчанию равен 37, значит, на холодные данные приходится 37%. Когда страница данных впервые загружается в кэш, кэшированная страница фактически помещается в начало связанного списка в области холодных данных.

  Затем MySQL установил правило, он разработалinnodb_old_blocks_timeПараметр, значение по умолчанию 1000, что составляет 1000 миллисекунд.То есть он должен быть после загрузки страницы данных в страницу кеша.Через 1с, когда вы обращаетесь к странице кеша, она будет перемещена в начало связанный список в области горячих данных. Потому что, если вы загружаете страницу данных в кеш, а затем получаете доступ к странице кеша через 1 с, это означает, что вы, вероятно, будете часто обращаться к ней в будущем.Ограничение по времени составляет 1 с, поэтому вы получаете доступ к этой странице только через 1 с. Кэшированные страницы, он передаст вам кешированные страницы в начало связанного списка в области горячих данных.
  В этом случае данные предварительного чтения и полного сканирования таблицы будут находиться только в заголовке холодных данных, а не попадут в область горячих данных в начале.

  Экстремальная оптимизация алгоритма LRU
  Оптимизировать правила доступа к области горячих данных связанного списка LRU, то есть только при доступе к страницам кэша в последних 3/4 области горячих данных они будут перемещены в начало связанного списка . Если вы обращаетесь к первой 1/4 страницы кэша в области горячих данных, она не переместится в начало связанного списка.

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

  Связанный список LRU для устранения времени кэширования страниц
  MySQLв исполненииCRUDВо-первых, это большое количество страниц кэша операций и несколько связанных с ними списков. Затем, когда страницы кеша заполнены, вы должны найти способ сбросить некоторые страницы кеша на диск, затем очистить эти страницы кеша, а затем загрузить необходимые страницы данных в страницы кеша!

  Мы уже знаем, что он удаляет страницы кеша согласно связанному списку LRU, так когда именно он сбрасывал на диск страницы кеша в области холодных данных связанного списка LRU? На самом деле у него есть следующие три возможности:

  • Периодически сбрасывать некоторые кешированные страницы в конце LRU на диск.
    Фоновый поток запускает запланированное задание.Это запланированное задание будет через равные промежутки времени сбрасывать на диск некоторые страницы кеша в конце области холодных данных связанного списка LRU, очищать эти страницы кеша и добавлять их обратно на диск. .freeперейти к связанному списку.

  

  • ПучокflushНекоторые страницы кеша в связанном списке периодически сбрасываются на диск.
    Недостаточно просто сбросить на диск страницы кеша области холодных данных связанного списка LRU, потому что многие страницы кеша в области горячих данных связанного списка также могут часто изменяться. слил на диск?
    Таким образом, этот фоновый поток также будетMySQLКогда не очень занят, ставьflushВсе страницы кэша в связанном списке сбрасываются на диск, поэтому измененные вами данные рано или поздно будут сброшены на диск!
    если толькоflushВолна страниц кеша в связанном списке сбрасывается на диск, затем эти страницы кеша также будутflushсвязанный список иlruУдалено из связанного списка, затем добавлено вfreeПерейти к списку!

    Таким образом, общий эффект заключается в том, чтобы продолжать загружать данные в кэшированную страницу, постоянно запрашивая и изменяя кэшированные данные, а затемfreeКэшированные страницы в связанном списке продолжают уменьшаться,flushКэшированные страницы в связанном списке продолжают увеличиваться,lruКэшированные страницы в связанном списке постоянно увеличиваются и перемещаются.
    С другой стороны, ваш фоновый поток продолжает помещатьlruкэшированные страницы области холодных данных связанного списка иflushСтраница кеша связанного списка сбрасывается на диск, чтобы очистить страницу кеша, а затемflushсвязанный список иlruКоличество кэшированных страниц в связанном списке уменьшается,freeКэшированные страницы в связанном списке увеличиваются.

  • freeВ связанном списке нет свободных страниц кеша
    я упалfreeБыл использован связанный список.В настоящее время, если вы хотите загрузить страницу данных с диска на свободную страницу кеша, страница кеша будет найдена в конце области холодных данных связанного списка LRU.Это должна быть наименее часто используемой страницей кэша. ! Затем сбросьте его на диск и сбросьте, затем загрузите страницу данных в эту бесплатную страницу кэша!

Подводя итог, использование трех связанных списков,Buffer PoolПри использовании он будет часто загружать страницы данных с диска в свои кэш-страницы, а затемfreeсвязанный список,flushсвязанный список,lruСвязанный список будет использоваться одновременно, например, при загрузке данных на страницу кеша,freeКэшированная страница будет удалена из связанного списка, а затемlruЗаголовок области холодных данных связанного списка размещается на этой странице кеша.

Затем, если вы измените кешированную страницу, тоflushЭта грязная страница будет записана в связанный список,lruСвязанный список также может переместить вас из области холодных данных в начало области горячих данных.

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

Redo log Bufferбуферизация журнала повторов

InnoDBимеютbuffer pool(сокращенно бп). bp - это кеш страниц базы данных, правильноInnoDBЛюбая операция модификации bp сначала будетpageon, то такие страницы будут отмечены какdirty(грязные страницы) и помещаются в специальныйflush list, продолжение будетmaster threadИли выделенный грязный поток периодически записывает эти страницы на диск (disk or ssd).

Преимущество этого заключается в том, чтобы избежать большого количества случайных операций ввода-вывода, вызванных работой диска для каждой операции записи, а периодическое загрязнение может многократно изменять страницу.mergeв операцию ввода-вывода, а асинхронная запись также снижает задержку доступа. Однако, если вdirty pageПеред прошивкой на дискserverВ случае нештатного завершения работы эти операции модификации будут потеряны, а если выполняются операции записи, база данных может быть даже недоступна из-за поврежденных файлов данных.

Во избежание вышеуказанных проблем,InnodbЗаписывайте все операции модификации страниц в специальный файл и восстанавливайте операции из этого файла при старте базы данных.redo log file. Такая технология задерживает обновление страницы bp, тем самым повышая пропускную способность базы данных и эффективно сокращая задержку доступа.
Проблема в том, что лишняя записьredo logНакладные расходы на операцию (последовательный ввод-вывод, который, конечно, быстрый) и время, необходимое для возобновления операции при запуске базы данных.

redoЖурнал состоит из двух частей:redo log buffer,redo log file(Представлено в разделе о дисковых файлах).innodbЭто механизм хранения, который поддерживает транзакции.Когда транзакция зафиксирована, все журналы транзакции должны быть записаны вredoВ файле журнала ожидающие транзакцииcommitВся операция транзакции завершается, когда операция завершена. каждый раз, когдаredo log bufferнаписатьredo log fileПосле этого нужно позвонить один разfsyncоперация, потому что буферизация журнала повторов сначала записывает содержимое только в буферную систему операционной системы и не гарантирует, что оно будет записано непосредственно на диск, поэтому это необходимо сделать один раз.fsyncработать. Таким образом, производительность диска также в определенной степени определяет производительность отправки транзакций (особенно позже).redo logЗнакомство с механизмом падения). InnoDBМеханизм хранения сначала помещает информацию журнала повторов в буфер журнала повторов, а затем с определенной периодичностью сбрасывает ее в файл журнала повторов. часы будут сбрасывать буфер журнала повторов в файл журнала, который можно настроить с помощью параметровInnodb_log_buffer_sizeУправление, по умолчанию 8 МБ.

Double Writeдвойная запись

если мы предположимInsert BufferдаватьInnoDBМеханизм хранения обеспечивает повышение производительности, а затемDouble wtiteприноситьInnoDBМеханизм хранения — надежность страниц данных.

InnoDBизPage SizeОн вообще 16кб, и его проверка данных тоже рассчитана на эти 16кб.Запись данных на диск основана наPageработать на единицу. Мы знаем, что, поскольку файловая система не является атомарной операцией для большой страницы данных (например, 16 КБ InnoDB), в большинстве случаев это означает, что в случае сбоя сервера может быть выполнена только часть записи. 16K данных, при записи 4K система выключаетсяos crash, только часть записи успешна, в данном случае этоpartial page writeпроблема.

Опытный администратор базы данных может подумать, что если произойдет сбой записи, MySQL можетredo logвосстановить. Это подход, но следует четко осознавать, чтоredo logТо, что записывается, является физической модификацией страницы, такой как смещение 800, запись записи «аааа». Если повреждена сама страница, переделывать нет смысла. MySQL проверяет во время восстановленияpageизchecksum,checksumпросто проверьтеpageНомер последней транзакции , произошлоpartial page writeпроблема,pageсломался, не могу найтиpageНомер транзакции в . С точки зрения InnoDB, такие страницы данных не могут проходить черезchecksumПосле проверки его невозможно восстановить. Даже если мы заставим его пройти проверку, он не сможет восстановиться после сбоя, потому что некоторые типы журналов, которые в настоящее время существуют в InnoDB, являются логическими операциями и не могут быть идемпотентными.

Чтобы решить эту проблему, InnoDB реализуетdouble write bufferПроще говоря, это запись страницы данных в независимое физическое расположение файла (ibdata) перед записью страницы данных, а затем запись на страницу данных. Таким образом, во время выключения и перезапуска, если страница данных повреждена, приложениеredo logРаньше страницу нужно было восстанавливать из копии страницы, а потомredo logпеределать, этоdouble write.double writeтехнология приноситinnodbМеханизм хранения - это надежность страницы данных, следующее лицоdoublewriteАнализ технологии

Как показано на фиг.Double WriteСостоит из двух частей, одна часть в памятиdouble write buffer, размер 2 МБ, а другая часть — 128 последовательных страниц общего табличного пространства на физическом диске, и размер тоже 2 МБ. При сбросе грязных страниц буферного пула пишет не напрямую на диск, а черезmemcpyФункция сначала копирует грязные страницы в эту область памяти, а затем передаетdouble write bufferДелится на два раза, каждый 1Мб последовательно записывается на физический диск общего табличного пространства, а потом вызывается сразуfsyncдля синхронизации диска и предотвращения проблем, вызванных буферизацией операций записи операционной системой. по окончанииdouble writeПосле того, как страница написана,double wirite bufferСтраницы записываются в каждый файл табличного пространства.
В этом процессеdoublewriteПоследовательная запись, накладные расходы не большие, после завершенияdoublewriteПосле написания, послеdouble write bufferЗапись в каждый файл табличного пространства, который в настоящее время является дискретным.

Если происходит сбой операционной системы во время записи страницы на диск, во время восстановления,InnoDBМеханизм хранения может получить доступ к общему табличному пространству изdouble writeНайдите копию страницы в , скопируйте ее в файл табличного пространства и примените журнал повторов.

InnoDBМеханизм хранения, часть 2: фоновые потоки

поток ввода-вывода

существуетInnoDBиспользовал многоAIO（Async IO）Выполнять обработку чтения и записи, что может значительно повысить производительность базы данных. существуетInnoDB 1.0Есть 4 версии доIO Thread, соответственнописать, читать, вставлять буфер и логировать поток, более поздние версии будутread threadиwrite threadИх стало 4, всего 10. -read thread: Отвечает за операции чтения, загрузку данных с диска в страницы кэша. 4 -write thread: Отвечает за операции записи, сброс кэшированных грязных страниц на диск. 4 -log thread: отвечает за сброс содержимого буфера журнала на диск. 1 -insert buffer thread: Отвечает за сброс содержимого буфера записи на диск. 1

Purgeнить

После того, как транзакция зафиксирована, он используетundoЖурналы больше не потребуются, поэтомуPurge Threadвернуть выделенныйundoСтраница.show variables like '%innodb*purge*threads%';

Page Cleanerнить

Функция состоит в том, чтобы сбросить грязные данные на диск, и после того, как грязные данные будут сброшены на диск, соответствующиеredo logОн также может быть перезаписан, то есть данные могут быть синхронизированы, и это может быть достигнутоredo logцель утилизации. Будет вызывать обработку потока потока записи.show variables like '%innodb*page*cleaners%';

InnoDBМеханизм хранения, часть 3: файлы на диске

InnoDBОсновные файлы диска в основном разделены на три блока:Одно из них — системное табличное пространство, другое — пользовательское табличное пространство, а третье — табличное пространство.redoлог-файлы и архивы.

бинарный файл(binlong) и т.д. файлыMySQL ServerФайлы, поддерживаемые слоями, поэтому не включеныInnoDBв файле диска.

Системное табличное пространство и пользовательское табличное пространство

Системное табличное пространство содержитInnoDBсловарь данных (метаданные и связанные объекты) иdouble write buffer , change buffer , undo logsзона хранения.
Системное табличное пространство также содержит по умолчанию табличные данные и данные индекса, созданные любым пользователем в системном табличном пространстве.
Системное табличное пространство является общим табличным пространством, потому что оно совместно используется несколькими таблицами.

Системное табличное пространство состоит из одного или нескольких файлов данных. По умолчанию 1 начальный размер составляет 10 МБ с именемibdata1Файлы системных данных создаются в каталоге данных MySQL. пользователь может использоватьinnodb_data_file_pathНастройте размер и количество файлов данных.

innodb_data_file_pathФормат следующий:

innodb_data_file_path=datafile1[,datafile2]...

Пользователи могут формировать табличное пространство с помощью нескольких файлов и одновременно указывать атрибуты файлов:

innodb_data_file_path = /db/ibdata1:1000M;/dr2/db/ibdata2:1000M:autoextend

здесь будет/db/ibdata1и/dr2/db/ibdata2Эти два файла составляют системное табличное пространство. Если два файла находятся на разных дисках, нагрузка на диски может быть усреднена, что повышает общую производительность базы данных. За именами обоих файлов следует атрибут, указывающий, что файлibdata1Размер файла 1000 МБ,ibdata2Размер составляет 1000 МБ, и он может автоматически увеличиваться после исчерпания свободного места.

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

Правила именования для пользовательских табличных пространств: tablename.ibd. Таким образом, пользователю не нужно хранить все данные в системном табличном пространстве по умолчанию, но пользовательское табличное пространство хранит только данные таблицы, индексы и буфер вставки BITMAP и другую информацию, а остальная информация по-прежнему хранится в системное табличное пространство по умолчанию.

На рисунке ниже показаноInnoDBМетод хранения подсистемы хранения для файлов, где файл frm представляет собой файл определения структуры таблицы, который записывает определение структуры таблицы для каждой таблицы.

файл журнала повторов (redo log file) и архив

По умолчанию вInnoDBВ каталоге данных механизма хранения будут два файла с именами.ib_logfile0иib_logfile1файл, этоInnoDBфайл повтора (redo log file), который записывает дляInnoDBЖурнал транзакций механизма хранения.

когдаInnoDBФайлы журнала повторного выполнения могут пригодиться, когда в файлах хранилища данных .InnoDBМеханизм хранения может использовать файлы журнала повторного выполнения для восстановления данных в правильное состояние, чтобы гарантировать правильность и целостность данных.

каждыйInnoDBМеханизм хранения имеет как минимум один файл журнала повторов, а каждая файловая группа имеет как минимум два файла журнала повторов, а также файл журнала по умолчанию.ib_logfile0иib_logfile1.

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

Размер каждого файла журнала повторов в группе журналов одинаков, и он работает в режиме [циклической записи].InnoDBМеханизм хранения сначала записывает в файл журнала повторов 1. Когда файл заполнен, он переключается на файл журнала повторов 2. Когда файл журнала повторов 2 также заполнен, он переключается на журнал повторов 1.

пользователь может использоватьInnodb_log_file_sizeустановить размер файла журнала повторов, что полезно дляInnoDBПроизводительность механизма хранения имеет очень большое влияние.

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

Механизм сброса журнала повторов

InnoDBСоблюдайте очистку файлов данных и файлов журналовWAL（write ahead redo log）иForce-log-at-commitДва правила, каждое из которых обеспечивает долговечность транзакции.WALПеред записью изменений данных на диск необходимо сначала записать на диск журнал в памяти;Force-log-at-commitТребуется, чтобы при фиксации транзакции все сгенерированные журналы были сброшены на диск.Если данные в буферном пуле сбрасываются на диск после успешного сброса журнала, происходит сбой базы данных до того, как данные будут сброшены на диск. диск, то база данных может восстановить данные из журнала при перезапуске.

Как показано на фиг.InnoDBКогда данные изменяются в пуле буферов, соответствующие изменения сначала записываются в буфер журнала повторов, а затем записываются на диск вовремя (например, механизм обновления каждую секунду) или когда транзакция фиксируется, что согласуется сForce-log-at-commitПринцип: после того, как журнал повторов будет записан на диск, измененные данные в буферном пуле будут основаны наcheckpointмеханизм записи на диск, который соответствуетWALв общем.

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

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

InnoDBизinnodb_flush_log_at_trx_commitСвойства могут контролировать, когда каждая транзакция фиксируетсяInnoDBповедение. Когда значение атрибута равно 0, когда транзакция зафиксирована, журнал повторов не будет записываться, а будет ждать, пока основной поток запишет вовремя; когда значение атрибута равно 1, когда транзакция зафиксирована, журнал повторов будет быть записаны в кеш файловой системы и вызыватьfsync, данные в буфере файловой системы фактически записываются в дисковое хранилище, чтобы гарантировать отсутствие потери данных; когда значение атрибута равно 2, при фиксации транзакции файл журнала также будет записан в кэш файловой системы, но fsync вызываться не будет, и файловая система сама решает, когда записывать кеш на диск.

Механизм сброса журнала показан на следующем рисунке:

Innodb_flush_log_at_commitдаInnoDBОсновной параметр настройки производительности, включающийInnoDBэффективность записи и безопасность данных. При значении параметра 0 эффективность записи самая высокая, но безопасность данных самая низкая; при значении параметра 1 эффективность записи самая низкая, но безопасность данных самая высокая; значение равно 1 для большей безопасности, и только когда установлено значение 1, можно гарантировать надежность транзакции.

использоватьUPDATEпредложение понятьInnoDBмеханизм хранения

С вышеуказаннымInnoDBБазовое введение в архитектуру механизма хранения, давайте еще раз проанализируем егоUPDATEСпециальный процесс обновления данных.

Делим эту картинку на две части: верхняя часть и нижняя часть, верхняя частьMySQL ServerПоток обработки слоя, следующая часть MySQL InnoDBПоток обработки механизма хранения.

MySQL ServerПоток обработки слоя

Эта часть потока обработки не имеет ничего общего с механизмом хранения.ServerКонкретные шаги заключаются в следующем:

1. Различные операции пользователя запускают выполнение sql в фоновом режиме через пул соединений с базой данных, который поставляется с веб-проектом: например,dbcp、c3p0、druidи т. д., установить сетевое соединение с пулом соединений базы данных сервера базы данных;
2. После того, как поток в пуле соединений с базой данных прослушивает запрос, он отвечает на полученный оператор SQL синтаксическому анализатору запросов через интерфейс SQL, а синтаксический анализатор запросов анализирует SQL в соответствии с синтаксисом SQL, чтобы выяснить, какие поля таблицы запрашивать. и каковы условия запроса;
3. Затем с помощью обработки оптимизатора запросов выберите оптимальный набор планов выполнения для sq;
4. Затем исполнитель отвечает за вызов ряда интерфейсов механизма хранения, выполнение плана и завершение выполнения всего оператора sql.

Эта часть процесса и та, что проанализирована вышеSelectАнализ потока обработки запросов в основном такой же.

InnoDBПоток обработки механизма хранения

Конкретный оператор выполнения должен быть завершен механизмом хранения, как показано на рисунке выше:

1. Обновите в таблице пользователей этот фрагмент данных с id=10.Если в буферном пуле такого фрагмента данных нет, необходимо сначала загрузить исходные данные обновленных данных в буферный пул с диска.
2. В то же время, чтобы обеспечить безопасность данных параллельного обновления, эти данные будут сначала заблокированы, чтобы предотвратить обновление других транзакций.
3. Затем пропишите значение перед обновлением в бэкапundo logсредний (для облегчения извлечения старых данных при откате транзакции), напримерupdateОператор сохраняет предыдущее значение обновляемого поля.
4. возобновитьbuffer poolКэшированные данные в памяти являются самыми последними данными, тогда данные в памяти являются грязными данными в это время (данные в памяти несовместимы с данными на диске)

На этом процесс выполнения в пуле буферов завершен (как показано на рисунке выше).

5. После обновления данных в буферном пуле необходимо записать текущую информацию об обновлении вRedo LogЛоги, потому что данные в памяти были изменены, а данные на диске не изменены.В это время, если машина, на которой находится MySQL, выходит из строя, измененные данные в памяти неизбежно будут потеряны.redoЖурнал предназначен для записи того, какие изменения вы внесли в данные, например, изменили значение поля имени для строки «id = 10». Это журнал, который используется для восстановления вас, когда MySQL внезапно выходит из строя. данные. Однако учтите, что в это времяRedo LogОн еще не был помещен в файл журнала.

   В это время подумайте над вопросом: что, если MySQL не работает, если транзакция не была зафиксирована?
   Выше мы знаем, что мы изменили данные памяти до сих пор, а затем записалиRedo Log BufferБуферизация журнала, если в это время происходит сбой MySQL, данные памяти иRedo Log BufferВсе данные будут потеряны, но не имеет значения, потеряны ли данные в это время, потому что оператор обновления не фиксирует транзакцию, это означает, что она не была выполнена успешно.В это время, хотя время простоя MySQL вызывает данные в памяти будут потеряны, вы обнаружите, что на диске данные остались прежними.

   Следующее, что нужно представить, это в настоящее время в соответствии с определенной стратегией.redoвойти изredo log bufferКисть в файл на диске, на данный момент эта стратегия черезinnodb_flush_log_at_trx_commitнастроить.

   • innodb_flush_log_at_trx_commit=0, указывая на то, что совершение действий не поставитredo log bufferЕсли данные в памяти сбрасываются в файл на диске, возможно, вы отправили транзакцию в это время, и в результате mysql не работает, а затем все данные в памяти в это время потеряны, поэтому этот метод не рекомендуется.
   • innodb_flush_log_at_trx_commit=1,redo logСбросить из памяти в файл на диск, пока транзакция успешно зафиксирована, затемredo logОн должен быть на диске, поэтому, если в это время произойдет сбой MySQL, вы можетеRedo LogДанные восстановления журнала.
   • innodb_flush_log_at_trx_commit=2, при фиксации транзакции записывать журнал повторов в соответствующий файл на дискеos cacheПерейти в кеш, вместо того, чтобы сразу перейти к файлу на диске, это может занять 1 секунду, чтобы поставить егоos cacheДанные записываются в файл на диске.

6. При совершении транзакции он также напишетbinlog,binlogСуществуют также различные стратегии чистки зубов.sync_binlogпараметры можно контролироватьbinlog, его значение по умолчанию равно 0, в это время вы ставитеbinlogПри записи на диск на самом деле происходит не прямой вход в файл на диске, а вводos cacheкеш памяти. Как правило, чтобы гарантировать, что данные не будут потеряны, мы настроим стратегию Double 1.Redo LogиBinlogВыберите 1 для стратегии размещения.

7. BinlogПосле размещенияBinlogимя файла, информацию о пути, где находится файл, иcommitОтметить для синхронной последовательной записи вRedo log, смысл этого шага в том, чтобы сохранитьredo logвойти сbinlogЛоги совпадают.commitОтметка является важным критерием для оценки того, успешно ли завершена транзакция.Например, если MySQL аварийно завершает работу после успешного выполнения 5-го или 6-го шага, на этот раз из-за отсутствия финальной транзакции.commitотмечено вredolog, поэтому эту транзакцию можно считать неудачной. не скажуredoВ лог-файле есть лог этого обновления, ноbinlogВ лог-файле нет лога этого обновления, поэтому несоответствия данных не будет.

8. После выполнения вышеуказанного данные в памяти были изменены, транзакция была отправлена, и журнал был помещен на диск, но данные на диске не были изменены синхронно.InnoDBВ фоновом режиме механизма хранения существует поток ввода-вывода, который будет обновлять данные в пуле буферов, обновленные транзакцией, но еще не записанные на диск (грязные данные, поскольку данные диска и данные памяти уже разные) во время низкого пика нагрузки на базу данных на диск для завершения персистентности транзакции.

такInnoDBПроцесс обработки записи можно представить следующей картинкой

Связанные вопросы интервью

Вопрос: Нужно ли блокировать буферный пул при доступе к нему?

Вопрос: Как инициализировать базу данных при ее запускеBuffer Poolиз?

Ответ: сначала нужно узнатьBuffer PoolЧто это такое, как он выглядит Пул буферов был представлен выше. Пул буферов будет содержать много страниц кэша, и каждая страница кэша также имеет данные описания (эту информацию описания можно в целом считать используемой для описания Кэш-страница, например, содержит следующие вещи: табличное пространство, к которому принадлежит страница данных, номер страницы данных, кэш-страница вBuffer Poolадрес в , и некоторые другие разные вещи. ),Как показано ниже:
На самом деле это тоже очень просто, пока база данных запущена, она будет следовать заданным вами настройкам.Buffer PoolРазмер, немного больший, переходит в операционную систему, чтобы подать заявку на область памяти, т.к.Buffer Poolобласть памяти. Затем, когда приложение области памяти будет завершено, база данных будет следовать размеру страницы кэша по умолчанию, равному 16 КБ, и соответствующему размеру данных описания, равному примерно 800 байтам.Buffer PoolСтраницы кэша делятся одна за другой, а соответствующие им данные описания — одна за другой.

Вопрос: Как база данных узнает, какие страницы данных свободны?

A: Страницы данных и страницы кэша на диске находятся во взаимно однозначном соответствии, обе по 16Кб, и одна страница данных соответствует одной странице кэша. База данных будетBuffer Poolдизайн одинfreeСвязный список, он представляет собой структуру данных двусвязного списка, этоfreeВ связанном списке каждый узел является адресом блока данных описания свободной страницы кеша, то есть, пока одна из ваших страниц кеша свободна, его блок данных описания будет помещен в этотfreeв связанном списке. Когда база данных запускается впервые, все страницы кэша могут быть свободны, потому что в это время это может быть пустая база данных без данных, поэтому блоки данных описания всех страниц кэша в это время будут помещены в этот блок.freeсвязанный список, среди прочего, этоfreeСвязанный список имеет базовый узел, который ссылается на головной узел и хвостовой узел связанного списка, а также хранит количество узлов в связанном списке, описывающих блок данных, то есть сколько свободных страниц кэша имеется.

Вопрос: Как узнать, кэшируется ли страница данных?

Ответ: При выполнении CRUD сначала проверьте, была ли кэширована страница данных.freeНайдите свободную страницу кеша в связанном списке, прочитайте страницу данных с диска и запишите страницу кеша, запишите данные описания, изfreeУдалить блок описания из связанного списка. Но если страница данных была кэширована, она будет использоваться напрямую.
Таким образом, база данных также будет иметь структуру данных хеш-таблицы, он будет использовать номер табличного пространства + номер страницы данных в качестве ключа, а затем адрес страницы кэша в качестве значения. Если вы хотите использовать страницу данных, используйте «номер табличного пространства + номер страницы данных» в качестве ключа для проверки этой хэш-таблицы, если нет, прочитайте страницу данных и запишите страницу кеша, а в хэш-таблице напишите ключ-значение пара, ключ — номер табличного пространства + номер страницы данных, а значение — адрес страницы кэша, если Если он уже существует, это означает, что страница данных была закэширована.

Вопрос: Какие данные находятся в области холодных данных связанного списка LRU?

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

проблема:Buffer PoolБудет ли фрагментация памяти?

О: Конечно, будет, потому чтоBuffer PoolРазмер устанавливается самостоятельно, скорее всегоBuffer PoolПосле разделения всех страниц кеша и блоков данных описания остается немного памяти, и эта небольшая память не может содержать никаких страниц кеша, поэтому эту память можно только хранить и нельзя использовать, что является фрагментацией памяти.

Так как же уменьшить фрагментацию памяти?
На самом деле это очень просто, база данных находится вBuffer PoolПри разделении страниц кэша посередине все страницы кэша и блоки данных описания располагаются близко друг к другу, чтобы максимально сократить потери памяти и максимально уменьшить фрагментацию памяти.

Вопрос: Как грязные страницы сбрасываются на диск?

Ответ: Грязные страницы образуются путем модификации данных в буферном пуле, что приводит к несоответствию между данными в памяти и данными на диске. Обновление грязных страниц заключается в синхронизации страниц с измененными данными с диском. Хранить все страницы в буфере невозможно бассейн.Обновить, как найти эти грязные тоже очень важно,MySQLОбработка такая же, как и для бесплатных страниц.
База данных здесь представляет еще одинfreeпохожий связанный списокflushсвязанный список, этоflushСуть связанного списка заключается в использовании двух указателей в блоке данных описания страницы кэша, чтобы сделать блок данных описания модифицированной страницы кэша двусвязным списком. Для любой кешированной страницы, которая была изменена, ее блок данных описания будет добавлен вflushк связанному списку,flushЭто означает, что это грязные страницы, и продолжение должноflushслить на диск.

проблема:undo logиredo logТы понимаешь? Каковы их функции?

отвечать:undo logиredo logнаходится в mysqlInnoDBБазовый состав механизма хранения:

• undo logЗначение данных перед транзакцией сохраняется, чтобы при откате транзакции можно было вернуть версию данных до транзакции.undo logцепочка версий;

• redo logРяд информации об операциях транзакций записывается на физическом уровне, чтобы гарантировать, что даже в случае сбоя mysql и других факторов данные еще не были сброшены на диск.redo logДанные, зафиксированные транзакциями, также могут быть восстановлены.

проблема:redo logКак сделать так, чтобы транзакции не терялись?

Ответ. После успешной отправки транзакции, несмотря на то, что данные в пуле буферов могут не попасть на диск вовремя,redo logЗаписанная информация о транзакции сохраняется на диске и содержитcommitОтметьте, в это время, если mysql не работает и данные памяти в пуле буферов, которые были обновлены транзакцией, потеряны, при перезапуске mysql данные на диске будут изменены.redo logИнформация об изменении транзакции загружается в пул буферов, чтобы гарантировать, что информация о транзакции не будет потеряна. илиredo logматовый,binlogЗапись прошла успешно, она будет автоматически дана при перезапускеcommitотметить и воспроизвести данные.

Вопрос: транзакция фиксируется первой или сначала сбрасывается?

A: Транзакция сначала отправляется, а затем обновляется;

1. Redo logКисть успешно
2. Binlogщетка
3. BinLogинформация об имени и пути к файлу,commitзнак, написанныйRedo log, транзакция гарантируется двухфазной фиксацией.

Вопрос: Почему операция обновления не обновляет диск напрямую, а проектирует такую ​​сложнуюInnoDBдвижок хранения доделать?

A: Непосредственное обновление диска — это случайная запись ввода-вывода, существует операция адресации диска, производительность очень низкая, и она не может поддерживать сценарии с высокой степенью параллелизма; вместо этого она преобразуется вInnoDBсредняя, ​​высокоскоростная память для чтения и записи,redo logиundo logПроизводительность диска с последовательной записью намного выше, чем производительность случайной записи ввода-вывода, и это улучшение производительности может компенсировать сложность этой архитектуры и может поддерживать сценарии с высокой степенью параллелизма в пределах определенного количества запросов в секунду.

Ссылка на данные:

«Возьмите вас, чтобы стать мастером боевой оптимизации MySQL с нуля»
"Инсайдер технологии MySQL - механизм хранения InnoBD"