[Пытка души] MySQL интервью высокочастотные 100 вопросов (направление инженера)

содержание

• содержание
• предисловие
• Корреляция индекса
• связанный с транзакцией
• дизайн структуры таблицы
• Связанный с механизмом хранения
• Разрозненные вопросы
• Справочная статья

предисловие

Основная аудитория этой статьи — разработчики, поэтому она не предполагает развертывания сервиса MySQL и прочих операций, а контента много, все готовы набраться терпения и дынной минералки.

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

Поэтому я решил задать вопрос MySQL Soul 100 и попытаться ответить на вопросы, чтобы углубить свое понимание знаний.

В этой статье мы не будем подробно объяснять mysql из использования select, в основном для некоторых моментов знаний MySQL, которые необходимо знать разработчикам, в основном включая индексы, транзакции, оптимизацию и т. д., в виде часто задаваемых вопросов в интервью Дайте ответ , Если у вас есть другие вопросы на собеседовании по MySQL, которые вы считаете интересными или сложными, вы можете прокомментировать вопросы или отправить электронное письмо по адресуhuyanshi2580@gmail.com, я включу его в эту статью с вашим именем.

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

Принцип индекса MySQL чрезвычайно оптимизирован

Крайний уровень изоляции транзакций MySQL

Корреляция индекса

По поводу индекса MySQL было резюме, ссылка на статью здесьПринцип и оптимизация индекса Mysql.

1. Что такое индекс?

Индекс — это структура данных, которая может помочь нам быстро найти данные.

2. Какой структурой данных является индекс?

Структура данных индекса связана с реализацией конкретного механизма хранения.Наиболее часто используемые индексы в MySQL включают хэш-индекс, индекс дерева B+ и т. д., а реализация индекса по умолчанию для механизма хранения InnoDB, которую мы часто используем: Индекс дерева B+.

3. В чем разница между хэш-индексом и деревом B+?

Прежде всего, вы должны знать основные принципы реализации хэш-индекса и индекса дерева B+:

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

Тогда видно, что они имеют следующие отличия:

• Хэш-индексы быстрее для запросов на равенство (в целом), но не для запросов диапазона.

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

• Хэш-индекс не поддерживает сортировку по индексу, принцип тот же, что и выше.

• Хэш-индекс не поддерживает нечеткий запрос и сопоставление крайнего левого префикса многостолбцового индекса, принцип также связан с тем, что хеш-функция непредсказуема.AAAAиAAAABИндекс не имеет зависимостей.

• Хэш-индекс не может избежать возврата к таблице для запроса данных в любое время, а дерево B+ может завершить запрос через индекс только при соблюдении определенных условий (кластеризованный индекс, покрывающий индекс и т. д.).

• Хотя хеш-индекс быстрее в эквивалентном запросе, он нестабилен. Производительность непредсказуема. Когда определенное значение ключа имеет большое количество повторений, возникает хэш-коллизия, и эффективность может быть крайне низкой. Дерево B+ относительно стабильно, для всех запросов оно идет от корневого узла к конечному узлу, а высота дерева невелика.

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

4. Как упоминалось выше, дереву B+ не нужно запрашивать данные в таблице, если оно удовлетворяет кластеризованному индексу и покрывающему индексу Что такое кластеризованный индекс?

В индексе дерева B+ конечный узел может хранить текущее значение ключа или может хранить текущее значение ключа и данные всей строки, которая является кластеризованным индексом и некластеризованным индексом. индекс первичного ключа — Для кластеризованного индекса, если первичный ключ отсутствует, выбирается уникальный ключ для создания кластеризованного индекса.Если уникальный ключ отсутствует, ключ генерируется неявно для создания кластеризованного индекса.

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

5. Всегда ли некластеризованный индекс будет возвращать табличный запрос?

Не обязательно, это зависит от того, все ли поля, требуемые оператором запроса, попали в индекс.Если все поля попали в индекс, то нет необходимости выполнять запрос обратно к таблице.

В качестве простого примера предположим, что мы создали индекс возраста таблицы сотрудников, тогда, когдаselect age from employee where age < 20При запросе на конечном узле индекса информация о возрасте уже включена, и запрос таблицы возврата не будет выполняться снова.

6. Какие факторы необходимо учитывать при создании индекса?

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

7. Что такое совместный индекс, почему нужно обращать внимание на порядок в совмещенном индексе?

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

Конкретные причины:

Когда MySQL использует индекс, индекс необходимо упорядочить.Предполагая, что объединенный индекс «имя, возраст, школа» теперь установлен, порядок индекса следующий: сначала сортировать по имени, если имена совпадают, то сортировать по возрасту, а если значения возраста тоже равны, то сортировать по школе.

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

8. Использовался ли созданный индекс или как узнать, почему этот оператор работает медленно?

MySQL предоставляет команду объяснения для просмотра плана выполнения оператора. Прежде чем MySQL выполнит оператор, он пройдет через оптимизатор запросов, а затем получит анализ оператора, то есть план выполнения, который содержит много информации. Попадание в индекс можно проанализировать с помощью информации, относящейся к индексу, такой как такие поля, как possilbe_key, key, key_len и т. д., которые соответственно объясняют индекс, который может использовать этот оператор, фактически используемый индекс и длину индекса. использовал.

9. При каких обстоятельствах индекс для этого столбца будет создан, но не будет использоваться во время запроса?

• используя не равный запрос,
• Столбец участвует в математической операции или функции
• Левая часть строки like — это подстановочный знак, похожий на «%aaa».
• Не используйте индекс, когда MySQL анализирует полное сканирование таблицы быстрее, чем при использовании индекса.
• При использовании объединенного индекса первым условием является запрос диапазона, а второе не может использовать индекс, даже если он соответствует принципу крайнего левого префикса.

В приведенных выше случаях MySQL не может использовать файл index.

связанный с транзакцией

1. Что такое транзакция?

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

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

2. Что такое ACID, можете уточнить?

A=Atomicity

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

C=Consistency

Система (база данных) всегда переходит из одного непротиворечивого состояния в другое непротиворечивое состояние, промежуточных состояний нет.

I=Isolation

Изоляция: Вообще говоря: транзакция невидима для других транзакций, пока она не будет полностью зафиксирована.Обратите внимание, что предыдущие обычно добавляются красным цветом, что означает наличие исключений.

D=Durability

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

3. Что делать, если одновременно выполняется несколько транзакций?

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

• Грязное чтение: транзакция A читает незафиксированное содержимое транзакции B, а транзакция B откатывается позже.
• Неповторяемое чтение: при настройке транзакции A можно прочитать только ту часть, которую зафиксировала транзакция B, это вызовет два запроса в транзакции A, и результаты будут разными, поскольку транзакция B зафиксировала операцию в течение этого периода.
• Фантомное чтение: транзакция считывает содержимое диапазона, в то время как транзакция B вставляет часть данных в течение этого периода.Вызывает «иллюзию».

4. Как решить эти проблемы?Вы понимаете уровень изоляции транзакций MySQL?

Четыре уровня изоляции MySQL следующие:

• ЧИТАТЬ БЕЗ ЗАЯВЛЕНИЙ

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

Этот уровень производительности не является достаточно большим преимуществом, но есть много проблем, поэтому он редко используется.

• ПРОЧИТАТЬ СОВЕРШЕНО

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

• ПОВТОРЯЕМОЕ ЧТЕНИЕ

Уровень изоляции повторного чтения решает проблему неповторяемого чтения выше (название вы знаете), но есть еще новая проблема, то есть фантомное чтение.При чтении строки данных с id > 10 добавьте блокировка чтения, в это время транзакция недавно вставила фрагмент данных с идентификатором = 11. Поскольку он был недавно вставлен, он не приведет к исключению вышеуказанной блокировки, тогда следующий запрос этой транзакции обнаружит, что есть a Данные с идентификатором = 11, и последняя операция запроса не получила их, а затем при их вставке возникнет проблема конфликта первичного ключа.

• SERIALIZABLE (сериализуемый)

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

5. Какой уровень изоляции использует Innodb?

InnoDB по умолчанию использует уровень изоляции Repeatable Read.

6. Вы понимаете блокировку MySQL?

При наличии параллельных транзакций в базе данных может возникнуть несогласованность данных.В это время необходимы какие-то механизмы для обеспечения порядка доступа.Таким механизмом является механизм блокировки.

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

7. Какие блокировки есть в MySQL?

Что касается типов блокировки, существуют разделяемые блокировки и эксклюзивные блокировки.

Общая блокировка: также известная как блокировка чтения. Когда пользователь хочет прочитать данные, к данным добавляется общая блокировка. Одновременно можно добавить несколько общих блокировок.

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

Используя приведенный выше пример, можно выделить два типа поведения пользователей. Одно — прийти посмотреть комнату. Несколько пользователей могут вместе посмотреть комнату. Другое – остаться на одну ночь. В течение этого периода, хотят ли они остаться Вы не можете даже хотеть видеть комнату.

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

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

дизайн структуры таблицы

1. Зачем пытаться установить первичный ключ?

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

2. Использует ли первичный ключ автоматически увеличивающийся идентификатор или UUID?

Рекомендуется использовать автоматически увеличивающийся идентификатор вместо UUID.

Поскольку в механизме хранения InnoDB индекс первичного ключа существует как кластеризованный индекс, то есть индекс первичного ключа и все данные (по порядку) хранятся в дочернем узле дерева B+ индекса первичного ключа. ключевой индекс является автоматически увеличивающимся идентификатором, тогда вам нужно только упорядочивать его в обратном порядке.Если это UUID, поскольку входящий идентификатор не определен с исходным размером, это вызовет много вставок и перемещений данных, а затем вызовет много фрагментации памяти, что приведет к падению производительности вставки.

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

Изображение взято из «Высокопроизводительного MySQL»: суффикс по умолчанию — использовать идентификатор автоинкремента,_uuidДля теста с использованием UUID в качестве первичного ключа была проверена производительность вставки строк 100 и 300 строк.

Что касается первичного ключа, то это кластеризованный индекс, если первичный ключ отсутствует, InnoDB выберет уникальный ключ в качестве кластеризованного индекса, а если уникального ключа нет, будет сгенерирован неявный первичный ключ.

If you define a PRIMARY KEY on your table, InnoDB uses it as the clustered index.

If you do not define a PRIMARY KEY for your table, MySQL picks the first UNIQUE index that has only NOT NULL columns as the primary key and InnoDB uses it as the clustered index.

3. Почему поле должно быть определено как ненулевое?

Официальный сайт MySQL представляет:

NULL columns require additional space in the rowto record whether their values are NULL. For MyISAM tables, each NULL columntakes one bit extra, rounded up to the nearest byte.

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

4. Если вы хотите сохранить хэш пароля пользователя, какое поле следует использовать для его хранения?

Строки фиксированной длины, такие как хэши паролей, соли и идентификационные номера пользователей, должны храниться в формате char вместо varchar, что экономит место и повышает эффективность поиска.

Связанный с механизмом хранения

1. Какие механизмы хранения поддерживает MySQL?

MySQL поддерживает различные механизмы хранения, такие как InnoDB, MyISAM, Memory, Archive и т. д. В большинстве случаев наиболее целесообразно использовать механизм InnoDB напрямую, а InnoDB также является механизмом хранения по умолчанию в MySQL.

16. В чем разница между InnoDB и MyISAM?

• InnoDB поддерживает вещи, а MyISAM — нет.
• InnoDB поддерживает блокировку на уровне строк, а MyISAM поддерживает блокировку на уровне таблиц.
• InnoDB поддерживает MVCC, а MyISAM — нет.
• InnoDB поддерживает внешние ключи, а MyISAM — нет.
• InnoDB не поддерживает полнотекстовое индексирование, в отличие от MyISAM.

Разрозненные вопросы

1. В чем разница между varchar и char в MySQL.

char — поле фиксированной длины, если применяетсяchar(10)пространство, то независимо от того, сколько контента фактически хранится.Это поле занимает 10 символов, а varchar имеет переменную длину, то есть применяется только максимальная длина, а занимаемое пространство - это фактическая длина символа + 1, а хранение последнего символа занимает сколько места.

С точки зрения эффективности поиска char> varchar, поэтому при использовании, если вы определяете длину значения поля, вы можете использовать char, в противном случае вам следует попробовать использовать varchar, Например, для хранения зашифрованного пароля пользователя MD5, вы должны использовать char.

2. Что означают varchar(10) и int(10)?

10 из varchar представляет собой размер пространства приложения, а также максимальную длину данных, которые могут быть сохранены, в то время как 10 из int представляет только длину дисплея, а менее 10 бит заполнены 0. То есть, int(1) и int(10) Размер чисел, которые могут быть сохранены, и занимаемое пространство одинаковы, но они отображаются в соответствии с длиной при отображении.

3. Есть несколько входных форматов для MySQL binlog, в чем отличия?

Есть три формата: заявление, строка и смешанный.

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

Кроме того, в новой версии MySQL были сделаны некоторые оптимизации на уровне строк: при изменении структуры таблицы оператор будет записываться вместо строки за строкой.

4. Что делать с негабаритным пейджингом?

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

• Уровень базы данных, на который мы в основном и ориентируемся (хотя эффект не так велик), подобенselect * from table where age > 20 limit 1000000,10Этот тип запроса на самом деле имеет место для оптимизации.Этот оператор должен загрузить 1000000 данных, а затем в основном отбросить их.Конечно, это медленно, чтобы принять только 10. В то время мы можем изменить его какselect * from table where id in (select id from table where age > 20 limit 1000000,10).Хотя таким образом загружается один миллион данных, из-за покрытия индекса все запрашиваемые поля находятся в индексе, поэтому скорость будет очень высокой.В то же время, если идентификаторы непрерывны, мы также можемselect * from table where id > 1000000 limit 10, эффективность тоже хорошая, возможностей для оптимизации много, но основная идея та же, то есть уменьшить нагрузку на данные.
• Сократите этот вид запроса с точки зрения спроса.... В основном не выполняйте аналогичные требования (переход непосредственно на определенную страницу после миллионов страниц. Разрешайте только постраничный просмотр или следуйте заданному маршруту, чтобы вы могли Предсказательный, кэшируемый) и предотвращает утечку идентификатора и непрерывные вредоносные атаки.

На самом деле, решение для большого пейджинга в основном зависит от кэширования, которое может предсказуемо найти контент заранее, кэшировать его в базе данных k-V, такой как Redis, и вернуть его напрямую.

В «Руководстве по разработке Java» от Alibaba решение для сверхбольшого пейджинга аналогично первому, упомянутому выше.

5. Вы были обеспокоены тем, что SQL в бизнес-системе отнимает много времени? Вы подсчитали медленные запросы? Как вы оптимизировали медленные запросы?

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

Чтобы оптимизировать медленный запрос, мы должны сначала понять, в чем причина медлительности: условие запроса не попадает в индекс, загружает ли он ненужный столбец данных или объем данных слишком велик?

Поэтому оптимизация также направлена ​​на эти три направления,

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

• Проанализируйте план выполнения оператора, а затем получите использование индекса, а затем измените оператор или измените индекс, чтобы оператор мог как можно чаще обращаться к индексу.

• Если оптимизацию выписки провести невозможно, можно подумать, не слишком ли велик объем данных в таблице, и если да, то разделить таблицу по горизонтали или по вертикали.

6. Горизонтальный раздельный стол и вертикальный разделенный стол упоминались выше, можете ли вы привести пример, который подходит для них?

Горизонтальная подтаблица разделена на строки. Предположим, у нас есть пользовательская таблица, первичный ключ - это самоувеличивающийся идентификатор и идентификатор пользователя одновременно. Объем данных большой, более 100 миллионов записей, то запрос помещается в таблицу в это время Эффект не идеален Мы можем разделить таблицу в соответствии с идентификатором первичного ключа, независимо от того, разделена ли она на хвостовое число или на интервал идентификатора Предполагая, что она разделена на 100 таблиц в соответствии с хвостовым номером 0-99, то данные только 100 Вт.Эффективность запроса в это время, несомненно, может удовлетворить требования.

Вертикальная таблица разделена на столбцы. Предположим, у нас теперь есть таблица статей. Содержит поля.id-摘要-内容.Форма отображения в системе предназначена для обновления списка, который содержит только заголовок и аннотацию.Когда пользователь нажимает на статью, чтобы ввести подробности, требуется содержание тела.В это время, если объем данных велик , содержимое большое и не большое. Соединение часто используемых столбцов вместе замедлит скорость запроса исходной таблицы. Мы можем разделить приведенную выше таблицу на две части.id-摘要,id-内容. Когда пользователь нажимает на сведения, первичный ключ может снова получить содержимое. Увеличенное хранилище — это всего лишь небольшое поле первичного ключа. Стоимость очень мала.

Конечно, подтаблица на самом деле тесно связана с бизнесом. Перед подтаблицей вы должны провести исследование и сравнительный анализ. Не действуйте вслепую в соответствии со своими собственными предположениями.

7. Что такое хранимая процедура? Какие преимущества и недостатки?

Хранимые процедуры представляют собой некоторые предварительно скомпилированные операторы SQL. 1. Более прямое понимание: можно сказать, что хранимая процедура представляет собой набор записей, который представляет собой блок кода, состоящий из некоторых операторов T-SQL.Эти коды операторов T-SQL реализуют некоторые функции, такие как метод (для одной таблицы или нескольких таблиц). таблицы) добавлять, удалять, изменять и проверять), а затем дать этому блоку кода имя и вызывать его при использовании этой функции. 2. Хранимая процедура представляет собой предварительно скомпилированный блок кода с высокой эффективностью выполнения.Хранимая процедура заменяет большое количество операторов T_SQL, что позволяет уменьшить сетевой трафик, повысить скорость связи и в определенной степени обеспечить безопасность данных.

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

8. Расскажите о трех парадигмах

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

При проектировании структуры базы данных старайтесь соблюдать три парадигмы, если нет, то должны быть достаточные причины.Например, производительность.На самом деле мы часто жертвуем дизайном базы данных ради производительности.

9. В чем разница между # и $ в MyBatis?

Наткнулся на странный вопрос... Я просто хотел задокументировать эту проблему отдельно, потому что она возникает так часто.

# будет обрабатывать входящее содержимое как строку, а $ будет напрямую объединять входящее значение в операторе sql.

Таким образом, # может в определенной степени предотвратить атаки SQL-инъекций.

Заканчивать.

ChangeLog

2019-05-19 Завершено

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

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

Контактный адрес электронной почты: huyanshi2580@gmail.com

Для получения дополнительных заметок по обучению см. личный блог или обратите внимание на вышеуказанный общедоступный аккаунт WeChat------>Хуян тен