Сопоставление знаний базы данных

база данных

1. Каковы уровни изоляции базы данных, каково их значение и каков уровень изоляции по умолчанию для MYSQL?Чтение незафиксированных: Чтение незафиксированных, как следует из названия, заключается в том, что транзакция может считывать данные другой незафиксированной транзакции.

Чтение зафиксировано: Чтение отправки, как следует из названия, представляет собой транзакцию, ожидающую, пока другая транзакция прочитает данные.

Repeatable read: Повторяющееся чтение, то есть при запуске чтения данных (транзакция открыта), операции модификации больше не допускаются.

Serializable Сериализация: Serializable — это самый высокий уровень изоляции транзакций.На этом уровне транзакции сериализуются и выполняются последовательно, что позволяет избежать грязных чтений, неповторяемых чтений и фантомных чтений. Однако этот уровень изоляции транзакций неэффективен и снижает производительность базы данных, поэтому обычно не используется.

Стоит отметить, что уровень изоляции транзакций по умолчанию для большинства баз данных — Read commited, таких как Sql Server, Oracle.Уровень изоляции Mysql по умолчанию — Repeatable read.

2. Что такое фантомное чтение.

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

Например: программист тратит 2000 юаней на потребление в один день, а потом его жена проверяет его запись потребления сегодня (полное сканирование таблицы FTS, включена транзакция жены), и видит, что 2000 юаней действительно потрачено, только вот в это время, программист потратил 10 000 на покупку компьютера, то есть в INSERT была добавлена ​​новая запись о потреблении и отправлена. Когда жена распечатала список записей о потреблении программатора (предоставленный делами жены), она обнаружила, что потратила 12 000 юаней, что, похоже, было галлюцинацией.Это галлюцинация.

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

1) InnoDB поддерживает транзакции, MyISAM — нет, что очень важно. Транзакция — это расширенный метод обработки, например, при добавлении, удалении и изменении некоторых столбцов, пока возникает ошибка, ее можно откатить и восстановить, а MyISAM — нет.

2) MyISAM подходит для приложений, основанных на запросах и вставках, а InnoDB подходит для частых изменений и приложений, требующих высокой безопасности.

3) InnoDB поддерживает внешние ключи, MyISAM — нет.

4) Начиная с MySQL 5.5.5, InnoDB является движком по умолчанию.

5) InnoDB не поддерживает индексы типа FULLTEXT.

6) InnoDB не сохраняет количество строк в таблице, например select count() из таблицы, InnoDB необходимо просмотреть всю таблицу, чтобы вычислить количество строк, но MyISAM просто считывает количество сохраненных строк. Обратите внимание, что при подсчете () содержит условие where MyISAM также необходимо просмотреть всю таблицу.

7) Для саморастущего поля InnoDB должен содержать индекс только этого поля, но может быть установлен совместный индекс с другими полями в таблице MyISAM.

8) При очистке всей таблицы InnoDB удаляет построчно, что очень медленно. MyISAM перестроит таблицу.

9) InnoDB поддерживает блокировку строк (в некоторых случаях блокируется вся таблица, например, при обновлении таблицы устанавливается a=1, где пользователю нравится «%lee%»

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

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

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

В итоге:

1. Тип MyISAM не поддерживает расширенную обработку, такую ​​как обработка транзакций, в отличие от типа InnoDB.

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

4. Как безопасно изменить одну и ту же строку данных при высоком уровне параллелизма.

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

2), идея кэш-очереди FIFO (First Input First Output, First In First Out). То есть размещение запроса непосредственно в очереди не приведет к тому, что некоторые запросы никогда не получат блокировку. Кажется немного вынужденным превратить многопоточность в однопоточность.

3), используйте оптимистическую блокировку (рекомендуется). По сравнению с «пессимистической блокировкой» применяется более расслабленный механизм блокировки, и большинство из них обновляются номером версии (Version).

Для более подробной информации, пожалуйста, прочитайте:blog.CSDN.net/Riemann_/AR…

5. Что такое оптимистичные блокировки и пессимистичные блокировки, каковы два типа стандартных блокировок на уровне строк в INNODB, и объясните их значение.

Оптимистичный контроль параллелизма (сокращенно «OCC»): это метод управления параллелизмом. Оптимистично, что многопользовательские параллельные транзакции не будут влиять друг на друга во время обработки, и каждая транзакция может обрабатывать свои собственные данные с помощью блокировок.

Пессимистический контроль параллелизма («PCC»): оптимистичной блокировке соответствует пессимистическая блокировка. Пессимистическая блокировка означает, что при работе с данными считается, что в этой операции будет конфликт данных, поэтому каждая операция должна быть получена путем получения блокировки для выполнения операций с одними и теми же данными, что очень похоже на синхронизацию в java, поэтому пессимистично блокировка требует больше времени. они естьОбщие блокировки и эксклюзивные блокировки. Разделяемые блокировки и эксклюзивные блокировки — это разные реализации пессимистической блокировки, и обе относятся к категории пессимистической блокировки.

6. Каковы общие шаги оптимизации SQL, как увидеть план выполнения и как понять значение каждого поля. [1], с помощью команды show status, чтобы понять частоту выполнения различных sql. После успешного подключения клиента mysql информация о состоянии службы может быть предоставлена ​​командой show [session|global] status или получена с помощью команды mysqladmin extend-status.

Обычно интерес представляют следующие статистические параметры: 1), Com_select: сколько раз выполняется операция выбора, и для одного запроса накапливается только 1. 2), Com_insert: количество выполнений операции вставки.Для операции вставки пакетной вставки оно накапливается только один раз. 3), Com_update: сколько раз выполняется операция обновления. 4), Com_delete: сколько раз выполняется операция удаления.

Приведенные выше параметры накапливаются для всех операций с таблицами механизма хранения. Следующие параметры только для innodb, и алгоритм накопления немного отличается: 1), Innodb_rows_read: количество строк, возвращенных запросом на выборку. 2), Innodb_rows_inserted: количество строк, вставленных операцией вставки. 3), Innodb_rows_updated: количество строк, обновленных операцией обновления. 4), Innodb_rows_deleted: количество строк, удаленных операцией удаления.

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

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

Кроме того, следующие параметры удобны для понимания пользователями базового положения базы данных: 1), Connections: количество попыток подключения к серверу mysql 2), Uptime: время работы сервера 3), Slow_queries: количество медленных запросов

[2], оператор sql с низкой эффективностью выполнения запросов:

Найдите эти операторы sql с низкой эффективностью выполнения в журнале медленных запросов.При запуске с параметром --log-slow-queries[=имя_файла] mysqld записывает файл журнала, содержащий все операторы sql, которые выполняются дольше, чем long_query_time секунд.

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

[3] Проанализируйте план выполнения неэффективного SQL с помощью объяснения: после запроса неэффективного оператора SQL вы можете использовать команду объяснения или desc для получения информации о том, как MySQL выполняет оператор выбора, включая то, как таблицы связаны и связаны во время выполнения. оператора select.

Ниже приведены параметры, возвращаемые оператором объяснения:

1), id: порядковый номер запроса на выборку, включая набор чисел, указывающих порядок, в котором предложение выбора или таблица операций выполняются в запросе. три условия: ①, идентификатор тот же: порядок выполнения сверху вниз ②, идентификатор отличается: если это подзапрос, порядковый номер идентификатора будет увеличиваться.Чем больше идентификатор, тем выше приоритет и выполняется первым. ③ Идентификатор имеет как одинаковые, так и разные идентификаторы, и оба существуют одновременно ---> Если идентификатор один и тот же, его можно рассматривать как группу и выполнять сверху вниз; во всех группах больший идентификатор, тем выше приоритет и первая реализация. 2), select_type: тип в основном используется для определения сложности общего запроса, совместного запроса, подзапроса и т. д.

SIMPLE: простой запрос на выборку, который не содержит подзапросов или UNION.

ПЕРВИЧНЫЙ: если запрос содержит какой-либо сложный самозапрос, самый внешний запрос является ПЕРВИЧНЫМ.

ПОДЗАПРОС: Включите подзапрос в SELECT или WHERE.

DERIVED: подзапросы, включенные в список FROM, помечаются как

ПРОИЗВОДНЫЕ MySQL будет рекурсивно выполнять эти подзапросы, помещая результаты во временную таблицу.

UNION: Если второй SELECT появляется после UNION, он помечается как UNION.Если UNION включен в подзапрос предложения FROM, внешний SELECT будет помечен как DERIVED.

РЕЗУЛЬТАТ ОБЪЕДИНЕНИЯ: ВЫБЕРИТЕ, чтобы получить результаты из таблицы ОБЪЕДИНЕНИЯ.

3), таблица: показать, что эта строка данных относится к этой таблице.

4), тип: основные типы следующие:

От лучшего к худшему: system > const > eq_ref > ref > range > index > ALL, как правило, на уровне диапазона, предпочтительно на уровне ссылки.

5).

6), ключи: фактический используемый индекс. Если не нуль, индекс не используется. Если в запросе появляется покрывающий индекс (покрывающий индекс: когда поля запроса и созданный индекс имеют одинаковое количество полей), в индексе появляется только ключ.

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

8), ссылка: столбец, показывающий используемый индекс, если возможно, является константой. Эти столбцы или константы используются для поиска значения в индексе.

9), строки: в соответствии со статистикой таблицы и выбором индекса приблизительно оцените количество строк, чтобы найти нужные записи.

10), Дополнительно: Содержит важную информацию, не подходящую для отображения в других столбцах.

7. Как решить тупик в mysql.

Для возникновения взаимоблокировки необходимы четыре условия:

①, Условие взаимного исключения: ресурс может использоваться только одним процессом одновременно.

②, условия запроса и удержания: когда процесс блокируется из-за запроса ресурсов, он сохраняет полученные ресурсы.

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

④ Условие циклического ожидания: между несколькими процессами формируется своего рода циклическое отношение ресурсов ожидания.

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

Вот два способа устранения взаимоблокировок базы данных:

① Перезапустите базу данных. ②, убить процесс захвата ресурсов

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

Принцип индекса MySql:

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

2) Индекс — это средство повышения производительности запросов данных с помощью сложных алгоритмов. Переход с диска io на memory io.

Типы индексов MySql:

1), обычный индекс индекса: ускорить поиск

2), уникальный индекс: ①, индекс первичного ключа: первичный ключ: ускоренный поиск + уникальное ограничение первичного ключа и не пустой. ②, уникальный индекс: уникальный: ускоренный поиск + уникальное ограничение первичного ключа.

3), совместный индекс:

①, первичный ключ (идентификатор, имя): совместный индекс первичного ключа. ②, уникальный (идентификатор, имя): совместный уникальный индекс. ③, уникальный (идентификатор, имя): совместный общий индекс.

4), полнотекстовый индекс fulltext: при использовании для поиска длинной статьи эффект наилучший.

5), пространственный индекс пространственный: хорошо знать, почти не нужно.

9. Разница между кластеризованным индексом и некластеризованным индексом.

«Кластеризация»: то есть индексы и записи находятся близко друг к другу.

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

10. Что означает выбор для обновления, будет ли он блокировать таблицу, строку или другое.

Оператор select for update — это оператор ручной блокировки, который мы часто используем. С предложением for update мы можем вручную реализовать операции защиты от блокировки данных на уровне приложения. Принадлежит блокировке одновременного освобождения.

11. Почему это реализовано с помощью Btree, как оно разделено, когда оно разделено и почему оно сбалансировано.

Зачем использовать дерево B+? Короче, потому что:

1).Файл очень большой, и хранить его весь в памяти невозможно, поэтому его нужно хранить на диске

2) Структурная организация индекса должна минимизировать количество обращений к диску в процессе поиска (почему использование B-/+Tree также связано с принципом доступа к диску).

3).Принцип локальности и предварительного чтения с диска.Длина предварительного чтения обычно кратна странице (во многих операционных системах размер страницы обычно равен 4k)

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

Ключ больше 1024 для разделения, потому что с увеличением данных ключ узла заполняется, чтобы сохранить характеристики дерева B, произойдет разделение, точно так же, как красно-черное дерево и AVL дерево необходимо вращать, чтобы сохранить характеристики дерева. !

12. Что такое ACID базы данных.

A (атомарный): Атомарность, либо все фиксируются, либо все терпят неудачу, не часть успеха, а часть неудачи.

C (консистентный): согласованность, после запуска и завершения транзакции ограничения согласованности данных не разрушаются.

I (изоляция): изоляция, одновременные транзакции не влияют друг на друга, не мешают друг другу.   D (долговечность): сохранение, обновления, сделанные в базе данных совершенными транзакциями, должны сохраняться постоянно. Даже в случае сбоя его нельзя будет откатить или данные будут утеряны.

13. В таблице почти 10 миллионов данных, CRUD относительно медленный, как оптимизировать.

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

1) Как реляционная база данных, в чем причина такой большой таблицы? Можно ли сделать разбиение таблицы, уменьшить количество полей в одной таблице и оптимизировать структуру таблицы.

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

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

Для более подробного анализа прочитайте статью:blog.CSDN.net/Riemann_/AR…

14. Как Mysql оптимизирует полное сканирование таблицы (table scan).

Избегайте нулевых тестов для полей в предложениях where.

Вы должны стараться избегать использования оператора != или в предложении where, иначе это заставит движок отказаться от использования индекса и выполнить полное сканирование таблицы.

Избегайте использования предложений or in where для объединения условий.

In и not in также следует использовать с осторожностью.

Как запрос (не левый старт).

Не используйте параметр NUM=@num таким образом.

Не указывайте num/2=XX в полях в предложениях where.

Не выполняйте функциональные операции с полями в предложениях where.

15. Как написать sql для эффективного использования составных индексов.

Так как составной индекс = составной индекс, это похоже на соединение нескольких досок вместе.Если середина прервана, это не будет работать.Поэтому, чтобы иметь возможность использовать составной индекс, сначала используйте его в начале (первый столбец ), например index(a,b) Таким образом, мы можем выбрать имя таблицы, где a=XX, чтобы использовать индекс первого столбца.Если мы хотим использовать второй столбец, мы можем и b=XX или и b как ' ТТТ%'.

16. Разница между in и существует в mysql.

Оператор in в mysql представляет собой хеш-соединение между внешней и внутренней таблицами, а оператор exists представляет собой цикл цикла для внешней таблицы, а внутренняя таблица запрашивается каждый раз, когда цикл зацикливается. Все всегда считали, что «существует» более эффективно, чем утверждение «в», что на самом деле неверно. Это чтобы различать окружение.

㊤, если две запрошенные таблицы имеют одинаковый размер, то использование in и exists мало чем отличается.

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

㊦, не в и не существует Если в операторе запроса используется not in, то и внутренняя, и внешняя таблицы будут выполнять полное сканирование таблицы без использования индекса, а подзапрос not extsts по-прежнему может использовать индекс таблицы. Таким образом, независимо от того, насколько велика таблица, использование not exists быстрее, чем not in.

EXISTS возвращает только TRUE или FALSE, а не UNKNOWN IN Когда он сталкивается с ситуацией, содержащей NULL, он возвращает UNKNOWN

17. Возможные проблемы с самоинкрементным первичным ключом базы данных.

[1].Используйте самоувеличивающийся первичный ключ для подбазы данных и подтаблицы базы данных, и могут возникнуть некоторые проблемы, такие как дублирование первичных ключей. [2] При импорте базы данных могут возникнуть проблемы с первичным ключом.

Справочные статьи:В частности, Aliyun.com/articles/38…

18. Сталкивались ли вы с подбиблиотеками и подтаблицами в проектах, которые вы делали?Как их сделать?Полезно ли это для промежуточного программного обеспечения, такого как шардирование jdbc и т.д.Знаете ли вы их принципы?

Справочная статья:Блог woowoo.cn на.com/butterfly10…

19. Как решить задержку master-slave в MYSQL.

На самом деле, задержка синхронизации master-slave вообще никак не может победить врага, потому что все SQL должны выполняться на подчиненном сервере, но если у главного сервера есть непрерывные операции обновления и запись ведется непрерывно, то раз возникает задержка, тогда вероятность усугубления просрочки возрастет. Конечно, мы можем принять некоторые смягчающие меры.

а) Самое простое решение уменьшить задержку синхронизации ведомых устройств — оптимизировать архитектуру и попытаться сделать так, чтобы DDL основной библиотеки выполнялся быстро. Кроме того, написана основная библиотека, которая имеет высокую безопасность данных, например, sync_binlog=1, innodb_flush_log_at_trx_commit = 1 и другие настройки, в то время как slave не нуждается в такой высокой безопасности данных, вы можете установить sync_binlog в 0 или закрыть binlog, innodb_flushlog может также установите значение 0, чтобы повысить эффективность выполнения sql. Другой вариант — использовать в качестве ведомого более качественное аппаратное устройство, чем основная библиотека.

б) Использовать подчиненный сервер в качестве резервного без предоставления запросов, так что его нагрузка будет снижена, а эффективность выполнения SQL в журнале релея естественно будет высокой.

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

Еще отличные статьи:

woo woo woo.cn blog on.com/ask потребление/…

blog.CSDN.net/Чжэн Чжаоя…

изучите golang.com/articles/14…