моя контактная информация
Почтамезофия@protonmail.com
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Вообще говоря, MySQL можно разделить на два уровня.
mysql -h$ip -P$port -u$user -p
MySQL в команде подключения — это клиентский инструмент, используемый для установления соединения с сервером.После завершения классического TCP-квитирования соединитель
Скоро начнется проверка вашей личности. В настоящее время будут использоваться введенные вами имя пользователя и пароль.
Если клиент неактивен слишком долго, коннектор автоматически отключит его. Это время контролируется параметром wait_timeout, значение по умолчанию — 8 часов.
Если клиент повторно отправит запрос после разрыва соединения, он получит напоминание об ошибке: Lost connection to MySQL server during query . Если вы хотите продолжить в это время, вам необходимо повторно подключиться, а затем выполнить запрос.
В базе данных длинное соединение означает, что после успешного соединения, если клиент продолжает делать запросы, всегда будет использоваться одно и то же соединение. Короткое соединение означает, что соединение разрывается после выполнения нескольких запросов и восстанавливается для следующего запроса.
Процесс установления соединения обычно сложен, поэтому предлагаю вам постараться минимизировать действия по установлению соединения во время использования, то есть стараться использовать длинные соединения.
Но после того, как будут использованы все длинные соединения, вы можете обнаружить, что иногда память, занимаемая MySQL, увеличивается очень быстро.Память, временно используемая MySQL во время выполнения, управляется в объекте соединения. . Эти ресурсы будут освобождены при разрыве соединения.Так что еслиНакопление длинных соединений может привести к чрезмерному использованию памяти., был принудительно убит системой (OOM). Судя по этому явлению, MySQL перезапустился ненормально.
Как решить эту проблему? Вы можете рассмотреть следующие два варианта.
mysql_reset_connection для повторной инициализации ресурсов соединения. Этот процесс не требует повторного подключения и проверки разрешений, но восстанавливает соединение до состояния, когда оно было только что создано.После того, как MySQL получит запрос на запрос, он сначала обратится к кешу запросов, чтобы проверить, выполнялся ли этот оператор ранее. Ранее выполненные инструкции и их результаты могут быть кэшированы непосредственно в памяти в виде пар ключ-значение. Ключом является оператор запроса, а значением — результат запроса. Если ваш запрос сможет найти ключ непосредственно в этом кеше, то значение будет возвращено непосредственно клиенту.
Если оператора нет в кэше запросов, фаза выполнения продолжается. После завершения выполнения результаты выполнения будут сохранены в кеше запроса. Вы можете видеть, что если запрос попадает в кеш, MySQL может напрямую вернуть результат, не выполняя последующих сложных операций, что очень эффективно.
Но большую часть времени я будуРекомендуется не использовать кэширование запросов. ,почему? Потому что кэширование запросов зачастую приносит больше вреда, чем пользы.
Кэш запросов очень часто становится недействительным. Пока происходит обновление таблицы, все кэши запросов в этой таблице будут очищены. Таким образом, возможно, вы потрудились сохранить результаты, и еще до того, как вы их использовали, они были удалены обновлением. Для баз данных с большой нагрузкой на обновления частота попадания в кэш запросов будет очень низкой. Если только в вашем бизнесе нет статической таблицы, которая будет обновляться только один раз в течение длительного времени. Например, если это таблица конфигурации системы, то запрос к этой таблице подходит для кэша запросов.
К счастью, MySQL также предоставляет этот метод «использования по требованию». Вы можете установить для параметра query_cache_type значение DEMAND, чтобы кэш запросов не использовался для операторов SQL по умолчанию. Для операторов, в которых вы уверены, что хотите использовать кэш запросов, вы можете использовать SQL_CACHE, чтобы явно указать его, как в следующем операторе:
select SQL_CACHE * from T where ID=10；
нужно знать,Версия MySQL 8.0 напрямую удаляет всю функцию кэша запросов., что означает, что эта функция больше не будет доступна, начиная с версии 8.0.
Если кеш запросов не затронут, начинается фактическое выполнение инструкции. Во-первых, MySQL должен знать, что вы хотите сделать, поэтому ему необходимо проанализировать оператор SQL.
Не знаю, помните ли вы статью «Конг Иджи». У менеджера отеля есть розовая доска, специально используемая для записи кредитных историй гостей. Если мало кто платит в кредит, он может написать на доске имя и счет клиента. Но если людей с кредитными счетами слишком много, всегда будут моменты, когда фан-доска не сможет их отслеживать. В это время владелец магазина должен иметь книгу, специально предназначенную для регистрации кредитных счетов.
Если кто-то хочет погасить кредит или погасить долг, у продавца обычно есть два варианта:
Когда бизнес процветает и прилавок занят, продавец обязательно выберетпоследний , потому что первая операция слишком затруднительна. Во-первых, вам нужно найти запись об общем кредитном счете этого человека. Подумайте об этом: здесь десятки плотно упакованных страниц. Чтобы найти имя, владельцу магазина, возможно, придется надеть очки для чтения и медленно искать. Найдя его, он достанет счеты для вычислений и, наконец, запишет результат обратно. бухгалтерская книга.
Обо всем этом процессе сложно думать. Напротив, легче сначала записать это на розовой доске. Подумайте об этом: если у владельца магазина нет помощи розовой доски, ему придется переворачивать бухгалтерскую книгу каждый раз, когда он записывает счета. Разве эффективность не невыносимо низка?
Аналогично, эта проблема существует и в MySQL. Если каждую операцию обновления необходимо записать на диск, и диск также должен найти соответствующую запись перед обновлением, стоимость ввода-вывода и стоимость поиска всего процесса будут очень высокими. Чтобы решить эту проблему, разработчики MySQL использовали идею, аналогичную розовой доске владельца магазина в отеле, для повышения эффективности обновлений.
Весь процесс взаимодействия между розовой доской и реестром на самом деле является тем, что часто упоминается в MySQL. WAL технологии,WAL Полное имяWrite-Ahead Logging, ключевой моментСначала записывайте журнал, затем записывайте на дискТо есть сначала напишите розовую доску, а затем, когда вы не заняты, напишите бухгалтерскую книгу.
В частности, когда запись необходимо обновить, механизм InnoDB сначала записывает запись в журнал повторов (розовая доска) и обновляет память. На этом этапе обновление завершается. В то же время механизм InnoDB обновит запись операции на диске в соответствующее время, и это обновление часто выполняется, когда система относительно простаивает, точно так же, как это делает продавец после закрытия.
Если сегодня кредитных счетов не так много, владелец магазина может подождать до закрытия, чтобы разобраться с товарами. Но что делать, если в определенный день кредитных счетов много и розовая доска заполнена? В это время у владельца магазина не было другого выбора, кроме как отложить свою работу, обновить некоторые кредитные записи на розовой доске в бухгалтерской книге, а затем стереть эти записи с розовой доски, чтобы освободить место для новых счетов.
Аналогично, журнал повторов InnoDB имеет фиксированный размер. Например, его можно настроить как набор из 4 файлов, каждый из которых имеет размер 1 ГБ. Тогда эта «розовая доска» может записывать в общей сложности 4 ГБ операций. Начните писать с начала, а затем вернитесь к началу и напишите циклично, как показано на рисунке ниже.
write pos — позиция текущей записи. При записи перемещается назад. После записи в конец файла №3 возвращается в начало файла №0. Контрольная точка — это текущая позиция, подлежащая удалению, а также перемещение вперед и циклическое движение. Перед стиранием записи ее необходимо обновить в файле данных.
Пространство между позицией записи и контрольной точкой — это пустая часть «розовой доски», которую можно использовать для записи новых операций. Если позиция записи догоняет контрольную точку, это означает, что «розовая доска» заполнена, и в настоящее время новые обновления не могут быть выполнены. Вам придется сначала остановиться и стереть некоторые записи, чтобы перейти к контрольной точке.
С помощью журнала повторов InnoDB может гарантировать, что даже в случае аварийного перезапуска базы данных ранее отправленные записи не будут потеряны. Эта возможность называется.crash-safe。
Чтобы понять концепцию безопасности от сбоев, вспомните наш предыдущий пример кредитной истории. Пока кредитная запись записана на розовой доске или записана в книге, даже если владелец магазина забудет ее позже, например, внезапно приостановив деятельность на несколько дней, он все равно может уточнить кредитный счет с помощью данных в книге и розовая доска после возобновления бизнеса.
Как мы упоминали ранее, MySQL в целом состоит из двух частей: одна — это уровень сервера, который в основном выполняет функции на функциональном уровне MySQL, а другая — уровень механизма, который отвечает за конкретные вопросы, связанные с хранилищем;Розовая доска, о которой мы говорили выше.журнал повторного выполнения — это журнал, уникальный для движка InnoDB.,и Уровень сервера также имеет собственный журнал, называемый binlog (архивный журнал).。
Думаю, вы спросите, а зачем два бревна?
Потому что вначале в MySQL не было движка InnoDB. Собственный движок MySQL — MyISAM, но MyISAM не имеет возможностей защиты от сбоев, а журналы binlog можно использовать только для архивирования. InnoDB был представлен в MySQL в виде плагина другой компанией. Поскольку использование только binlog не обеспечивает возможности защиты от сбоев, InnoDB использует другую систему журналов, то есть журнал повторного выполнения, для обеспечения безопасности от сбоев.
Эти два журнала имеют следующие три различия.
Имея концептуальное представление об этих двух журналах, давайте посмотрим на внутренние процессы исполнителя и механизма InnoDB при выполнении этого простого оператора обновления.
Здесь я привожу блок-схему выполнения этого оператора обновления. Светлый прямоугольник на рисунке указывает, что он выполняется внутри InnoDB, а темный прямоугольник указывает, что он выполняется в исполнителе.
процесс выполнения оператора обновления
Возможно, вы заметили, что последние три шага кажутся немного «цикличными». Написание журнала повторов разделено на два этапа: подготовка и фиксация. Это «двухфазная фиксация».
Зачем нужна «двухэтапная подача»?Это сделано для того, чтобы разрешить разницу между двумя журналами.логически последовательный . Чтобы объяснить эту проблему, нам придется начать с вопроса в начале статьи: Как восстановить базу данных до состояния любой секунды в течение полумесяца?
Как мы уже говорили, binlog записывает все логические операции и принимает форму «дополнительной записи». Если ваш администратор базы данных обещает, что ее можно восстановить в течение полумесяца, то система резервного копирования обязательно сохранит все бинлоги за последние полмесяца, и система будет выполнять регулярное резервное копирование всей базы данных. «Регулярность» здесь зависит от важности системы, которая может быть раз в день или раз в неделю.
Когда вам нужно восстановить заданную секунду, например, в два часа дня, вы обнаружите, что таблица была случайно удалена в полдень, и вам нужно получить данные, вы можете сделать это:
Хорошо, после разговора о процессе восстановления данных, давайте вернемся и поговорим о том, почему журналу нужна «двухфазная фиксация». Здесь мы могли бы также использовать доказательство от противного для объяснения.
Поскольку журнал повторного выполнения и binlog представляют собой две независимые логики, если двухфазная фиксация не используется, либо сначала должен быть записан журнал повторного выполнения, а затем binlog, либо должен быть принят обратный порядок. Давайте посмотрим, какие проблемы есть у этих двух методов.
По-прежнему используйте предыдущий оператор обновления в качестве примера. Предположим, что значение поля c в текущей строке с ID=2 равно 0, и предположим, что во время выполнения оператора обновления происходит сбой после записи первого журнала, но до записи второго. Что произойдет?
Вы можете сказать, неужели эта вероятность очень мала? Не бывает ситуаций, когда временную библиотеку нужно будет восстанавливать в любой момент?
На самом деле нет, этот процесс необходим не только для восстановления данных после неправильной эксплуатации. Когда вам нужно расширить емкость, то есть когда вам нужно создать больше резервных баз данных для увеличения емкости чтения системы, сейчас общепринятой практикой является использование полного резервного копирования и применение binlog для достижения этой цели. несогласованность между главной и подчиненной базами данных в сети.
Проще говоря, как журнал повторного выполнения, так и binlog могут использоваться для представления статуса фиксации транзакции.Двухэтапное представление призвано обеспечить логическую согласованность двух состояний.。
Он посвятил себя исследованию технологий более 30 лет и владеет различными языками, такими как Java, Linux, Javascript, php, css и т. д. Он внес большой вклад в область открытого исходного кода. Станция документации для разработчиков, где можно поделиться некоторыми проблемами в разработке технологий для дальнейшего использования.
Почтамезофия@protonmail.com