1.1. Введение в системную библиотеку
MySQL имеет несколько системных баз данных.Эти базы данных содержат некоторую информацию, необходимую во время работы сервера MySQL, и некоторую информацию о рабочем состоянии.Давайте рассмотрим ее сейчас.
представление_схемы
Эта база данных в основном хранит некоторую информацию о состоянии во время работы сервера MySQL, которую можно рассматривать как мониторинг производительности сервера MySQL. Включая статистику того, какие операторы выполнялись недавно, сколько времени занял каждый этап процесса выполнения, использование памяти и другую информацию.
информационная_схема
Эта база данных содержит информацию обо всех других базах данных, поддерживаемых сервером MySQL, например, какие таблицы, какие представления, какие триггеры, какие столбцы и какие индексы. Это некоторая описательная информация, называемая метаданными.
система
Эта база данных объединяет information_schema и performance_schema в форме представления, чтобы программистам было легче понять некоторую информацию о производительности сервера MySQL.
mysql
В основном он хранит информацию об учетной записи пользователя и полномочиях MySQL, а также некоторую информацию о хранимых процедурах и определениях событий, некоторую информацию журнала, сгенерированную во время работы, некоторую справочную информацию и информацию о часовом поясе и т. д.
1.2.performance_schema
1.2.1 Что такое performance_schema
Performance_schema MySQL — это функция, которая работает на более низком уровне и используется для мониторинга потребления ресурсов и ожидания ресурсов во время работы MySQL Server.Он имеет следующие характеристики.
Запуск на более низком уровне. Собранные элементы относятся к относительно низкоуровневому, например файлы на диске, табличный ввод-вывод, блокировки таблиц и т. д.
• performance_schema предоставляет способ проверки внутреннего выполнения Сервера в режиме реального времени во время работы базы данных. Таблицы в базе данных performance_schema используют механизм хранения performance_schema. База данных в основном фокусируется на данных, связанных с производительностью, во время работы базы данных.
• performance_schema отслеживает внутреннее выполнение сервера, отслеживая события сервера. «События» — это все, что происходит во внутренней деятельности сервера, и соответствующее потребление времени. Используйте эту информацию, чтобы определить, где потребляются соответствующие ресурсы на сервере. . В общем, событие может быть вызовом функции, ожиданием операционной системы, стадией выполнения SQL-оператора [такой как этап парсинга (parsing) или сортировки (сортировки) в процессе выполнения SQL-оператора] или совокупностью весь оператор SQL. Сбор событий может удобно предоставить информацию о синхронном вызове ресурсов, таких как файлы на диске, табличный ввод-вывод и блокировки таблиц соответствующими механизмами хранения на сервере.
• Информация, записанная в текущих активных событиях, исторических событиях и связанных сводных таблицах событий, может предоставить информацию о времени выполнения и продолжительности использования события, которую затем можно использовать для анализа событий, связанных с конкретным потоком или конкретным объектом (таким как как мьютекс или файл) Activity.
• Механизм хранения performance_schema использует «точки обнаружения» в исходном коде Сервера для сбора данных о событиях. В самом механизме реализации performance_schema нет отдельного потока, связанного с инструментированием кода, в отличие от других функций, таких как репликация или планировщик событий.
Собранные данные о событиях сохраняются в таблицах базы данных performance_schema. Для этих таблиц вы можете использовать оператор SELECT для запроса или вы можете использовать оператор SQL для обновления записей таблицы в базе данных performance_schema (например, динамически изменить таблицу конфигурации, начинающуюся с «setup_» в performance_schema, но она должна обратите внимание, что изменение таблицы конфигурации вступит в силу немедленно, что повлияет на сбор данных).
• Данные в таблице performance_schema не будут постоянно храниться на диске, а будут храниться в памяти.При перезапуске сервера данные будут потеряны (все данные по всей performance_schema, включая таблицу конфигурации).
1.2.2. Использование схемы performance_schema
Благодаря приведенному выше введению, я полагаю, вы лучше понимаете, что такое performance_schema. Давайте начнем знакомить с использованием performance_schema.
1.2.3. Проверьте, поддерживает ли текущая версия базы данных
performance_schema считается механизмом хранения, и если он доступен, он должен находиться в
В таблице INFORMATION_SCHEMA.ENGINES или в выходных данных оператора show engine вы можете увидеть, что его значение поля Support равно YES, как показано ниже.
выберите * из INFORMATION_SCHEMA.ENGINES; показать двигатели;
Когда мы видим, что значение поля Support, соответствующего performance_schema, равно YES, это означает, что текущая версия базы данных поддерживает performance_schema. Но если подтверждено, что экземпляр базы данных поддерживает механизм хранения performance_schema, можно ли его использовать? НЕТ, к сожалению, performance_schema не включена по умолчанию в MySQL 5.6 и более ранних версиях, и изменена только для включения по умолчанию в MySQL 5.7 и более поздних версиях.
После запуска mysqld используйте следующий оператор, чтобы проверить, включена ли схема performance_schema (значение ON указывает, что performance_schema была успешно инициализирована и готова к использованию; значение OFF указывает, что при включении performance_schema произошли некоторые ошибки, и вы можете проверьте журнал ошибок для устранения неполадок).
показывать переменные типа «performance_schema»;
(Если вы хотите явно включить или отключить performance_schema , вам нужно использовать параметр performance_schema=ON|OFF , чтобы установить и настроить его в my.cnf . Примечание . Этот параметр доступен только для чтения и должен быть установлен перед экземпляр начинает действовать)
Теперь вы можете узнать, какие таблицы существуют, запросив метаданные, относящиеся к механизму хранения performance_schema, в таблице INFORMATION_SCHEMA.TABLES или с помощью оператора show table в библиотеке performance_schema.
Используйте оператор showtables, чтобы запросить, какие таблицы механизма performance_schema существуют.
Теперь мы знаем, что в текущей версии есть 87 таблиц в библиотеке performance_schema,
Итак, какие данные используются для хранения этих таблиц? Как мы используем их для запроса данных? Давайте сначала посмотрим, как классифицируются эти таблицы.
1.2.4 Классификация таблицы performance_schema
Таблицы в библиотеке performance_schema могут быть сгруппированы в соответствии с различными параметрами мониторинга, например: группировка в соответствии с различными объектами базы данных, группировка в соответствии с различными типами событий или группировка в соответствии с типами событий, а затем дальнейшая группировка в соответствии с учетной записью, хостом, программа, поток, пользователи и т. д. сегментированы.
Ниже описаны таблицы, в которых записываются данные о событиях производительности, сгруппированные по типу события.
• Таблица записей событий операторов: таблица, в которой записывается информация о событиях операторов, в том числе: events_statements_current (текущая таблица событий операторов), events_statements_history (историческая таблица событий операторов), events_statements_history_long (длинная таблица событий хронологических операторов) и некоторые сводные таблицы (агрегированные сводные таблицы). . Среди них сводную таблицу можно подразделить по учетной записи (account), хосту (host), программе (program), потоку (thread), пользователю (user) и глобальному (global).
показывать таблицы типа 'events_statement%';
• Таблица журнала событий ожидания: аналогична таблице журнала событий оператора.
показывать таблицы типа 'events_wait%';
• Таблица записи событий этапа: таблица, в которой записываются события этапа выполнения оператора, аналогичная таблице записи событий оператора.
показывать таблицы типа 'events_stage%';
• Таблица журнала событий транзакций: таблица, в которой записываются события, связанные с транзакциями, аналогично таблице журнала событий операторов.
показывать таблицы типа «events_transaction%»;
• Таблицы, которые отслеживают вызовы уровня файловой системы:
показывать таблицы типа '%file%';
• Таблицы для контроля использования памяти:
показывать таблицы типа '%memory%';
• Таблица конфигурации для динамической настройки performance_schema:
показывать таблицы типа '%setup%';
Теперь у нас есть обзор классификации основных таблиц в performance_schema, но как использовать эти таблицы для предоставления данных о событиях производительности?
1.2.5.простая настройка и использование performance_schema
Когда инициализация базы данных завершена и запущена, не все инструменты (в таблице конфигурации элемента конфигурации коллекции каждый элемент имеет поле переключателя, либо ДА, либо НЕТ) и потребители (аналогично элементу конфигурации коллекции, также имеют соответствующий тип события сохраняет элемент конфигурации таблицы, YES означает, что соответствующая таблица сохраняет данные о производительности, а NO означает, что соответствующая таблица не сохраняет данные о производительности) включены, поэтому по умолчанию все события не будут собираться.
Возможно, событие, которое вы хотите обнаружить, не включено и его необходимо установить. Для открытия соответствующих инструментов и потребителей можно использовать следующие два оператора.В качестве примера для иллюстрации возьмем мониторинг конфигурации и данные об ожидающих событиях.
Чтобы включить элемент конфигурации коллектора для ожидающих событий, необходимо изменить соответствующий элемент конфигурации коллектора в таблице конфигурации setup_instruments.
обновить setup_instruments set enabled = 'yes', timed = 'yes', где имя типа 'wait%';
Включите переключатель элемента конфигурации таблицы сохранения для событий ожидания и измените соответствующий элемент конфигурации в таблице конфигурации setup_consumers.
обновить setup_consumers set enabled='yes', где имя типа 'wait%';
После настройки мы можем проверить, что в данный момент делает сервер. Вы можете узнать, запросив таблицу events_waits_current, что каждый поток в этой таблице содержит только одну строку данных, которая используется для отображения последних событий мониторинга (что вы делаете) каждого потока.
Каждый поток в таблице _current хранит только одну запись, и как только поток завершит свою работу, информация о событии потока больше не будет записываться в таблицу. В таблицу истории записывается информация о событиях каждого выполненного потока, но записывается информация только о 10 событиях каждого потока, и все остальные будут перезаписаны. * Информация о событиях всех потоков записывается в таблицу history_long, но общее количество записей составляет 10 000 строк, которые будут перезаписаны.
Сводная таблица содержит сводную информацию обо всех событиях. Таблицы в этой группе обобщают данные о событиях по-разному (например: по пользователям, по узлам, по потокам и т. д.).
1.2.6 Просмотр последних неудачных операторов SQL
Использование кода для выполнения определенных операций с базой данных (например: использование платформы ORM Java для работы с базой данных) сообщает о синтаксической ошибке, но код не имеет функции записи текста оператора SQL. конкретный текст оператора SQL на уровне базы данных MySQL См. Проверьте, нет ли опечатки? В настоящее время первое, о чем думает большинство людей, — это проверить журнал ошибок. К сожалению, журнал ошибок не записывает синтаксические ошибки операторов SQL.
На самом деле более подробная информация записывается для статуса выполнения каждого оператора в таблице записи событий оператора в performance_schema, например: таблица events_statements и таблица events_statements_summary_by_digest ( в таблице events_statements записываются все сообщения об ошибках выполнения операторов, а в таблице events_statements_summary_by_digest записывается только статистическая информация записывается для инструкции о том, что при выполнении инструкции возникли ошибки, а конкретный тип ошибки не записывается (например, не записывается информация о синтаксических ошибках). Давайте посмотрим, как использовать эти две таблицы для запроса информации об операторе ошибки.
Во-первых, мы моделируем инструкцию SQL с синтаксической ошибкой и используем таблицу events_statements_history_long или таблицу events_statements_history для запроса инструкции SQL синтаксической ошибки:
Затем запросите запись с номером ошибки 1064 в таблице events_statements_history.
выберите * из events_statements_history, где mysql_errno=1064\G
Если вы не знаете номер ошибки, вы можете запросить записи оператора, число ошибок которых не равно 0, и найти в нем поля SQL_TEXT и MESSAGE_TEXT (это тот, чье подсказка является синтаксической ошибкой).
1.2.7 Просмотр последней информации о выполнении транзакции
Мы можем запросить общее время выполнения оператора через журнал медленных запросов, но если в базе данных есть какие-то большие транзакции, которые откатываются во время выполнения или аварийно завершаются во время выполнения, журнал медленных запросов не сможет помочь. в это время. В это время мы можем использовать таблицу events_transactions_* из performance_schema для просмотра записей, связанных с транзакцией. В этих таблицах подробно записывается, была ли транзакция откатана, активна (транзакции, которые не были совершенные в течение длительного времени также являются активными транзакциями) или совершенными.
Прежде всего, его необходимо настроить и включить, события транзакций по умолчанию не включены.
обновить setup_instruments set enabled = 'yes', timed = 'yes', где имя похоже на 'transaction%';
обновить setup_consumers set enabled='yes', где имя типа '%transaction%';
Теперь мы открываем новый сеанс (сеанс 2), чтобы выполнить транзакцию и смоделировать откат транзакции.
Запрос активных транзакций Активные транзакции представляют события транзакций, выполняемые в данный момент, и их необходимо запрашивать из таблицы events_transactions_current.
На рисунке ниже видно, что имеется запись, представляющая текущее активное событие транзакции.
Откат транзакции в сеансе 2:
Запросить текущую таблицу событий транзакций (events_transactions_current) и таблицу истории событий транзакций (events_transactions_history)
Видно, что строка информации о событии транзакции записана в обеих таблицах, а поток, идентификатор потока которого равен 30, выполняет транзакцию, а статус транзакции — ROLLED BACK.
Но когда мы закрываем сессию 2, записи в текущей таблице событий транзакций (events_transactions_current) исчезают.
Для запроса вам необходимо проверить таблицу (events_transactions_history_long)
1.2.8. Резюме
Конечно, использование performance_schema — это нечто большее, чем то, что мы упомянули выше.Он также может обеспечивать, например, просмотр фазы выполнения и информации о ходе выполнения операторов SQL, функцию репликации в кластере MySQL, просмотр подробностей отчетов об ошибках репликации и скоро.
За подробностями обращайтесь на официальный сайт: MySQL :: MySQL 5.7 Reference Manual :: 25 MySQL Performance Schema
1.3.sys системная библиотека
1.3.1.sys инструкции
Системная библиотека sys поддерживает MySQL 5.6 или более поздние версии, но не поддерживает MySQL 5.5.x и более ранние версии.
Системная библиотека sys обычно предоставляется профессиональным администраторам баз данных для устранения некоторых конкретных проблем, и различные запросы, связанные с ней, в той или иной степени влияют на производительность.
Поскольку системная библиотека sys предоставляет некоторые представления вместо прямого доступа к performance_schema, performance_schema должна быть включена (установите для системного параметра performance_schema значение ON), и большинство функций системной библиотеки sys можно использовать в обычном режиме.
В то же время для полного доступа к системной библиотеке sys пользователь должен иметь права администратора для следующих баз данных.
Некоторые функции performance_schema должны быть включены, если вы хотите в полной мере использовать возможности системной библиотеки sys. например:
Включить все инструменты ожидания:
ВЫЗОВ sys.ps_setup_enable_instrument('ждать');
Включить текущую таблицу для всех типов событий:
ВЫЗОВ sys.ps_setup_enable_consumer('текущий');
Примечание. Конфигурация performance_schema по умолчанию может удовлетворять большинству функций сбора данных системной библиотеки sys. При включении всех необходимых функций снижается производительность, поэтому лучше включать только необходимые конфигурации.
1.3.2.sys использование системной библиотеки
Если вы используете оператор USE для переключения базы данных по умолчанию, вы можете напрямую использовать представления в системной библиотеке sys для запросов, точно так же, как запросы к таблицам в определенной библиотеке. Вы также можете использовать db_name.view_name, db_name.procedure_name, db_name.func_name и т. д. для доступа к объектам в системной библиотеке sys без указания базы данных по умолчанию (это называется ссылкой на объект с уточненным именем).
В системной библиотеке sys имеется множество представлений, которые выполняют совокупные вычисления и отображают данные в таблице performance_schema различными способами. Большинство этих представлений появляются парами, два представления имеют одинаковое имя, но одно представление имеет префикс x
host_summary_by_file_io и x$host_summary_by_file_io
Представляет данные о производительности файлового ввода-вывода на основе сводной статистики хоста. Источники данных, к которым обращаются два представления, одинаковы, но в инструкции для создания представления представление без префикса x отображает данные после преобразования единиц измерения соответствующего значение (единицы — миллисекунды, секунды, минуты, часы, дни и т. д.), а представления с префиксом отображают необработанные данные (единицы — пикосекунды).
1.3.3. Посмотрите, где медленная инструкция SQL медленная
Если мы часто сталкиваемся с тем, что оператор медленно выполняется в журнале медленных запросов, и причину этого нельзя найти в структуре таблицы, структуре индекса и статистической информации, мы можем использовать козырную карту в системной библиотеке sys: представление sys.session. в сочетании с performance_schema событий ожидания, чтобы выяснить, что не так. Итак, в чем польза сеансового представления? Используйте его, чтобы просмотреть информацию о списке процессов текущего пользовательского сеанса и узнать, что делает текущий процесс.Обратите внимание, что это представление появляется только в MySQL 5.7.9.
Во-первых, вам нужно включить функции, связанные с ожидающими событиями:
вызовите sys.ps_setup_enable_instrument('wait');
вызовите sys.ps_setup_enable_consumer («ждите»);
Затем смоделируйте это:
Выполнить в сеансе
выберите сон (30);
В другом сеансе запросите в библиотеке sys:
выберите * из сеанса, где command='query' и conn_id !=connection_id()\G
Добавление, удаление, модификация таблицы запросов, объем данных запроса и статистика ввода-вывода, требующая времени.
выберите * из schema_table_statistics_with_buffer\G
1.3.4. Резюме
Кроме того, с помощью sys вы также можете запрашивать и просматривать горячие данные в пуле буферов InnoDB, проверять наличие ожидающих блокировок транзакций, проверять неиспользуемые избыточные индексы, проверять, какие операторы используют полное сканирование таблицы и т. д.
Подробную информацию можно найти на официальном веб-сайте: MySQL :: Справочное руководство по MySQL 5.7 :: 26 MySQL sys Schema
1.4.информационная_схема
1.4.1 Что такое информационная_схема
information_schema обеспечивает доступ к метаданным базы данных, статистической информации и информации о сервере MySQL (например: имя базы данных или имя таблицы, тип данных поля и права доступа и т. д.). Информацию, хранящуюся в этой библиотеке, также можно назвать словарем данных MySQL или системным каталогом.
В каждом экземпляре MySQL существует независимая схема information_schema, которая используется для хранения основной информации обо всех других базах данных в экземпляре MySQL. Библиотека information_schema содержит несколько таблиц только для чтения (непостоянных таблиц), поэтому в каталоге данных на диске нет соответствующих связанных файлов, и для этих таблиц нельзя установить триггеры. Хотя вы можете использовать оператор USE, чтобы установить базу данных по умолчанию как information_schema при запросе, все таблицы в этой базе данных доступны только для чтения, и операции изменения данных, такие как INSERT, UPDATE и DELETE, не могут быть выполнены.
Операции запроса для таблиц в information_schema могут заменить некоторые операторы запроса SHOW (например: SHOW DATABASES, SHOW TABLES и т. д.).
Примечание. В зависимости от версии MySQL количество и объем хранения таблиц различаются. Всего в версии MySQL 5.6 имеется 59 таблиц , а в схеме версии MySQL 5.7 всего 61 таблица .
В MySQL 8.0 таблицы словаря данных (включая некоторые временные таблицы исходного механизма памяти ) в схеме перенесены в схему mysql , и эти таблицы словаря данных скрыты в схеме mysql и не могут быть доступны напрямую. доступ через information_schema
Все таблицы в information_schema используют механизмы хранения Memory и InnoDB и являются временными, а не постоянными таблицами.Эти данные будут потеряны после перезапуска базы данных. Среди 4-х системных библиотек MySQL, information_schema также является единственной системной библиотекой, которая не имеет каталогов и файлов, соответствующих библиотечным таблицам в файловой системе.
1.4.2.Классификация таблиц data_schema
Таблица словаря статистической информации серверного слоя
(1) КОЛОННЫ
• Предоставьте информацию о столбцах (полях) в таблице запроса.
（2）KEY_COLUMN_USAGE
• Предоставляет запрос, для каких столбцов индекса есть ограничения.
• Информация в этой таблице включает информацию об ограничениях, такую как первичный ключ, уникальный индекс, внешний ключ и т. д., например: имя столбца библиотечной таблицы, в которой он расположен, имя столбца библиотечной таблицы, на которую ссылаются, и т. д. Информация в этой таблице несколько похожа на информацию, записанную в таблице TABLE_CONSTRAINTS, но таблица TABLE_CONSTRAINTS не записывает информацию о столбцах библиотечной таблицы, на которые ссылаются ограничения, а в таблице KEY_COLUMN_USAGE записываются типы ограничений, которых нет в таблице TABLE_CONSTRAINTS.
（3）REFERENTIAL_CONSTRAINTS
• Предоставляет запросу некоторую информацию об ограничениях внешнего ключа.
(4) СТАТИСТИКА
• Предоставлять статистику запросов об индексах, индекс соответствует строке записей.
（5）TABLE_CONSTRAINTS
• Предоставлять запрос информации об ограничениях, связанных с таблицами.
(6) ФАЙЛЫ
• Предоставлять информацию запроса, связанную с файлами табличного пространства данных MySQL.
(7) ДВИГАТЕЛИ
• Предоставлять информацию о механизмах запросов, поддерживаемых сервером MySQL.
(8) ТАБЛИЧНЫЕ ПРОСТРАНСТВА
• Предоставлять информацию запроса об активном табличном пространстве (главным образом записывать информацию о табличном пространстве механизма хранения NDB).
• Примечание. Эта таблица не содержит информации о табличном пространстве механизма хранения InnoDB. Для получения метаданных о табличных пространствах InnoDB запросите таблицы INNODB_SYS_TABLESPACES и INNODB_SYS_DATAFILES. Кроме того, начиная с MySQL 5.7.8, таблица INFORMATION_SCHEMA.FILES также предоставляет метаданные для запросов к табличным пространствам InnoDB.
（9）СХЕМЫ
• Предоставлять запрос информации о списке баз данных в MySQL Server, схема представляет базу данных.
Таблица словаря объектов уровня таблицы уровня сервера
（1）ВИДЫ
• Предоставляет информацию о представлениях в базе данных запросов. Учетная запись, которая запрашивает эту таблицу, должна иметь разрешение на просмотр просмотра.
(2) ТРИГГЕРЫ
• Предоставить запрос информации о триггерах в определенной базе данных.
(3) ТАБЛИЦЫ
• Обеспечивает запрос базовой информации, связанной с таблицами в базе данных.
(4) ПРОГРАММЫ
• Предоставляет информацию запроса о хранимых процедурах и хранимых функциях (за исключением пользовательских функций). Информация в этой таблице соответствует информации, записанной в mysql.proc (если в таблице есть значение).
(5) ПЕРЕГОРОДКИ
• Предоставляет информацию запроса о секционированных таблицах.
(6) СОБЫТИЯ
• Обеспечивает запрос информации, связанной с запланированными событиями задачи.
(7) ПАРАМЕТРЫ
• Предоставляет информацию о параметрах хранимых процедур и функций, а также информацию о возвращаемых значениях хранимых функций. Информация о параметрах аналогична содержимому, записанному в столбце param_list в таблице mysql.proc.
Таблица словаря смешанной информации серверного слоя
（1）GLOBAL_STATUS, GLOBAL_VARIABLES, SESSION_STATUS,
SESSION_VARIABLES
• Предоставлять глобальные запросы, переменные состояния уровня сеанса и информацию о системных переменных.
（2）OPTIMIZER_TRACE
• Предоставляет информацию, полученную функцией трассировки оптимизатора.
• Функция трассировки по умолчанию отключена. Используйте системную переменную Optimizer_trace, чтобы включить функцию трассировки. Если эта функция включена, каждый сеанс может отслеживать только операторы, выполняемые им самим, и не может видеть операторы, выполняемые другими сеансами, и каждый сеанс может записывать только последний отслеживаемый оператор SQL.
（3）ПЛАГИНЫ
• Предоставляет информацию запроса о том, какие подключаемые модули поддерживаются сервером MySQL.
（4）СПИСОК ПРОЦЕССОВ
• Предоставляет возможность запрашивать некоторую информацию о состоянии запущенного процесса потока.
(5) ПРОФИЛИРОВАНИЕ
• Предоставляет информацию запроса о профилировании операторов. Содержимое его записи соответствует информации, сгенерированной операторами SHOW PROFILES и SHOW PROFILE. Эта таблица будет записывать информацию об анализе производительности оператора только тогда, когда переменная сеанса профилирования = 1, в противном случае эта таблица не будет записываться.
• Примечание: Начиная с MySQL 5.7.2, эта таблица больше не рекомендуется, она будет удалена в будущих версиях MySQL и заменена Performance Schema.
（6）CHARACTER_SETS
• Укажите доступные наборы символов, поддерживаемые запросом MySQL Server.
(7) ЗАКУСКИ
• Предоставляет доступные правила сопоставления, поддерживаемые запросом MySQL Server.
（8）COLLATION_CHARACTER_SET_APPLICABILITY
• Предоставьте запрос, для которого набор символов в MySQL Server применяется к каким правилам сопоставления. Набор результатов запроса эквивалентен первым двум значениям полей набора результатов, полученного из SHOW COLLATION. До сих пор было обнаружено, что таблица не имеет большого эффекта.
（9）COLUMN_PRIVILEGES
• Предоставлять информацию о разрешениях запроса для столбцов (полей).Содержимое таблицы берется из таблицы разрешений столбцов mysql.column_priv (содержимое будет только после авторизации столбцов таблицы отдельно).
（10）SCHEMA_PRIVILEGES
• Предоставлять запрос информации о разрешениях на уровне библиотеки.Каждый тип разрешений на уровне библиотеки записывает строку информации.Информация в этой таблице поступает из таблицы mysql.db.
（11）TABLE_PRIVILEGES
• Предоставлять информацию запроса о разрешениях на уровне таблицы, содержимое которой берется из таблицы mysql.tables_priv.
（12）USER_PRIVILEGES
• Предоставьте информацию для запроса глобальных разрешений.Информация в этой таблице берется из таблицы mysql.user.
10.2.4 Таблица системного словаря уровня InnoDB
（1）INNODB_SYS_DATAFILES
• Предоставлять метаданные для запроса всех файлов типа табличного пространства InnoDB (внутренний идентификатор табличного пространства и информация о путях к файлам табличного пространства), включая независимое табличное пространство, обычное табличное пространство, системное табличное пространство, временное табличное пространство и пространство отмены (если включено, если вы настроили независимое пространство отмены) .
• Информация в этой таблице эквивалентна информации в таблице SYS_DATAFILES внутри словаря данных InnoDB.
（2）INNODB_SYS_VIRTUAL
• Предоставлять метаданные запроса о виртуальных сгенерированных столбцах InnoDB и связанных столбцах, которые эквивалентны информации таблицы SYS_VIRTUAL в словаре данных InnoDB. Информация о строке, показанная в этой таблице, является информацией для каждого столбца, связанного с виртуальным сгенерированным столбцом.
（3）INNODB_SYS_INDEXES
• Предоставлять информацию метаданных запроса об индексах InnoDB, которая эквивалентна информации в таблице SYS_INDEXES внутри словаря данных InnoDB.
（4）INNODB_SYS_TABLES
• Предоставлять информацию метаданных запроса о таблицах InnoDB, которая эквивалентна информации таблицы SYS_TABLES в словаре данных InnoDB.
（5）INNODB_SYS_FIELDS
• Предоставлять метаданные запроса о ключевых столбцах (полях) индекса InnoDB, которые эквивалентны информации в таблице SYS_FIELDS внутри словаря данных InnoDB.
（6）INNODB_SYS_TABLESPACES
• Предоставлять информацию метаданных запроса о независимых табличных пространствах InnoDB и общих табличных пространствах (включая табличные пространства полнотекстового индекса), которая эквивалентна информации таблицы SYS_TABLESPACES в словаре данных InnoDB.
（7）INNODB_SYS_FOREIGN_COLS
• Предоставлять информацию о статусе запроса о столбцах внешнего ключа InnoDB, которая эквивалентна внутреннему словарю данных InnoDB.
Информация таблицы SYS_FOREIGN_COLS.
（8）INNODB_SYS_COLUMNS
• Предоставлять метаданные запроса о столбцах таблицы InnoDB, которые эквивалентны внутреннему словарю данных InnoDB.
Информация таблицы SYS_COLUMNS.
（9）INNODB_SYS_FOREIGN
• Предоставлять информацию метаданных запроса о внешних ключах InnoDB, которая эквивалентна информации таблицы SYS_FOREIGN в словаре данных InnoDB.
（10）INNODB_SYS_TABLESTATS
• Предоставляет представление для запроса информации о состоянии более низкого уровня о таблицах InnoDB. Оптимизатор MySQL использует эти статистические данные для расчета и определения того, какой индекс использовать при запросе таблиц InnoDB. Эта информация хранится в структурах данных в памяти, которые не соответствуют данным, хранящимся на диске. В InnoDB нет соответствующей системной таблицы.
Блокировки, транзакции, таблицы словаря статистической информации слоя InnoDB
（1）INNODB_LOCKS
• Предоставлять информацию запроса о блокировках, которые запрашиваются транзакциями в механизме InnoDB и одновременно блокируются другими транзакциями (то есть информация о блокировках, которая не ожидает блокировок между различными транзакциями, которые нельзя просмотреть здесь. Например, когда есть только одна транзакция, он не может просмотреть информацию о блокировке, добавленную транзакцией). Содержимое этой таблицы можно использовать для диагностики информации о конфликте блокировок в условиях высокой степени параллелизма.
（2）INNODB_TRX
• Предоставлять информацию о запросе каждой транзакции (за исключением транзакций только для чтения), которая в настоящее время выполняется в механизме InnoDB, включая информацию о том, ожидает ли транзакция блокировку, когда транзакция начинается, а также текстовую информацию оператора SQL, выполняемого транзакцией, и т.д. (если есть SQL-предложение).
（3）INNODB_BUFFER_PAGE_LRU
• Предоставляет информацию о страницах в пуле буферов запросов. В отличие от таблицы INNODB_BUFFER_PAGE, таблица INNODB_BUFFER_PAGE_LRU содержит информацию о том, как страницы в пуле буферов InnoDB вводятся в список LRU, и какие страницы необходимо исключить из пула буферов, когда он не заполнен.
（4）INNODB_LOCK_WAITS
• Предоставлять информацию об ожидании блокировки для запроса транзакций InnoDB. Если запрошенная таблица пуста, это означает, что информация об ожидании блокировки отсутствует; если в запрашиваемой таблице есть записи, это означает, что имеется ожидание блокировки, и каждая запись строки в таблице представляет отношение ожидания блокировки. Отношение ожидания блокировки включает в себя: транзакцию, ожидающую блокировки (то есть запрашивающую блокировку) и такую информацию, как блокировка, которую она ожидает, и транзакцию, удерживающую блокировку (здесь относится к блокировке, которую запрашивает транзакция ожидания блокировки). ) и информацию о блокировках, которые он содержит.
（5）INNODB_TEMP_TABLE_INFO
• Предоставлять информацию запроса о временных таблицах InnoDB, созданных пользователями, которые в данный момент активны в экземпляре InnoDB (действительно только для пользователей, которые установили соединения, а временные таблицы, соответствующие отключенным пользовательским соединениям, будут автоматически удалены). Он не предоставляет информацию о внутренних временных таблицах InnoDB, используемых оптимизатором запросов. Таблица создается при первом запросе.
（6）INNODB_BUFFER_PAGE
• Обеспечивает запросы информации о страницах в пуле буферов.
（7）INNODB_METRICS
• Он предоставляет более подробную информацию о производительности для запросов InnoDB, которая является дополнением к Performance_schema InnoDB. Запрашивая эту таблицу, ее можно использовать для проверки общего состояния InnoDB, а также для диагностики узких мест производительности, нехватки ресурсов и проблем приложений.
（8）INNODB_BUFFER_POOL_STATS
• Предоставлять информацию о состоянии запроса в некоторых пулах буферов InnoDB.Информация, записанная в этой таблице, аналогична статистической информации о пуле буферов, выводимой оператором SHOW ENGINEINNODB STATUS. Кроме того, некоторые переменные состояния пула буферов InnoDB также предоставляют одни и те же значения.
Таблица словаря полнотекстового индекса слоя InnoDB
（1）INNODB_FT_CONFIG
（2）INNODB_FT_BEING_DELETED
（3）INNODB_FT_DELETED
（4）INNODB_FT_DEFAULT_STOPWORD
（5）INNODB_FT_INDEX_TABLE
Связанные со сжатием словарные таблицы уровня InnoDB
（1）INNODB_CMP и INNODB_CMP_RESET
• Данные в этих двух таблицах содержат информацию о рабочем состоянии, связанную со сжатыми страницами таблицы InnoDB. Данные, записанные в таблице, служат эталоном для измерения эффективности сжатия таблиц InnoDB в базе данных.
（2）INNODB_CMP_PER_INDEX и INNODB_CMP_PER_INDEX_RESET
• Эти две таблицы записывают информацию о рабочем состоянии, относящуюся к сжатым табличным данным и индексам InnoDB, и используют различную статистическую информацию для каждой комбинации базы данных, таблицы и индекса, чтобы обеспечить справку для оценки производительности сжатия и практической применимости данных конкретной таблицы.
(3) INNODB_CMPMEM и INNODB_CMPMEM_RESET
• Эти две таблицы записывают информацию о состоянии сжатых страниц в пуле буферов InnoDB, предоставляя справочную информацию для измерения эффективности сжатия таблиц InnoDB в базе данных.
1.4.3. Приложение information_schema
Просмотр информации о столбце индекса
Таблица INNODB_SYS_FIELDS предоставляет информацию метаданных для запросов о столбцах (полях) индекса InnoDB, которая эквивалентна информации таблицы SYS_FIELDS в словаре данных InnoDB.
Таблица INNODB_SYS_INDEXES предоставляет информацию метаданных для запросов об индексах InnoDB, которая эквивалентна информации в таблице SYS_INDEXES внутри словаря данных InnoDB.
Таблица INNODB_SYS_TABLES предоставляет метаданные для запросов о таблицах InnoDB, которые эквивалентны информации таблицы SYS_TABLES в словаре данных InnoDB.
Предположим, что вам нужно запросить связанную информацию, такую как имя столбца индекса, состав и порядок столбца индекса таблицы InnoDB order_exp в библиотеке lijin,
Затем вы можете использовать следующую инструкцию SQL для запроса
ВЫБИРАТЬ
т. ИМЯ КАК d_t_name,
я. ИМЯ КАК i_name,
i.type КАК i_type,
i.N_FIELDS КАК i_column_numbers,
ф. ИМЯ КАК i_column_name,
f.pos AS i_position
ОТ
INNODB_SYS_TABLES КАК Т
ПРИСОЕДИНЯЙТЕСЬ к INNODB_SYS_INDEXES AS i ON t.TABLE_ID = i.TABLE_ID
LEFT JOIN INNODB_SYS_FIELDS AS f ON i.INDEX_ID = f.INDEX_ID
ГДЕ
т. ИМЯ = 'lijin/order_exp';
Все столбцы в результате хорошо понятны, единственный, который требует дополнительного объяснения, — это i_type(INNODB_SYS_INDEXES.type), который представляет собой числовой идентификатор, представляющий тип индекса:
0 = вторичный индекс
1 = кластерный индекс
2 = уникальный индекс
3 = индекс первичного ключа
32 = полнотекстовый индекс
64 = пространственный индекс
128 = Вторичный индекс с виртуальными сгенерированными столбцами.
1.5.системная библиотека mysql в Mysql
1.5.1 Таблица системы разрешений
Поскольку за управление полномочиями отвечает администратор баз данных, мы можем получить общее представление о таблицах в этой части. В системной библиотеке mysql системная таблица полномочий доступа MySQL размещена в библиотеке mysql, в основном включая следующие таблицы.
• пользователь: содержит учетные записи пользователей, глобальные разрешения и другие непривилегированные списки (поле «Конфигурация безопасности» и поле «Управление ресурсами»).
• db: таблица разрешений на уровне базы данных. Информация о разрешениях, записанная в этой таблице, показывает, может ли пользователь использовать эти разрешения для доступа ко всем объектам (таблицам или хранимым процедурам) в базе данных, к которой предоставлен доступ.
• table_priv: таблица привилегий на уровне таблицы.
• columns_priv: таблица привилегий на уровне столбца.
• procs_priv: хранимая процедура и таблица привилегий функций.
• proxies_priv: Таблица привилегий пользователей прокси.
намекать:
Чтобы изменить содержимое таблицы разрешений, вы должны использовать операторы управления учетными записями (такие как: CREATE USER , GRANT , REVOKE* * и т. д.) для косвенного изменения. Не рекомендуется напрямую использовать операторы DML для изменения таблицы разрешений. **
(оператор гранта, отзыва изменит соответствующие записи в таблице разрешений после выполнения и в то же время обновит связанные объекты в памяти, которые записывают разрешения пользователя. Оператор dml напрямую изменяет таблицу разрешений, только изменяет информацию о разрешениях в таблице. , и необходимо выполнить привилегии сброса; для обновления памяти связанный объект, который содержит разрешения пользователя)
1.5.2 Таблица статистики
Функция постоянной статистики предназначена для хранения статистических данных в памяти на диске, чтобы статистическую информацию можно было быстро перечитать при перезапуске базы данных без повторного выполнения статистической информации, чтобы оптимизатор запросов мог использовать эти постоянные данные. статистическая информация Точно выбрать план выполнения (если нет постоянной статистической информации, статистическая информация в памяти будет потеряна после перезапуска базы данных, и статистическая информация должна быть пересчитана при следующем доступе к базе данных, а пересчет может быть связано с тем, что различия в оценках приводят к изменениям в плане запроса, что, в свою очередь, приводит к изменениям в производительности запроса).
Как включить функцию сохранения статистики? Когда innodb_stats_persistent = ON, постоянная функция статистической информации включена глобально, что включено по умолчанию.
показывать переменные типа «innodb_stats_persistent»;
Если вы хотите отключить функцию постоянной статистики для определенной таблицы отдельно, вы можете изменить ее с помощью оператора ALTER TABLE tbl_name STATS_PERSISTENT = 0.
1.5.2.1.innodb_table_stats
Таблица innodb_table_stats предоставляет статистику запросов, связанную с данными таблицы.
выберите * из innodb_table_stats, где table_name = 'order_exp'\G
имя_базы_данных: имя базы данных.
• table_name: имя таблицы, имя раздела или имя подраздела.
• last_update: указывает, когда InnoDB последний раз обновлял строку статистики.
• n_rows: предполагаемое количество строк записи данных в таблице.
• clustered_index_size: размер индекса первичного ключа, оцененный в страницах.
• sum_of_other_index_sizes: общий размер других (не первичных ключей) индексов, оцененный в страницах.
1.5.2.2.innodb_index_stats
Таблица innodb_index_stats предоставляет статистику по запросам и индексам.
выберите * из innodb_index_stats, где table_name = 'order_exp';
Поля таблицы имеют следующие значения.
• имя_базы_данных: имя базы данных.
• table_name: имя таблицы, имя таблицы разделов, имя таблицы подразделов.
• index_name: имя индекса.
• last_update: указывает, когда InnoDB последний раз обновлял строку статистики.
• stat_name: имя статистической информации и соответствующее ему значение статистической информации хранится в поле stat_value.
• stat_value: сохранить значение статистической информации, соответствующее полю stat_name названия статистической информации.
• sample_size: количество образцовых страниц для оценки статистики, указанной в поле stat_value.
• stat_description: описание статистики, указанной в поле stat_name.
Это видно из данных запроса таблицы:
• Поле stat_name имеет следующие статистические значения.
■ размер: когда поле stat_name является значением размера, значение поля stat_value указывает общее количество страниц в индексе.
■ n_leaf_pages: когда поле stat_name имеет значение n_leaf_pages, значение поля stat_value указывает количество конечных страниц индекса.
■ n_diff_pfxNN: NN обозначает числа (например, 01, 02 и т. д.). Когда поле stat_name имеет значение n_diff_pfxNN, значение поля stat_value указывает количество уникальных значений в первом столбце индекса (то есть первый столбец индекса индекса, начиная с первого столбца в последовательности определения индекса ). Например: когда NN равно 01, значение поля stat_value указывает количество уникальных значений первого столбца индекса; когда NN равно 02, значение поля stat_value указывает количество уникальных значений сочетание первого и второго столбцов индекса, так далее и тому подобное. Кроме того, в случае stat_name=n_diff_pfxNN поле stat_description показывает разделенный запятыми список полей статистики вычисляемого индекса.
• Из информации описания «id» поля stat_description, значением поля index_name которого является строка данных PRIMARY, видно, что статистическая информация индекса первичного ключа включает только столбцы, явно указанные при создании индекса первичного ключа.
• Из информации описания «insert_time, order_status, expire_time» поля stat_description, значением поля index_name которого является строка данных u_idx_day_status, видно, что статистическая информация уникального индекса включает только столбцы, явно указанные при создании уникального индекса.
• Из информации описания «order_no,id» поля stat_description, значением поля index_name которого является строка данных idx_order_no, видно, что статистическая информация обычных индексов (неуникальных вспомогательных индексов) включает явно определенные столбцы и столбцы первичного ключа.
Обратите внимание, что в приведенном выше описании, таком как конечные страницы, первый индексный столбец индекса и т. д., эти вещи объясняются в главе индекса и не будут здесь подробно рассматриваться.
1.5.3 Таблица журнала
Система журналов MySQL включает в себя: обычный журнал запросов, журнал медленных запросов, журнал ошибок (записывает сообщения об ошибках, когда сервер запускается, работает и останавливается), двоичный журнал (логический журнал, который записывает изменения данных во время работы сервера) и журнал ретрансляции (записывает журнал изменений данных основной библиотеки, полученный из основной библиотеки потоком ввода-вывода библиотеки), журнал DDL (записывает информацию об изменении метаданных при выполнении оператора DDL. В MySQL 5.7 он поддерживает только запись в файлы, а в MySQL 8.0 — поддерживает запись в таблицу innodb_ddl_log.В MySQL5.7 только общий журнал запросов и журнал медленных запросов поддерживают запись в таблицу (также поддерживает запись в файл) и могут быть сохранены в таблице mysql.general_log и mysql.slow_log с помощью установка таблицы log_output=TABLE, другие типы журналов поддерживают только запись в файлы в MySQL 5.7.
1.5.3.1. общий_лог
Таблица general_log предоставляет информацию о записи выполнения для запроса общих операторов SQL и используется для проверки того, какие операторы SQL клиент выполнил на сервере.
Отключено по умолчанию
показывать переменные типа 'general_log';
включать
set global log_output='TABLE'; -- 'TABLE,FILE' означает одновременный вывод в таблицу и файл установить глобальный general_log=on; показывать переменные типа 'general_log';
После произвольного выполнения запроса
выберите * из mysql.general_log\G
1.5.3.2. slow_log
Таблица slow_log содержит операторы SQL, время выполнения запроса которых превышает значение параметра long_query_time, операторы, которые не используют индексы (необходимо включить параметр log_queries_not_using_indexes=ON) или операторы управления (необходимо включить параметр log_slow_admin_statements=ON).
показывать переменные типа 'log_queries_not_using_indexes'; показывать переменные типа 'log_slow_admin_statements';
включать
установить глобальный log_queries_not_using_indexes=on; установить глобальный log_slow_admin_statements=on; показывать переменные типа 'log_queries_not_using_indexes'; показывать переменные типа 'log_slow_admin_statements';
Мы уже знаем, что журнал медленных запросов может помочь найти операторы SQL, которые могут иметь проблемы, чтобы оптимизировать уровень операторов SQL. Но значение по умолчанию выключено, нам нужно открыть его вручную.
показывать ПЕРЕМЕННЫЕ, такие как 'slow_query_log';
установить ГЛОБАЛЬНЫЙ slow_query_log=1;
Включить 1, выключить 0
Но насколько медленно медленно? В MySQL можно установить пороговое значение, и все операторы SQL, время выполнения которых превышает это значение, записываются в журнал медленных запросов. Параметр long_query_time является этим порогом. Значение по умолчанию — 10, что соответствует 10 секундам.
показывать ПЕРЕМЕННЫЕ, такие как '%long_query_time%';
Конечно, вы также можете установить
установить глобальный long_query_time=0;
По умолчанию 10 секунд, здесь установлено 0 для удобства демонстрации
Затем мы тестируем его, просто пишем SQL
выберите * из mysql.slow_log\G
1.5.4 Статистика в InnoDB
Мы часто использовали некоторые статистические данные, когда говорили о стоимости запроса. Например, мы можем увидеть статистические данные о таблице через SHOW TABLE STATUS, и мы можем увидеть статистические данные об индексе через SHOW INDEX. Так как же эти откуда статистические данные? Как они собираются?
1.5.4.1 Метод хранения статистических данных
InnoDB предоставляет два способа хранения статистических данных:
Постоянная статистика, которая хранится на диске, то есть эта статистика сохраняется после перезапуска сервера.
Непостоянные статистические данные, хранящиеся в памяти, очищаются при выключении сервера и повторно собираются в определенных соответствующих сценариях после перезапуска сервера.
MySQL предоставляет нам системную переменную innodb_stats_persistent, чтобы контролировать, какой метод используется для хранения статистических данных. До MySQL 5.6.6 значение innodb_stats_persistent по умолчанию выключено, что означает, что статистика InnoDB по умолчанию хранится в памяти.В более поздних версиях значение innodb_stats_persistent по умолчанию включено, то есть статистика по умолчанию хранится на диске. .
ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'innodb_stats_persistent';
Однако последние версии MySQL в основном не используют непостоянные статистические данные на основе памяти, поэтому мы не будем углубляться в это.
Однако InnoDB по умолчанию собирает и хранит статистику в единицах таблиц, то есть мы можем хранить статистику некоторых таблиц (и статистику индекса таблицы) на диске, а статистику других таблиц хранить в памяти. Как ты сделал это? Мы можем указать метод хранения статистических данных таблицы, указав атрибут STATS_PERSISTENT при создании и изменении таблицы:
CREATE TABLE 表名 (...) Engine=InnoDB, STATS_PERSISTENT = (1|0);
ALTER TABLE 表名 Engine=InnoDB, STATS_PERSISTENT = (1|0);
Когда STATS_PERSISTENT=1, это означает, что мы хотим постоянно хранить статистические данные таблицы на диске, а когда STATS_PERSISTENT=0, это означает, что мы хотим временно хранить статистические данные таблицы в памяти. Если мы не указываем атрибут STATS_PERSISTENT при создании таблицы, в качестве значения атрибута по умолчанию используется значение системной переменной innodb_stats_persistent.
1.5.4.2 Постоянная статистика на диске
Когда мы выбираем хранение статистических данных таблицы и индекса таблицы на диске, мы фактически сохраняем эти статистические данные в двух таблицах:
ПОКАЗАТЬ ТАБЛИЦЫ ИЗ mysql КАК 'innodb%';
Как видите, эти две таблицы находятся в системной базе данных mysql, где:
innodb_table_stats хранит статистические данные о таблице, и каждая запись соответствует статистическим данным таблицы.
innodb_index_stats хранит статистические данные об индексе, и каждая запись соответствует статистическим данным статистического элемента индекса.
innodb_table_stats
Взгляните непосредственно на то, что делает каждый столбец в таблице innodb_table_stats:
имя_базы_данных имя базы данных
имя_таблицы имя таблицы
last_update Время последнего обновления этой записи
Количество записей в таблице n_rows
clustered_index_size Количество страниц, занимаемых кластеризованным индексом таблицы
Количество страниц, занятых другими индексами таблицы sum_of_other_index_sizes
Посмотрим непосредственно на содержимое этой таблицы:
ВЫБЕРИТЕ * ИЗ mysql.innodb_table_stats;
Значения нескольких важных элементов статистики следующие:
Значение n_rows равно 10 350, что указывает на то, что в таблице order_exp содержится около 10 350 записей. Обратите внимание, что эти данные являются приблизительными.
Значение clustered_index_size равно 97, что указывает на то, что кластеризованный индекс таблицы order_exp занимает 97 страниц, и это значение также является оценочным значением.
Значение sum_of_other_index_sizes равно 81, что указывает на то, что другие индексы таблицы order_exp занимают в общей сложности 81 страницу, и это значение также является оценочным значением.
Коллекция статистических элементов n_rows
InnoDB подсчитывает количество строк в таблице следующим образом:
По определенному алгоритму (не чисто случайному) выбрать несколько страниц листовых узлов, вычислить количество записей значения первичного ключа на каждой странице, а затем вычислить среднее количество записей значения первичного ключа на странице, умноженное на количество всех листовых узлов Значение n_rows таблицы.
Можно видеть, что точность этого значения n_rows зависит от количества страниц, отобранных во время статистики.MySQL использует системную переменную с именем innodb_stats_persistent_sample_pages для управления количеством страниц, отобранных при расчете статистики при использовании постоянной статистики. Чем больше задано значение, тем точнее будет рассчитанное значение n_rows, но статистика займет больше всего времени, чем меньше задано значение, тем менее точным будет вычисленное значение n_rows, но статистика займет больше времени. меньше времени. Поэтому при реальном использовании нужно взвесить все за и против.Значение этой системной переменной по умолчанию равно 20.
По умолчанию InnoDB собирает и хранит статистические данные в единицах таблиц.Мы также можем установить количество страниц выборки для таблицы отдельно.Метод настройки заключается в указании статистических данных таблицы путем указания атрибута STATS_SAMPLE_PAGES при создании или изменении таблицы. таблица Способ хранения:
CREATE TABLE имя таблицы (...) Engine = InnoDB, STATS_SAMPLE_PAGES = определенное количество страниц выборки;
Имя таблицы ALTER TABLE Engine=InnoDB, STATS_SAMPLE_PAGES = определенное количество страниц выборки;
Если мы не укажем атрибут STATS_SAMPLE_PAGES в операторе, который создает таблицу, значение системной переменной innodb_stats_persistent_sample_pages будет использоваться как значение атрибута по умолчанию.
Сбор статистических элементов clustered_index_size и sum_of_other_index_sizes требует очень специфических знаний о табличном пространстве InnoDB и деталях хранения данных страницы, поэтому мы не будем вдаваться в подробности.
innodb_index_stats
Взгляните непосредственно на то, что делает каждый столбец в таблице innodb_index_stats:
описание mysql.innodb_index_stats;
Описание имени поля
имя_базы_данных имя базы данных
имя_таблицы имя таблицы
index_name имя индекса
last_update Время последнего обновления этой записи
stat_name Имя статистического элемента
Значение статистического элемента, соответствующего stat_value
sample_size количество страниц, выбранных для генерации статистики
Описание статистического элемента, соответствующего stat_description
Каждая запись в таблице innodb_index_stats представляет статистический элемент индекса. Возможно, это заставит вас немного запутаться в том, к чему относится этот статистический элемент. Не волнуйтесь, давайте посмотрим на статистику индекса таблицы order_exp:
SELECT * FROM mysql.innodb_index_stats WHERE table_name = 'order_exp';
Сначала проверяем столбец index_name, в котором указано, к какому индексу принадлежит запись.Из результатов видно, что PRIMARY индекс (то есть первичный ключ) занимает 3 записи, а индекс idx_expire_time занимает 6 записей.
Для записей с одним и тем же столбцом index_name stat_name указывает имя статистического элемента для индекса, stat_value показывает значение индекса статистического элемента, а stat_description относится к описанию значения статистического элемента. Посмотрим на статистику индекса:
n_leaf_pages: указывает, сколько страниц занимают конечные узлы индекса.
размер: указывает, сколько страниц занимает индекс в целом.
n_diff_pfxNN: указывает, сколько уникальных значений имеет соответствующий столбец индекса. NN в нем выглядит немного странно, что вы имеете в виду?
На самом деле NN можно заменить на такие числа, как 01, 02, 03.... Например, для u_idx_day_status:
n_diff_pfx01 указывает, сколько уникальных значений в одном столбце insert_time подсчитывается.
n_diff_pfx02 указывает, сколько уникальных значений объединено в двух столбцах статистики insert_time и order_status.
n_diff_pfx03 указывает, сколько уникальных значений объединено в трех столбцах статистики insert_time, order_status и expire_time.
n_diff_pfx04 указывает, сколько неповторяющихся значений объединяется в четырех столбцах статистики key_pare1, key_pare2, expire_time и id.
Для обычных вторичных индексов не гарантируется уникальность значений столбца индекса, например, для idx_order_no в столбце key1 может быть много записей с повторяющимися значениями. В настоящее время только путем добавления значения первичного ключа к столбцу индекса можно различить записи вторичного индекса с тем же значением двух столбцов индекса.
Для первичного ключа и уникального вторичного индекса такой проблемы нет, они могут гарантировать, что значения столбца индекса не повторяются, поэтому нет необходимости подсчитывать количество уникальных значений, добавленных в индекс. значение первичного ключа после столбца индекса. Например, u_idx_day_statu и idx_order_no.
При подсчете количества уникальных значений, содержащихся в некоторых столбцах индекса, необходимо произвести выборку некоторых страниц листовых узлов, а в столбце sample_size указано количество отобранных страниц.
Для объединенного индекса с несколькими столбцами количество выбранных страниц составляет: innodb_stats_persistent_sample_pages × количество столбцов индекса.
Когда количество страниц для выборки больше, чем количество листовых узлов в индексе, полное сканирование таблицы используется непосредственно для подсчета количества уникальных значений в столбце индекса. Таким образом, вы можете видеть в результатах запроса, что значения столбца size, соответствующие разным индексам, могут быть разными.
Регулярно обновляйте статистику
По мере того, как мы продолжаем добавлять, удалять и изменять таблицу, данные в таблице также меняются, и статистика в таблицах innodb_table_stats и innodb_index_stats также меняется. MySQL предоставляет следующие два способа обновления статистики:
Включите innodb_stats_auto_recalc.
Системная переменная innodb_stats_auto_recalc определяет, будет ли сервер автоматически пересчитывать статистику, ее значение по умолчанию — ON, то есть по умолчанию функция включена. Каждая таблица поддерживает переменную, которая фиксирует количество записей, добавленных, удаленных и измененных в таблицу.Если количество измененных записей превышает 10% размера таблицы и включена функция автоматического пересчета статистических данных, то сервер пересчитает статистику и обновит таблицы innodb_table_stats и innodb_index_stats. Однако процесс автоматического пересчета статистических данных происходит асинхронно, то есть, даже если количество измененных записей в таблице превышает 10%, автоматический пересчет статистических данных произойдет не сразу, а может быть задержан на несколько секунд перед расчетом.
Опять же, InnoDB собирает и хранит статистические данные в единицах таблиц по умолчанию.Мы также можем установить атрибут, следует ли автоматически пересчитывать статистику для определенной таблицы.Метод настройки заключается в том, чтобы указать STATS_AUTO_RECALC при создании или изменении атрибутов таблицы, чтобы указать, как статистика хранится для таблицы:
CREATE TABLE 表名 (...) Engine=InnoDB, STATS_AUTO_RECALC = (1|0);
ALTER TABLE имя таблицы Engine=InnoDB, STATS_AUTO_RECALC = (1|0);
Когда STATS_AUTO_RECALC=1, это означает, что мы хотим, чтобы таблица автоматически пересчитывала статистику, когда STATS_AUTO_RECALC=0, это означает, что мы не хотим, чтобы таблица автоматически пересчитывала статистику. Если мы не указываем атрибут STATS_AUTO_RECALC при создании таблицы, в качестве значения атрибута по умолчанию используется значение системной переменной innodb_stats_auto_recalc.
Вручную вызовите инструкцию ANALYZE TABLE, чтобы обновить статистику.
Если значение системной переменной innodb_stats_auto_recalc равно OFF, мы также можем вручную вызвать оператор ANALYZE TABLE для пересчета статистики.Например, мы можем обновить статистику в таблице order_exp следующим образом:
АНАЛИЗ ТАБЛИЦЫ order_exp;
Оператор ANALYZE TABLE немедленно пересчитает статистические данные, то есть процесс является синхронным. Этот процесс может быть особенно медленным, когда в таблице много индексов или слишком много выборочных страниц. Лучше всего запускать его, когда бизнес не очень занят.
Вручную обновите таблицы innodb_table_stats и innodb_index_stats.
По сути, таблицы innodb_table_stats и innodb_index_stats эквивалентны обычной таблице, и мы можем добавлять, удалять, изменять и запрашивать их. Это также означает, что мы можем вручную обновлять статистику таблицы или индекса. Например, если мы хотим изменить статистические данные о количестве строк в таблице order_exp, мы можем сделать это:
Шаг 1: Обновите таблицу innodb_table_stats.
Шаг 2: Позвольте оптимизатору запросов MySQL перезагрузить данные, которые мы изменили.
После обновления innodb_table_stats вы просто изменяете данные таблицы. Вам нужно позволить оптимизатору запросов MySQL перезагрузить данные, которые мы изменили. Просто выполните следующую команду:
FLUSH TABLE order_exp;