Последняя статья "буферный пул (buffer pool), досконально разбирайся!" «Представлен принцип работы буферного пула InnoDB.
Краткий обзор: 
(1) хранилище данных MySQL состоит из двух частей: памяти и диска;
(2) буферный пул памяти использует страницы в качестве единицы для кэширования самых популярных страниц данных и страниц индекса. ;
(3) к вариантам алгоритма LRU управления пулом буферов InnoDB и сможет решить проблему «сбоя предварительного чтения» и «загрязнения пула буферов»;
озвучивание: подробности см. В «пуле буферов (пул буферов), полностью поймите! ".
Нет сомнений в том, что для запросов на чтение пул буферов может уменьшить количество операций ввода-вывода диска и повысить производительность. Вопрос в том, что насчет запроса на запись?
Ситуация первая
Предположим, вы хотите изменить страницу индекса со страницей 4, и эта страница находится в пуле буферов. 
Как показано в приведенном выше порядковом номере 1-2:
(1) Непосредственно изменить страницу в буферном пуле, одна операция с памятью;
(2) Запись в журнал повторов, одна операция последовательной записи на диск;
эта эффективность является максимальной.
Закадровый голос: записывайте в последовательности, как в журнале, десятки тысяч раз в секунду, без проблем.
Будут ли проблемы с согласованностью?
На самом деле, нет.
(1) Чтение затронет страницы пула буферов;
(2) Данные LRU в пуле буферов будут удалены, а «грязные страницы» будут сброшены обратно на диск;
(3) База данных аварийно завершила работу, и данные можно восстановить из журнала повторов;
Когда страницы буферного пула будут сброшены на диск?
Регулярная очистка диска, а не каждый раз, может уменьшить количество операций ввода-вывода диска и повысить производительность MySQL.
Закадровый голос: Пакетное написание - распространенный метод оптимизации.
Ситуация вторая
Предположим, вы хотите изменить страницу индекса со страницей 40, и эта страница оказалась вне пула буферов. 
На этом этапе это немного проблематично, как показано на рисунке выше, вам нужно 1-3:
(1) Сначала загрузите страницу индекса, которая должна быть 40, с диска в пул буферов, произвольная операция чтения с диска;
(2) Изменить страницу в пуле буферов, операция с памятью ;
(3) Запись журнала повторения, операция последовательной записи на диск;
Если в буферный пул не попадает, создается по крайней мере один дисковый ввод-вывод. Есть ли еще место для оптимизации для бизнес-сценариев, когда больше операций записи и меньше операций чтения?
Это проблема, которую рассматривает InnoDB, и именно буфер изменений будет обсуждаться в этой статье.
Закадровый голос: из названия легко понять, что буферизация записи - это механизм для уменьшения дискового ввода-вывода и повышения производительности записи в базу данных.
Что такое буфер записи InnoDB?
До MySQL5.5 он назывался буфером вставки, который был оптимизирован только для вставки; теперь он также эффективен для удаления и обновления, называемый буфером изменений.
Это приложение, когда неуникальная страница вторичного индекса не находится в пуле буферов, и страница записывается, а страница диска не загружается сразу в пул буферов, а изменяется только буфер (буфер изменения), когда будущие данные считываются, данные объединяются и восстанавливаются в пуле буферов. Буферизация записи предназначена для уменьшения количества операций ввода-вывода на диск для операций записи и повышения производительности базы данных.
Голос за кадром: У R есть собака, это такое длинное предложение.
InnoDB добавила оптимизацию буфера записи, какие изменения произойдут с вышеупомянутым процессом "случай два"?
Предположим, вы хотите изменить страницу индекса со страницей 40, и эта страница оказалась вне пула буферов. 
После добавления оптимизации буфера записи процесс оптимизируется следующим образом:
(1) Запись этой операции в буфер записи, операция памяти;
(2) Запись в журнал повторов, операция последовательной записи на диск;
ее производительность такая же, как у индексной страницы в буферном пуле ,аналогичный.
Закадровый голос: Как видите, страница 40 не загружена в буферный пул.
Будут ли проблемы с согласованностью?
И не будет.
(1) База данных аварийно завершает работу, и данные могут быть восстановлены из журнала повторов;
(2) Буфер записи - это не просто структура памяти, он также будет периодически сбрасываться в системное табличное пространство буфера записи;
(3) Когда данные читаются, происходит Другой процесс, объединение данных в буферный пул;
Можно предположить, что позже появится запрос на запрос данных страницы 40 индекса. 
В настоящее время процесс имеет порядковый номер 1-3:
(1) загрузка индексной страницы, буферный пул отсутствует, на этот раз дисковый ввод-вывод неизбежен;
(2) чтение связанной информации из буфера записи;
(3) восстановление индексной страницы и ее размещение В пуле буферов LRU;
голос за кадром: как вы можете видеть, страница 40 будет загружена в пул буферов при фактическом чтении.
Также есть упущение. Почему оптимизация буфера записи применима только к неуникальным обычным индексным страницам?
В InnoDB сходства и различия между кластеризованным индексом и вторичным индексом подробно описаны в разделе «Понимание различий в индексах между MyISAM и InnoDB за 1 минуту» и не будут расширяться.
Если индекс установлен с уникальным атрибутом, InnoDB должен выполнить проверку уникальности во время операций модификации. Другими словами, даже если индексная страница не находится в пуле буферов, нельзя избежать чтения страницы с диска (иначе как проверить, является ли она уникальной?), В это время соответствующая страница должна быть непосредственно помещена в пул буферов, а затем изменена, и не должна Весь буфер записи это Yaozi.
В дополнение к странице данных, к которой осуществляется доступ, какие еще сценарии вызовут очистку данных в буфере?
Также существует несколько ситуаций, когда данные в буфере будут сброшены:
(1) есть фоновый поток, когда база данных считается бездействующей;
(2) когда пула буферов базы данных недостаточно;
(3) когда база данных завершается нормально;
(4) повторять Когда журнал заполнен;
голос за кадром: журнал повторов почти не заполнен, и вся база данных находится в непригодном для использования состоянии, и запись невозможна.
Какой бизнес-сценарий подходит для включения механизма буфера записи InnoDB?
Позвольте мне сначала поговорить о том, когда это не подходит. Как было проанализировано выше, когда:
(1) база данных является уникальным индексом;
(2) или после записи данных они будут немедленно прочитаны; для
этих двух типов сценариев, когда операция записи выполняется ( После продолжения) первоначально должны были выполняться чтения страниц, а соответствующие страницы должны были изначально храниться в пуле буферов.В то время кэширование записи стало обузой и увеличило сложность.
Когда целесообразно использовать буфер записи, если:
(1) большая часть базы данных является неуникальным индексом;
(2) бизнес состоит в том, чтобы писать больше и меньше для чтения или не читать сразу после записи;
буфер записи может использоваться, и первоначальная потребность для каждой записи Выполните дисковый ввод-вывод SQL и оптимизируйте периодическую пакетную запись на диск.
Озвучивание: Например, бизнес с потоками счетов
Каким параметрам в InnoDB соответствуют приведенные выше принципы?
Есть еще два важных параметра. 
Параметр: innodb_change_buffer_max_size
Введение: Настройте размер буфера записи, который учитывает долю всего пула буферов.Значение по умолчанию - 25%, максимальное значение - 50%.
Закадровый голос: компаниям, которые больше пишут и меньше читают, необходимо увеличить это значение. Для компаний, которые больше читают и меньше пишут, 25% на самом деле слишком много.
Параметры: innodb_change_buffering
Введение : настройте, какие операции записи включают буферизацию записи, которая может быть установлена на все / нет / вставки / удаления и т. Д.
Надеюсь, вы что-то получите, а идеи важнее выводов. Рекомендации по 
техническим идеям Architect's Road-Sharing
:
«6 советов по оболочке, чтобы сделать скрипты более профессиональными | 1-минутная серия»
«Разница в индексах MyISAM и InnoDB | 1-минутная серия»
«буферный пул (буферный пул), на этот раз полностью понял! ! ! «
Научись слушать, самое главное на рабочем месте!» ! ! 》