WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 31. Представление Query Analyzer MySQL Query Analyzer позволяет вам контролировать SQL-операторы, выполненные на сервере MySQL, и показывает детали каждого запроса и время выполнения. Подобные запросы с различными литеральными значениями объединены для сообщения о целях. Query Analyzer собирает информацию относительно SQL-операторов, которые клиентские приложения MySQL посылают в сервер MySQL, используя обзоры схемы Performance (MySQL Server 5.6.14 и выше). Данные могут быть собраны непосредственно от MySQL Server без дополнительной конфигурации, используя агент MySQL Enterprise Monitor. Для получения дополнительной информации о пользовательском интерфейсе Query Analyzer см. раздел 31.3. Как только данные собраны, вы рассматриваете и контролируете запросы, проверяете статистику выполнения, фильтруете и изучаете информацию. Сравнивая запросы с графами сервера, можно коррелировать выполнение запросов со статусом сервера. Для получения дополнительной информации о просмотре, фильтрации и сообщении о данных Query Analyzer см. раздел 31.3. 31.1. Обеспечение данных Query Analyzer MySQL Query Analyzer получает данные из Performance Schema. Performance Schema предоставляет статистическую информацию о запросах, время выполнения, количество результатов и другие данные, чтобы показать и проанализировать на странице Query Analyzer. Используя обзоры Performance Schema с MySQL Server 5.6.14 и выше, данные могут быть собраны непосредственно от MySQL Server без дополнительной конфигурации. 31.1.1. Применение MySQL Performance Schema Данные Query Analyzer автоматически собраны и показаны, контролируя MySQL Server 5.6.14 или выше через функциональность Performance Schema Statement Digests (Performance Schema Statement Digests and Sampling), которую добавили в MySQL 5.6. Невозможно получить данные об обзоре запросов из версий сервера MySQL до MySQL 5.6.14. Сбор данных Query Analyzer из Performance Schema обеспечивает данные о том, как запросы производят свои наборы результатов: Время блокировки таблицы Сколько строк было исследовано Сколько временных таблиц было составлено, и были ли какие-либо созданы на диске Были ли сделаны просмотры диапазона и в какой форме они были сделаны Произошла ли сортировка, сколько строк было сортировано Агент MySQL Enterprise Monitor проверяет таблицу performance_schema.events_statements_summary_by_digest (каждую минуту по умолчанию) и все время вычисляет дельты для каждого из нормализованных запросов, которые выставляются во время окна снимка. Это зависит от установки Performance Schema, позволяющей "statements_digest" в performance_schema.setup_consumers, что включено по умолчанию в MySQL 5.6: mysql> SELECT * FROM performance_schema.setup_consumers WHERE name = 'statements_digest'; +-------------------+---------+ | NAME | ENABLED | +-------------------+---------+ | statements_digest | YES | +-------------------+---------+ Если это не позволено, включите: UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name = 'statements_digest'; Агент MySQL Enterprise Monitor Agent не делает TRUNCATE для таблицы performance_schema.events_statements_summary_by_digest каждый раз, когда это читается, поскольку это возможно, может быть востребовано другими процессами/инструментами, потребляющими эти данные. Из-за этого статистическая величина Max Latency о которой сообщают для нормализованного запроса в Query Analyzer, является на самом деле максимумом начиная с запуска MySQL Server или с последнего вызова TRUNCATE TABLE performance_schema.events_statements_summary_by_digest. Максимальное пространство, доступное для вычисления обзора, составляет по умолчанию килобайт, запросы, превышающие эту длину, усечены. С MySQL 5.7.8 и позже и с 5.6.26 и позже это значение может быть изменено при запуске сервера, установив переменную performance_schema_max_digest_length . В MySQL 5.6.24, 5.6.24, 5.7.6 и 5.7.7 вместо этого используется max_digest_length. Для MySQL 5.7 до 5.7.6 значение не может быть изменено. При этом это не может быть изменено для версий MySQL 5.6 до 5.6.24. Таблица performance_schema.events_statements_summary_by_digest хранится в памяти в рамках Performance Schema, ее размер автоформируется. Чтобы проверить текущий размер: mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema_digests_size'; +---------------------------------+-------+ | Variable_name | Value | +---------------------------------+-------+ | performance_schema_digests_size | 5000 | +---------------------------------+-------+ Если ваше приложение выполняет больше, чем это количество нормализованных запросов, то возможно, что можно начать терять некоторую инструментовку запросов. Можно контролировать эту ситуацию переменной Performance_schema_digest_lost : mysql> SHOW GLOBAL STATUS LIKE 'Performance_schema_digest_lost'; +--------------------------------+-------+ | Variable_name | Value | +--------------------------------+-------+ | Performance_schema_digest_lost | 0 | +--------------------------------+-------+ Если вы обнаруживаете, что эта переменная счетчика растет, рассмотрите увеличение performance_schema_digests_size . Также возможно, что ваш профиль запроса изменялся со временем, и вы теперь выполняете не те запросы, чем были первоначально прослежены (это особенно возможно в очень давно работающих экземплярах). В этом случае вы можете просто выполнить TRUNCATE TABLE performance_schema.events_statements_summary_by_digest, Query Analyzer автоматически начинает собирать данные снова. Если включена функция Example Query, Query Analyzer пытается получить пример самого длинного запроса во время интервала снимка, делая LEFT JOIN с groupwise-max на таблице performance_schema.events_statements_summary_by_digest к таблице performance_schema.events_statements_history_long. Использование этого метода не гарантирует, что запрос в качестве примера всегда предоставляется потому, что по умолчанию таблица events_statements_history_long это кольцевой буфер последних 1000 выполненных запросов. Данные собраны таким образом из Performance Schema, чтобы минимизировать нагрузку на проверенном экземпляре вместо того, чтобы проверять таблицу performance_schema.events_statements_history_long слишком часто, чтобы попытаться собрать статистику. Маленькое подмножество (приблизительно 2 МБ данных) снимка известных предшествующих значений сохраняется в памяти, остальное сбрасывается на диск. Буфер сохранен в $MYSQL_AGENT_HOME /spool/queryAnalysis. Example Query требует, чтобы таблица events_statements_history_long была включена в performance_schema.setup_consumers (это отключено по умолчанию в MySQL 5.6): mysql> SELECT * FROM performance_schema.setup_consumers where name = 'events_statements_history_long'; +--------------------------------+---------+ | NAME | ENABLED | +--------------------------------+---------+ | events_statements_history_long | NO | +--------------------------------+---------+ Если это не позволено, включите: UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name = 'events_statements_history_long'; Когда включены Example Query и Example Explain, MySQL Enterprise Monitor Agent пытается выполнить EXPLAIN для каждого запроса в качестве примера, который обнаружен и работал дольше Auto-Explain Threshold. Из-за способа, которым Performance Schema выставляет нормализованные запросы, усекая любой нормализованный запрос, который длинней 1024 байт из-за проблем памяти в MySQL Server, возможно, что EXPLAIN может потерпеть неудачу, потому что усеченные запросы не разбирают правильно, выполняя EXPLAIN. 31.2. Query Response Time index (QRTi) QRTi это "Query Response Time index". Это "quality of service" для каждого запроса и использует формулу Apdex для вычисления: Apdex on Wikipedia. Как QRTi определяется Три условия измерения "optimum", "acceptable" и "unacceptable", которые определяются как: Таблица 31.1. Определения значений QRTi Тип Временные значения по умолчанию Назначенное значение Описание Цвет Optimum 100ms 1.00 (100%) Оптимальный период времени Зеленый Acceptable 4 * Optimum -- 100ms to 400ms 0.50 (50%) Приемлемый период времени Желтый Unacceptable Exceeds Acceptable -- greater than 400ms 0.00 (0%) Недопустимый период времени Красный Вычисление в качестве примера Мы вычисляем среднее число, чтобы определить заключительное значение QRTi. Например, если есть 100 выполнений канонического запроса, где 60 закончены ниже 100 мс (оптимальный период времени), 30 между 100 мс и 400 мс (приемлемый период времени) и 10 заняли больше времени, чем 400 мс (недопустимое время), тогда QRTi: ((60 + (30/2) + (10*0)) / 100) = 0.75. Чтение значения QRTi У запросов, перечисленных на странице Query Analyzer, есть круговая диаграмма, на которую наносят цветную маркировку, представляющую разбивку, используемую в вычислении QRTi: зеленое представляет оптимальный процент, желтое приемлемый процент, красное недопустимый процент. Вы можете двигать мышь по самой круговой диаграмме, чтобы видеть общее количество выполнения запросов, которое находилось в пределах каждой категории, а также процент выполнения запросов в пределах той группы. Таким образом, делая оптимизацию запросов, стоит начать с тех, у которых есть визуальная круговая диаграмма QRTi, которая является 100% красной, что означает, что у них также есть фактическая ценность QRTi 0. Это означает, что *все* выполнение того запроса заняло больше времени, чем приемлемый период времени (400 мс по умолчанию). Можно нажать на запрос, чтобы получить больше информации, такой как максимальное и среднее время выполнения запроса, среднее количество исследованных строк, среднее время ожидания блокировки, исследовать типовой запрос, посмотреть на пример плана EXPLAIN, видеть, было ли сделано полное сканирование таблицы, исследовать использование индекса и т.д. Можно тогда проложить себе путь от запросов с ценностью QRTi 0 к тем, у которых есть ценность 1 (подразумеват, что все случаи запроса выполнились в течение оптимального периода времени). Как только вы переходите к сути дела, что у вас больше нет запросов с ценностью QRTi меньше 1, тогда можно войти в конфигурацию Query Analysis Reporting Advisor , изменить QRTi Threshold (целевое время) вниз, скажем, 50 мс и начать процесс снова и снова. 31.3. Пользовательский интерфейс Query Analyzer Чтобы открыть Query Analyzer, выберите Queries из навигационного меню. Рис. 31.1. Представление Query Analyzer Таблица 31.2. Управление Query Analyzer Элемент Описание Filters Query Analyzer: содержит следующие системные фильтры: Administration Statements: фильтры на запросах типа GRANT, REVOKE, RESET, SET, SHOW, FLUSH, CACHE, KILL и SHUTDOWN. All Statements: (умолчание) никакая фильтрация не определяется. Все запросы показаны. DDL Statements: фильтры на запросах типа CREATE, DROP, ALTER, TRUNCATE и RENAME. DML Statements: фильтры на запросах типа SELECT, INSERT, UPDATE, DELETE, REPLACE, CALL, LOAD, DO и HANDLER . Prepared Statements: фильтры на запросах типа PREPARE, EXECUTE и DEALLOCATE. Replication Statements: фильтры на запросах типа START, STOP, RESET, и CHANGE. Statements with Errors: фильтры на продвинутых вариантах фильтра Total Errors > 0. Statements with Full Table Scans: фильтры на продвинутых вариантах фильтра Table Scan и Total Table Scans > 0. Statements with Max Exec Time Over 1 Second: фильтры на продвинутых вариантах фильтра Max Exec Time > 1. Statements with Temporary Tables: фильтры на продвинутых вариантах фильтра Total Temporary Tables > 0. Statements with Temporary Tables on Disk : фильтры на продвинутых вариантах фильтра Total Temporary Disk Tables > 0. Statements with Warnings: фильтры на продвинутых вариантах фильтра Total Warnings > 0. Table Maintenance Statements: фильтры на запросах типа OPTIMIZE, ANALYZE, CHECK, REPAIR, и CHECKSUM. Transactional and Locking Statements: фильтры на запросах типа BEGIN, COMMIT, ROLLBACK, SAVEPOINT, RELEASE, LOCK и UNLOCK. Настроенные версии системных фильтров создаются, используя название фильтра с суффиксом -clone. Configure View Открывает представление конфигурации. Configure View позволяет вам настроить данные, показанные согласно представлению Query Analyzer, см. раздел 31.5. Statements Панель statements показывает данные о запросе. Показанные данные формируются в разделе Data View в Configuration View. См. Data View. По умолчанию представление запросов показывает следующее: Круговая диаграмма QRTi: визуальное представление индекса времени отклика запроса. Двигайте курсор по круговой диаграмме, чтобы видеть резюме процентов QRTi Optimal, Acceptable и Unacceptable. Query: показывает нормализованный запрос. Двигайте курсор по запросу, чтобы видеть полную версию. Или щелкните по запросу, чтобы открыть страницу Details. Database: название базы данных, на которой был выполнен запрос. First Seen: время и дата, когда этот запрос был увиден в первый раз в базе данных. Latency: граф, показывающий время ожидания запроса. Двигайте курсор по графу, чтобы показать всплывающую подсказку, содержащую резюме времени ожидания. Total: общая сумма времени, потраченая на этот запрос. Execution Counts: сколько раз этот запрос был выполнен. Rows: количество строк затронуто этим запросом. Все элементы представления запроса конфигурируемы, за исключением самого запроса, который всегда показывается. Чтобы показать полный запрос, наведите курсор на строку запроса. Полный запрос показан во всплывающем окне. Чтобы посмотреть детали запроса, щелкните по нему. Для получения дополнительной информации о странице Details см. раздел 31.4. 31.4. Подробная информация о запросе Нажмите на отдельный запрос, чтобы видеть более подробную информацию об отдельном запросе в представлении Details. Для получения дополнительной информации о Normalization and Statement Digests см. Performance Schema Statement Digests and Sampling. Если вы изменяете контекст, выбирая другой сервер MySQL из меню All Targets, а он не содержит обзор первоначально выбранного запроса, ошибка показана. Страница деталей содержит следующие элементы: Statement Digest перечисляет усеченный идентификатор запроса. Чтобы видеть полную версию, нажмите Show. Чтобы скопировать обзор запроса в буфер обмена, нажмите Copy. Диапазон даты и времени: показывает диапазон времени запроса, как отобрано на странице Query Analyzer. Normalized SQL Statement: показывает выбранный нормализованный SQL-оператор. Statistics: показывает соответствующую статистику для SQL-оператора. Количество выполнений, полное время выполнения и так далее. Graphs: показывает среднее время выполнения, количество выполнений и количество строк, затронутых запросом в выбранном диапазоне времени. Example Statements: (показано только, если включено Example Query) диаграмма распределения запросов по Execution Time в миллисекундах и времени в выбранном диапазоне времени. Example SQL Statements: (показано только, если включено Example Query) Нормализованный SQL-оператор и статистика Normalized SQL Statement показывает нормализованную версию SQL-оператора в то время, как Statistics показывает полезную информацию о выполнении запроса. Рис. 31.2. Normalized Queries and Statistics Графы Граф запроса показывает среднее время выполнения, количество выполнений и количество затронутых строк. Рис. 31.3. Графы деталей запроса Example Statements, Details и EXPLAIN Диаграмма распределения Example Statements графически представляет запрос по времени выполнения и дате и времени. Каждый пункт на диаграмме представляет определенное время выполнения запроса. Рис. 31.4. Диаграмма распределения Example Statements Запросы со связанным планом EXPLAIN представляются кругом в Distribution Chart. У площадей нет плана EXPLAIN. Красный круг или квадрат это SQL-оператор с самым долгим временем выполнения в течение установленного периода. Нажатие на круг или квадрат показывает свой текст запроса в оригинальной форме, подробностях выполнения и его плане EXPLAIN, если EXPLAIN позволен. Отбор одного из пунктов загружает данные для того пункта в структурах деталей Example: Рис. 31.5. Example Statement и Details Рис. 31.6. Пример EXPLAIN 31.5. Представление Query Analyzer Configuration Configuration View позволяет вам настроить данные, показанные согласно представлению Query Analyzer. Рис. 31.7. Configuration View Селектор Graph View Позволяет вам выбрать графы, показанные согласно представлению Query Analyzer и диапазону времени выбранных графов. Чтобы выбрать диапазон времени для графов, выберите значение из секции Zoom. Возможные значения колеблются от одного часа до двух дней. Чтобы выбрать один или несколько графов, чтобы показать согласно представлению Query Analyzer, щелкните в рамке выбора Graph и выберите необходимые графы из доступных параметров. Рис. 31.8. Graph View Filter View Рис. 31.9. Filter View Следующее это возможные варианты фильтра: Column: позволяет вам отфильтровать запросы на основе определенных значений в рамках любой из колонок, показанных в списке отчета Query Analyzer. Чтобы использовать вертикальные фильтры, необходимо определить Column, которую вы хотите отфильтровать, Operator, чтобы использовать, выполняя сравнение, и Value, которое вы хотите сравнить. Например, чтобы отфильтровать на всех запросах, которые возвращают больше 100 строк в среднем, установите Column = Average Rows, Operator = >=, Value = 100. Database: ограничивает запросы выполненным в определенной базе данных. Соответствие базы данных выполняется, используя LIKE от базы данных MySQL, следовательно можно использовать символы % и _ для многих символов и отдельного символа. Для получения дополнительной информации посмотрите Pattern Matching. Notices: Фильтры на уведомлениях, позволяя вам отфильтровать список, чтобы показать только запросы, которые не подняли уведомление, указали на полное сканирование таблицы или указали, что использовался плохой индекс. Statement Text и Value поддерживают текстовый поиск нормализованного запроса. Для типа поиска можно определить, что основной текст соответствует (Contains) или регулярное выражение соответствует (Regex). В дополнение к основному текстовому совпадению можно также искать запрос, который не содержит конкретную последовательность. Для поисков регулярного выражения можно определить, должно ли регулярное выражение соответствовать или нет (отрицательный regexp) запросу. Регулярные выражения разобраны, используя стандартную функцию MySQL REGEXP(). См. Regular Expressions. Поиск выполняется для канонической версии запроса. Вы не можете искать определенный текст или значения в параметрах самого запроса. Statement Type: Ограничивает поиск запросами конкретного типа (SELECT, LITERAL, ...). Time From/To: позволяет вам выбрать диапазон времени для фильтрации. Только запросы, выполненные в показанном периоде времени, показаны, используя всплывающее окно (Hours и Minutes) или можно задать, должен ли выбор быть основан на периоде времени (From/To). Используя это значение, можно показать только запросы, выполненные во время определенного отрезка времени, а можно показать историю запроса для намного более длинного периода времени, столько, сколько вы делали запись информации об анализе запроса. Невозможно использовать сразу Time Interval и Time From\To. Необходимо использовать одно или другое. Time Interval: запросы в данном периоде времени от момента, когда граф был обновлен. Например, если вы выбираете 30 минут, показанные запросы захвачены в течение прошлых 30 минут. Если вы обновили показ в 14:00, показанные запросы захвачены между 13:30 и 14:00. Возможные значения между 15 минутами и 2 годами. Невозможно использовать сразу Time Interval и Time From\To. Необходимо использовать одно или другое. View: определяет, должна ли информация быть возвращена на основе Group, где совокупность того же самого запроса, выполненного на всех проверенных серверах, показывают, или на основе Server, где запросы получены в итоге отдельным сервером. Если последний выбор выбран, запросы могут быть расширены, чтобы перечислить отдельные серверы, на которых они были выполнены. Представление Sort Представление Sort позволяет вам определить, как данные упорядочены в представлении Statements. Рис. 31.10. Представление View Database: база данных по умолчанию во время запроса. Имя базы данных может быть пустым или не соответствовать базе данных, используемой в запросе, если вы использовали компетентное имя таблицы (например, select ... from db_name.table_name) или если применен запрос USE, чтобы переключить базы данных после соединения. Errors: подсвечивает любые конкретные проблемы, испытанные, управляя запросами, включая чрезмерное сканирование таблицы и плохое использование индекса. Они предоставляют непосредственный признак проблемы с запросом, который мог бы потребовать дополнительной экспертизы. Execution Counts: число раз, которое запрос был выполнен. First Seen: дата и время, когда нормализованная версия этого запроса была увидена в первый раз, возможно, ранее, чем период, определенный фильтром. Instance: имя экземпляра MySQL. Latency: время выполнения для всех соответствующих запросов. Это время, для каждого вызова соответствующего запроса, как вычислено, сравнивая время, когда запрос был представлен и когда результаты были возвращены сервером. Времена выражаются в HH:MM:SS.MS (часы, минуты, секунды и миллисекунды). Latency подразделено на следующие группировки: Latency Total: совокупное время выполнения для всего выполнения этого запроса. Latency Maximum: максимальное время выполнения для этого запроса. Latency Average: среднее время выполнения для этого запроса. Locks: время, потраченное на ожидание блокировок таблицы, вызванных запросом. Граф Average History (Avg History): изображает среднее время выполнения в виде графика. Rows: строки, возвращенные запросом. Это подразделено на следующие группировки: Rows Total: количество строк, возвращенных всеми выполнениями запроса. Rows Average: среднее количество строк, возвращенных выполнением запроса. Rows Examined: среднее количество строк, возвращенных всеми выполнениями запроса. Select Type Select Type Full Join: количество соединений, выполняющих сканирование таблицы, потому что они не используют индексы. Select Type Full Range Join: количество соединений, используя диапазон поиска на таблице ссылок. Select Type Range: количество соединений, используя диапазоны на первой таблице. Select Type Range Check: количество соединений без ключей, которые проверяют на ключевое использование после каждой строки. Select Type Scan: количество соединений, выполняющих полный просмотр первой таблицы. Sorting Sorting Merge Passes: количество слияний, которые сделал алгоритм сортировки. Sorting Range: число сортировок, выполненных с использованием диапазонов. Sorting Rows: количество отсортированных строк. Sorting Scan: число сортировок, выполненных просматривая таблицу. Statement: нормализованная версия запроса. Нормализация удаляет определенные для запроса данные так, чтобы различные запросы с различными параметрами данных были идентифицированы как тот же самый основной запрос. Информацию показывают как один запрос на строку. Каждая строка запроса растяжима и может быть расширена, чтобы показать время выполнения для отдельных серверов для этого запроса. Если выбранный контекст это кластер, запросы для узлов SQL показаны для определенного узла или для кластера как совокупности. Если другие типы узлов выбраны, показана именно совокупность. Temporary Tables Temporary Tables Average: среднее количество внутренних временных таблиц, созданных на возникновение запроса. Temporary Tables Disk: общее количество внутренних временных таблиц на диске, которые создаются экземплярами запроса. Temporary Tables Disk % : процент внутренних временных таблиц в памяти, которые были преобразованы в таблицы на диске. Temporary Tables Total: общее количество внутренних временных таблиц в памяти, которые создаются экземплярами запроса. Time: время, в которое были выполнены запросы. Warnings: количество предупреждений, произведенных запросом. Data View Data View формирует элементы, показанные в записях представления Statement. Рис. 31.11. Data View Возможные свойства следующие: Database: название базы данных, на которой был выполнен запрос. Execution Counts: сколько раз запрос был выполнен. First Seen: время и дата, когда запрос был увиден в первый раз. Information Icons: выберите, какие информационные символы вы хотите показать в statement view. Эти символы показаны на правой стороне запроса. Возможный выбор: Notices, Errors или Warnings. Instance Name: название экземпляра MySQL. Latency: время выполнения для запросов. Следующие параметры настройки времени ожидания возможны: History Graph: добавляет граф времени ожидания к данным о запросе. Это изображает в виде графика время ожидания. Total Time: полное время, потраченное всеми выполнениями этого запроса. Maximum Time: максимальное время, потраченное для выполнения этого запроса. Average Time: среднее время выполнения для этого запроса. Lock Time: время, потраченное на ожидание блокировок таблицы, вызванных этим запросом. QRTi Graph: добавляет круговую диаграмму Query Response Time index к левой стороне запроса. Круговая диаграмма изображает процент запросов Optimal, Acceptable и Unacceptable. Rows: сколько строк возвращено. Следующее возможные значения: Total: суммарный итог строк, возвращенных выполнением этого запроса. Examined: общее количество строк, прочитанных этим запросом. Average: среднее количество строк, возвращенных этим запросом. Select Type: следующее возможные значения: Full Join: количество соединений, выполняющих сканирование таблицы, потому что они не используют индексы. Full Range: количество соединений, используя диапазон поиска на таблице ссылок. Range: количество соединений, используя диапазоны на первой таблице. Range Check: количество соединений без ключей, которые проверяют на ключевое использование после каждой строки. Scan: количество соединений, выполняющих полный просмотр первой таблицы. Sorting: следующее возможные значения: Merge Passes: количество слияний через алгоритм сортировки. Range: количество сортировок, используя диапазоны. Rows: количество отсортированных строк. Scan: количество сортировок, выполненных просматривая таблицу. Temporary Tables: следующие значения возможны: Average: среднее количество внутренних временных таблиц, созданных на возникновение запроса. Disk: общее количество внутренних временных таблиц на диске, которые создаются экзеплярами запроса. Disk % : процент внутренних временных таблиц в памяти, которые были преобразованы в таблицы на диске. Total: общее количество внутренних временных таблиц в памяти, которые создаются экземплярами запроса. Настройка фильтров Фильтры могут быть созданы (или существующие настроены) в Query Analyzer Configuration View. Чтобы создать пользовательский фильтр, можно создать фильтр и сохранить его нажатием Save as... или создать новый фильтр при нажатии New, определить критерии фильтра и нажать Save as.... Можно также создать фильтр при помощи существующего фильтра как шаблон. Выберите фильтр и внесите ваши изменения. Если вы создаете названный фильтр на основе существующего фильтра, -clone добавляется к имени, когда вы редактируете новый фильтр. Имя может быть отредактировано как требуется. Системные фильтры перечисляются с замком на левой стороне их имени. Они не могут быть отредактированы, но могут использоваться в качестве шаблонов для новых фильтров. Чтобы установить фильтр как умолчание, выберите его в выпадающем списке и выберите Set as Default из смежного выпадающего меню. Звезда показана рядом с фильтром по умолчанию. Если вы модернизировали от предыдущей версии и использовали умолчание, ваш фильтр переносится и переименовывается в User Default.

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.