интервьюер:Почему бы вам не рассказать мне, как вы настроили MySQL?
Кандидат: Ничего себе, это большое предложение ... Я думаю, что для разработчиков основное внимание при настройке MySQL обычно уделяется «спецификациям разработки», «индексированию базы данных» или решению медленных онлайн-запросов.
Кандидат: Настройкой параметров внутри MySQL занимается профессиональный администратор баз данных.
интервьюер: Спустя столько времени вы просто хотите заявить, что не разбираетесь в настройке параметров MySQL, верно?
Кандидат: Трава, была найдена.
интервьюер:Затем давайте поговорим о спецификациях и указателях, которые вы обычно разрабатываете, и о том, как они обычно выглядят.
Кандидат: Ну, во-первых, в производственной среде мы создаем таблицы базы данных в рамках системы рабочих заданий (что, естественно, требует одобрения администратора баз данных). Если будет обнаружено, что при создании таблицы индекс не был создан, предупреждение будет выведено напрямую (:
Кандидат: В теории, если таблица имеет определенное количество данных, он должен создать соответствующий индекс. Все еще есть несколько мест для обращения внимания при запросе данных из базы данных, многие из которых накапливаются в обычных временах. Например:
Кандидат: 1. Можно ли использовать «покрывающий индекс» для сокращения времени, затрачиваемого на «возврат таблицы». Это означает, что при выборе мы должны указывать соответствующий столбец, а не выбирать *
Кандидат: 2. Подумайте, формировать ли «совместный индекс».Если формируется «совместный индекс», постарайтесь поставить самую высокую степень дискриминации на крайний левый, и вам нужно учитывать «крайний левый принцип соответствия»
Кандидат: 3. Выполнение функции или вычисление выражения для индекса приведет к сбою индекса.
Кандидат: 4. Используйте подзапросы для оптимизации сценариев многостраничного пейджинга. Например, limit offset , n в MySQL — это получить записи смещения + n, а затем вернуть n записей. Использование подзапроса заключается в поиске n записей и извлечении соответствующих записей через идентификатор для повышения эффективности запроса.
интервьюер:В порядке…
Кандидат: 5. Просмотрите план выполнения SQL с помощью команды объяснения, чтобы увидеть, прошел ли SQL, написанный вами, индекс, и какой индекс прошел. Используйте профиль показа для просмотра потребления SQL на системных ресурсах (но обычно он используется редко)
Кандидат: 6. После того, как транзакция открыта, работайте с базой данных как можно больше в рамках транзакции и сознательно сокращайте время удержания блокировки (например, если вам нужно вставить && изменить данные в транзакцию, вы можете вставить ее сначала, а затем измените его. Поскольку модификация является операцией обновления, будет добавлена блокировка строки. Если она будет обновлена первой, одновременные запросы могут привести к тому, что несколько запросов транзакций будут ожидать снятия блокировки строки)
интервьюер: Ну, вы упомянули транзакцию, а также раньше говорили об уровне изоляции транзакции.Какой уровень изоляции вы используете в сети?
Кандидат: Ну, здесь мы используем Read Commit, а MySQL по умолчанию использует Repeatable read. Выбор уровня изоляции в основном зависит от сценария приложения, поскольку чем ниже уровень изоляции, тем выше производительность параллелизма транзакций.
Кандидат: (Обычные интернет-компании выбирают Read Commit в качестве основного уровня изоляции)
Кандидат: Как и в случае с уровнем изоляции Repeatable read, могут возникнуть проблемы взаимоблокировки, вызванные «блокировками пробелов».
Кандидат: Но, возможно, вы уже знаете, что уровень изоляции MySQL по умолчанию — Repeatable read. Большая часть причины заключается в том, что вначале в бинарном журнале MySQL не было режима строк, и возникла проблема «несогласованности данных ведущий-ведомый» на уровне изоляции фиксации чтения.
Кандидат: binlog записывает структуру таблицы базы данных и «изменения» данных таблицы, такие как обновление/удаление/вставка/усечение/создание. В MySQL синхронизация master-slave на самом деле реализована с помощью binlog (:
Кандидат: по этой исторической причине MySQL устанавливает уровень изоляции по умолчанию для повторного чтения.
интервьюер: Ну кстати, хочу спросить, сталкивались ли вы с подобными проблемами:Даже если индекс правильный, онлайн-запрос все еще медленный.
Кандидат: Ну, конечно.
интервьюер:Итак, как вы это сделали?
Кандидат: Если индекс правильный, но запрос по-прежнему медленный, то, вообще говоря, объем данных в таблице слишком велик.
Кандидат: Во-первых, подумайте, можно ли "удалить" "старые данные". Для нашей компании мы все синхронизируем данные в Hive, указывая, что копия была сохранена в автономном режиме.
Кандидат: Тогда, если «старые данные» не имеют отношения к запросу, самый простой способ — «удалить» некоторые данные. Объем данных уменьшается, поэтому, естественно, скорость поиска будет выше...
интервьюер: Ну а вообще не удалил
Кандидат: Да, только очень небольшое количество предприятий может удалять данные (:
Кандидат: Тогда рассмотрим другую ситуацию, можно ли перейти непосредственно к слою кеша (Redis) перед запросом.
Кандидат: Если вы используете кеш, это зависит от того, может ли бизнес допустить чтение данных «не в реальном времени» (в конце концов, должна быть гарантирована согласованность данных между Redis и MySQL), если условия запроса относительно сложны и изменчивый (с участием различных групп по и сумме), то это не очень хороший способ использования кеша, и его неудобно поддерживать...
Кандидат: Давайте посмотрим, есть ли сценарий извлечения "строки", который делает запрос неэффективным. Если это так, вы можете рассмотреть возможность импорта данных таблицы в поисковую систему типа Elasticsearch, и последующие онлайн-запросы будут направляться непосредственно в Elasticsearch.
Кандидат: MySQL->Elasticsearch должна иметь соответствующую программу синхронизации (обычно прослушивает бинарный журнал MySQL, анализирует бинарный журнал и импортирует его в Elasticsearch)
Кандидат: Если нет, то рассмотрите возможность создания соответствующей таблицы агрегации в соответствии с измерениями условий запроса и запроса данных в таблице агрегации для онлайн-запросов, не просматривая исходную таблицу.
Кандидат: например, после того, как пользователь разместил заказ, есть сведения о заказе, а список сведений о заказе слишком велик. Однако функция запроса, показанная на стороне продукта (стойка регистрации), отображается в измерении «день», поэтому ежедневные данные каждого пользователя могут быть агрегированы. .
Кандидат: Запрос к таблице идти после полимеризации, эта скорость безусловно Leverage (объем агрегации табличных данных конечно намного меньше исходной)
Кандидат: Общая идея состоит в том, чтобы «обменять пространство на время» и хранить копии тех же данных в других местах для повышения эффективности запросов.
интервьюер:Тогда еще хочу спросить, кроме чтения у производительности записи есть еще и узкое место, что делать?
Кандидат: Когда ты это говоришь, мне больше не хочется спать.
Кандидат: Если в MySQL есть узкие места при чтении и записи, сначала посмотрите на текущую архитектуру MySQL.
Кандидат: Если это одна библиотека, можно ли рассмотреть возможность перехода на архитектуру ведущий-ведомый для достижения разделения чтения и записи.
Кандидат: Простое понимание таково: основная библиотека получает запросы на запись, а подчиненная библиотека получает запросы на чтение. Данные подчиненной библиотеки обновляются двоичным журналом, отправленным главной библиотекой, для достижения согласованности данных ведущий-ведомый (в общих сценариях данные ведущий-ведомый являются асинхронными для обеспечения возможной согласованности).
интервьюер:В порядке…
Кандидат: Если в архитектуре master-slave все еще есть узкое место при чтении и записи, то вам нужно подумать, следует ли использовать подбазу данных и подтаблицу.
Кандидат: По крайней мере, при структуре моей бывшей компании бизнес был дифференцированным. Существует база данных трафика для трафика, база данных для рекламы и база данных для товаров. Следовательно, значение подбиблиотеки и подтаблицы, о которых я здесь говорю, таково: разделение таблицы в исходной библиотеке.
Кандидат: Например, теперь у меня есть таблица бизнес-заказов, эта таблица заказов находится в рекламной библиотеке, предполагая, что эта таблица бизнес-заказов уже имеет объем данных 100 миллионов, теперь я хочу разделить базу данных и таблицу
Кандидат: Затем данные этой таблицы будут разделены на несколько библиотек объявлений и несколько таблиц (:
Кандидат: Наиболее очевидным преимуществом подбазы данных и подтаблицы является равномерная амортизация запросов (оригинал, одна таблица одной базы данных содержит 100 миллионов данных, если я разделю 8 баз данных, то объем данных каждой базы данных составит 1200+). W, под каждую базу данных, разделенную на 8 таблиц, каждая таблица имеет объем данных 150W).
интервьюер:Что вы используете в качестве ключа ветки?
Кандидат: по нашему опыту, вообще говоря, он основан на userId (потому что существует много запросов, основанных на пользовательских параметрах).Если вы хотите запросить на основе других параметров, вам следует обратиться к приведенной выше идее (обменять пространство на время).
интервьюер:Как генерируется идентификатор подбазы данных и подтаблицы?
Кандидат: Это касается способа распределенной генерации ID, есть много идей. Некоторые из них автоматически увеличиваются с помощью MySQL, некоторые автоматически увеличиваются с помощью Redis, а некоторые автоматически увеличиваются на основе «алгоритма снежинки». Какой метод использовать, зависит от технологического стека компании, чаще всего используются реализации на основе Redis и «Алгоритма снежинки».
Кандидат: Что касается того, почему акцент сделан на самоинкремент (это все еще связано с порядком индекса, о котором упоминалось ранее, вы все равно должны помнить)
интервьюер: Хорошо, если я хочу разделить базу данных и таблицу, как выглядит процесс миграции?
Кандидат: мы обычно используем метод "двойной записи" для переноса. Общие шаги таковы:
Кандидат: 1. Запишите каждое добавочное сообщение в новую таблицу и старую таблицу.
Кандидат: 2. Перенести данные старой таблицы в новую базу данных
Кандидат: 3. Рано или поздно данные новой таблицы догонят данные старой таблицы (данные синхронизируются на определенном узле)
Кандидат: В-четвертых, проверьте, являются ли данные новой таблицы и старой таблицы нормальными (в основном зависит от того, могут ли они совпадать)
Кандидат: 5. Включить двойное чтение (часть трафика уходит на новую таблицу, часть трафика уходит на старую таблицу), что эквивалентно процессу градации серого онлайн
Кандидат: 6. Весь читающий трафик обрезается в новую таблицу, а запись в старую таблицу останавливается
Кандидат: Семь, подготовьте механизм отката заранее, временный сбой коммутатора может восстановить нормальный бизнес и соответствующие процедуры для восстановления данных.
интервьюер: Ну... пойдем сегодня сюда
В этой статье делается вывод:
- Если в таблице базы данных есть определенный объем данных, должен быть соответствующий индекс
- При обнаружении медленного запроса проверьте правильность индекса, можно ли использовать лучший индекс для оптимизации скорости запроса и есть ли какие-либо проблемы с позицией использования индекса.
- Когда индекс не может решить медленный запрос, это обычно вызвано большим объемом данных в бизнес-таблице и идеей использования пространства для времени.
- Когда производительность чтения и записи сталкивается с узкими местами, сначала подумайте, можно ли обновить архитектуру базы данных, чтобы решить проблему.Если нет, вам нужно рассмотреть подбазу данных и подтаблицу.
- Хотя подбаза данных и подтаблица могут решить узкое место чтения и записи, они одновременно принесут различные проблемы.Необходимо исследовать решения и наступать на ямы заранее.
Интернет — это не место, где вы можете хвастаться своими навыками, стабильность — это последнее слово. Можно решить простым способом, а не сложным
Добро пожаловать в мой публичный аккаунт WeChat【Java3y] Давайте поговорим о Java-интервью, серия онлайн-интервьюеров постоянно обновляется!
Серия [Онлайн-интервьюер-Мобильный терминал]Продолжаем обновлять два раза в неделю!
【Онлайн-интервьюер-компьютер】СерияПродолжаем обновлять два раза в неделю!
Оригинал это не просто! ! Проси три! !