Некоторые точки знаний и вопросы для интервью по изучению Java, которые я обобщил самостоятельно, в настоящее время находятся в открытом доступе и будут продолжать улучшаться.Предложения и рекомендации приветствуются.Добро пожаловать в Star: GitHub.com/snail Climb/…
Книга Рекомендации
Высокая производительность MySQL: 3-е издание
Рекомендация по текстовому учебнику
Учебник по MySQL (учебник для новичков)
Учебник по MySQL (учебник по легкой сотне)
Рекомендуемые видеоуроки
Начало работы с основами: Связь на нулевом расстоянии с MySQL - Сеть MOOC
Навыки разработки MySQL: Навыки разработки MySQL (1) Навыки разработки MySQL (2) Навыки разработки MySQL (3)
Новые функции Mysql5.7 и связанные с ними навыки оптимизации: Новые возможности версии MySQL 5.7 Оптимизация производительности оптимизации MySQL
Начало работы с кластером MySQL (PXC) Введение и применение MyCAT
Резюме часто задаваемых вопросов
-
①Двигатель памяти
Два общих механизма хранения в MySQL: отношения любви и ненависти между MyISAM и InnoDB
-
②Набор символов и правила корректуры
Набор символов относится к отображению двоичной кодировки в определенный класс символьных символов. Правила сопоставления относятся к правилам сопоставления для определенного набора символов. Каждый набор символов в Mysql соответствует ряду правил сопоставления.
Mysql использует аналогичный метод наследования для указания значения по умолчанию для набора символов.Каждая база данных и каждая таблица данных имеют свое собственное значение по умолчанию, которое наследуется слой за слоем. Например: набором символов по умолчанию для всех таблиц в библиотеке будет набор символов, указанный в базе данных (набор символов по умолчанию будет использоваться для этих таблиц, если набор символов не указан) PS: Аранжировка из «Пути развития для Java-инженеры» 》
Для получения подробной информации см.:Понимание набора символов MySQL и правил корректуры
-
③ Контент, связанный с индексами (очень важная технология при использовании баз данных, разумное и правильное использование индексов может значительно повысить производительность запросов к базе данных)
Структуры данных, используемые индексами Mysql, в основном:Индекс BTreeихэш-индекс. Для хэш-индекса базовой структурой данных является хэш-таблица. Поэтому, когда большинство требований относится к запросу с одной записью, вы можете выбрать хэш-индекс, который имеет самую высокую производительность запроса; для большинства других сценариев рекомендуется выбрать индекс BTree.
Индекс BTree Mysql использует B+Tree в числе B, но методы реализации для двух основных механизмов хранения различаются.
MyISAM:Поле данных конечного узла B+Tree хранит адрес записи данных. При извлечении индекса индекс сначала просматривается в соответствии с алгоритмом поиска B+Tree.Если указанный ключ существует, значение его поля данных извлекается, а затем считывается соответствующая запись данных с адресом поля данных. Это называется «некластеризованным индексом».
InnoDB:Сам его файл данных является индексным файлом. По сравнению с MyISAM файл индекса и файл данных разделены.Сам файл данных таблицы представляет собой структуру индекса, организованную B+Tree, а поле данных конечного узла дерева сохраняет полную запись данных. Ключ этого индекса является первичным ключом таблицы данных, поэтому сам файл данных таблицы InnoDB является первичным индексом. Это называется «кластеризованный индекс (или кластеризованный индекс)». Остальные индексы используются как вспомогательные, а в поле данных вспомогательного индекса вместо адреса хранится значение первичного ключа соответствующей записи, что также отличается от MyISAM.При поиске по первичному индексу данные можно получить, непосредственно найдя узел, в котором находится ключ; при поиске по вторичному индексу сначала нужно получить значение первичного ключа, а затем первичный индекс. снова ходил. Поэтому при проектировании таблицы не рекомендуется использовать слишком длинное поле в качестве первичного ключа, а также не рекомендуется использовать в качестве первичного ключа немонотонное поле, что приведет к частому разбиению первичного индекса.PS: Аранжировка из "Путь развития инженера Java"
Для получения подробной информации см.:
Галантерея: структура данных индекса mysql
Серия оптимизаций MySQL (3) - использование, принцип и оптимизация дизайна индексов
-
④Использование кеша запросов
Добавьте следующую конфигурацию в my.cnf, перезапустите Mysql, чтобы включить кеширование запросов.
query_cache_type=1 query_cache_size=600000Mysql также может открыть кеш запросов, выполнив следующую команду
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; -
⑤ Механизм сделки
Реляционные базы данных должны следовать правилам ACID, а именно:
- Атомарность:Транзакция является наименьшей единицей выполнения и не допускает разделения. Атомарность транзакций гарантирует, что действия либо завершатся, либо вообще ничего не сделают;
- последовательность:До и после выполнения транзакции данные остаются согласованными;
- Изоляция:При одновременном доступе к базе данных транзакция пользователя не нарушается другими транзакциями, а база данных независима от параллельных транзакций;
- Упорство:После совершения транзакции. Его изменения данных в базе данных являются постоянными и не должны иметь никакого эффекта, даже если база данных выйдет из строя.
Для достижения вышеуказанных характеристик транзакций база данных определяет несколько различных уровней изоляции транзакций:
-
READ_UNCOMMITTED (неавторизованное чтение):Самый низкий уровень изоляции, позволяющий читать изменения данных, которые еще не были зафиксированы,Может вызвать грязное чтение, фантомное чтение или неповторяющееся чтение.
-
READ_COMMITTED (авторизованное чтение):Позволяет читать данные, которые были зафиксированы параллельными транзакциями,Грязные чтения можно предотвратить, но фантомные или неповторяющиеся чтения все же могут происходить.
-
REPEATABLE_READ (повторяемое чтение):Результаты многократного чтения одного и того же поля согласуются, если только данные не изменены самой транзакцией.Грязные чтения и неповторяющиеся чтения можно предотвратить, но фантомные чтения все еще могут возникать.
-
СЕРИАЛИЗУЕМЫЙ:Самый высокий уровень изоляции, полностью соответствующий уровню изоляции ACID. Все транзакции выполняются одна за другой, так что абсолютно исключена возможность вмешательства между транзакциями, т.е.Этот уровень предотвращает грязные чтения, неповторяемые чтения и фантомные чтения.. Но это серьезно повлияет на производительность программы. Обычно этот уровень также не используется.
Здесь следует отметить следующее:Уровень изоляции REPEATABLE_READ, принятый Mysql по умолчанию, является уровнем изоляции READ_COMMITTED, принятым Oracle по умолчанию.
Реализация механизма изоляции транзакций основана на механизме блокировки и параллельном планировании. Среди них параллельное планирование использует MVVC (управление параллелизмом нескольких версий), который поддерживает такие функции, как параллельное согласованное чтение и откат путем сохранения измененной информации о старой версии.
Для получения подробной информации см.:Вероятно, самое красивое подробное объяснение управления транзакциями Spring.
-
⑥Механизм блокировки и алгоритм блокировки InnoDB
Блокировки, используемые механизмами хранения MyISAM и InnoDB:
- MyISAM использует блокировку на уровне таблицы.
- InnoDB поддерживает блокировку на уровне строки и блокировку на уровне таблицы, по умолчанию используется блокировка на уровне строки.
Сравнение блокировок на уровне таблицы и блокировок на уровне строк:
- Блокировки на уровне таблицы:Заблокировать в MysqlМаксимальная детализацияРазновидность блокировки, которая блокирует всю таблицу текущей операции, проста в реализации, потребляет меньше ресурсов, быстро блокируется и не вызывает взаимоблокировок. Он имеет наибольшую степень детализации блокировки, наибольшую вероятность возникновения конфликтов блокировок и наименьший параллелизм.Оба механизма MyISAM и InnoDB поддерживают блокировки на уровне таблицы.
- Блокировка уровня строки:Заблокировать в Mysqlнаименьшая степень детализацииТип блокировки, которая блокирует только строку, над которой в данный момент выполняется операция. Блокировки на уровне строк могут значительно уменьшить количество конфликтов в операциях базы данных. Его степень детализации блокировки является наименьшей, а параллелизм высоким, но накладные расходы на блокировку также самые большие, а блокировка выполняется медленно и могут возникать взаимоблокировки.
Для получения подробной информации см.:Механизм блокировки Mysql прост для понимания
Существует три алгоритма блокировки механизма хранения InnoDB:
- Блокировка записи: блокировка записи одной строки
- Блокировка промежутка: Блокировка промежутка, блокирует диапазон, исключая саму запись
- Блокировка следующей клавиши: запись + пробел блокирует диапазон, включая саму запись.
Связанные точки знаний:
- innodb использует блокировку следующего ключа для запросов строк
- Следующая блокировка ключа для решения проблемы фантомного чтения Phantom Problem
- Понизьте блокировку следующего ключа до ключа записи, если запрошенный индекс содержит уникальный атрибут.
- Цель конструкции Gap lock — предотвратить вставку записей в один и тот же диапазон несколькими транзакциями, что может привести к фантомным проблемам чтения.
- Есть два способа явного закрытия гэп-блокировок: (за исключением ограничений внешнего ключа и проверок уникальности, используются только блокировки записей) A. Установить уровень изоляции транзакции на RC B. Установить для параметра innodb_locks_unsafe_for_binlog значение 1
-
⑦ Оптимизация больших таблиц
Когда количество записей в таблице MySQL слишком велико, производительность CRUD базы данных будет значительно снижена.Некоторые общие меры оптимизации заключаются в следующем:
-
Ограничьте диапазон данных:Обязательно запретите операторы запросов без каких-либо условий, ограничивающих диапазон данных. Например: когда пользователи запрашивают историю заказов, мы можем контролировать ее в течение месяца. ;
-
Разделение чтения/записи:Классическая схема разделения базы данных, основная библиотека отвечает за запись, а подчиненная библиотека — за чтение;
-
кеш:Используйте кеш MySQL и рассмотрите возможность использования кеша уровня приложения для тяжеловесных и менее обновленных данных;
-
Вертикальная перегородка:
Разделить в соответствии с релевантностью таблиц данных в базе данных.Например, пользовательская таблица содержит как информацию для входа в систему, так и основную информацию о пользователе.Таблица пользователей может быть разделена на две отдельные таблицы или даже помещена в отдельную базу данных в качестве подбазы данных.
Проще говоря, вертикальное разделение означает разделение столбцов таблицы данных, разделение таблицы с большим количеством столбцов на несколько таблиц.Как показано на рисунке ниже, это должно быть проще для понимания.
Преимущества вертикального шпагата:Это может сделать данные строки меньше, уменьшить количество блоков, считываемых во время запроса, и уменьшить количество операций ввода-вывода. Кроме того, вертикальное разбиение может упростить структуру таблицы и облегчить ее обслуживание.
Недостатки вертикального шпагата:Первичный ключ будет избыточным, необходимо управлять избыточными столбцами, и это вызовет операцию соединения, которую можно решить, выполнив соединение на уровне приложения. Кроме того, вертикальное разделение может сделать транзакции более сложными;
-
Горизонтальная перегородка:
Сохраняйте структуру таблицы данных неизменной и храните осколки данных с помощью определенной стратегии. Таким образом, каждый фрагмент данных распределяется по разным таблицам или библиотекам для достижения цели распространения. Горизонтальное разбиение может поддерживать очень большие объемы данных.
Горизонтальное разбиение относится к разбиению строк таблицы данных. Когда количество строк в таблице превышает 2 миллиона строк, оно замедляется. В это время данные одной таблицы можно разделить на несколько таблиц для хранения. Например, мы можем разделить таблицу с информацией о пользователях на несколько таблиц с информацией о пользователях, чтобы избежать влияния на производительность, вызванного большим объемом данных в одной таблице.
Разделение воды может поддерживать очень большие объемы данных. Следует отметить, что разделение таблиц решает только проблему, заключающуюся в том, что данные в одной таблице слишком велики, но, поскольку данные таблицы все еще находятся на той же машине, нет никакого смысла улучшать возможности параллелизма MySQL. , такЛучшая подбиблиотека для разделения продуктов воды.
Горизонтально разделенная банкаПоддержка очень большого объема хранилища данных и меньшее преобразование на стороне приложения,ноШардинговые транзакции трудно разрешить, трансграничное соединение имеет низкую производительность и сложную логику. Рекомендовано автором книги "Путь Java-инженеров"Старайтесь не сегментировать данные, потому что сегментирование принесет различные сложности логики, развертывания, эксплуатации и обслуживания., для общей таблицы данных не составляет большой проблемы поддержка объема данных менее 10 миллионов, если она правильно оптимизирована. Если вы действительно хотите сегментировать, попробуйте выбрать архитектуру сегментирования на стороне клиента, которая может сократить сетевой ввод-вывод на один раз и промежуточное программное обеспечение.
Вот два распространенных сценария сегментирования базы данных:
- Клиентский прокси: Логика сегментирования находится на стороне приложения, инкапсулирована в пакет jar и реализована путем изменения или инкапсуляции уровня JDBC.дангдангSharding-JDBC, TDDL Али — две из наиболее часто используемых реализаций.
- Прокси промежуточного ПО: Между приложением и данными добавляется прокси-слой. Логика сегментирования единообразно поддерживается в службе промежуточного программного обеспечения.о чем мы говоримMycat, Atlas 360, DDB Netease и т. д. — все они являются реализациями этой архитектуры.
Для получения подробной информации см.:Схема оптимизации больших таблиц MySQL
Добро пожаловать в мой публичный аккаунт WeChat: "Руководство по прохождению собеседования на Java"(Теплый общедоступный аккаунт WeChat, никакой рекламы, чистый обмен технологиями, я с нетерпением жду прогресса вместе с вами~~~ настаивайте на оригинальности, делитесь красивыми текстами и делитесь различными учебными ресурсами Java. Если вы хотите обратить внимание, обратите внимание, паблик это просто я записываю текст И где ты живешь, не важно какие интересы.)