Советы:
1. Как обнаружить неэффективные утверждения?
В MySQL, установив --log-slow-queries=[имя файла] в параметрах запуска, вы можете записывать операторы SQL, время выполнения которых превышает long_query_time (по умолчанию 10 секунд), в указанный файл журнала. Вы также можете изменить время длительного запроса в файле конфигурации запуска, например:
# Установите время длительного запроса на 8 секунд
long_query_time=8
2. Как запросить индекс таблицы?
Вы можете использовать оператор SHOW INDEX, например:
SHOW INDEX FROM [имя таблицы]
3. Как запросить использование индекса определенного оператора?
Вы можете использовать оператор EXPLAIN, чтобы увидеть использование индекса определенного оператора SELECT. Если это оператор UPDATE или DELETE, его необходимо сначала преобразовать в оператор SELECT.
4. Как экспортировать содержимое механизма INNODB в файл журнала ошибок.
Мы можем использовать команду SHOW INNODB STATUS для просмотра большого количества полезной информации о механизме INNODB, такой как текущий процесс, транзакции, ошибки внешнего ключа, взаимоблокировка? проблемы и другая статистика. Как включить запись этой информации в файл журнала? Пока вы создаете таблицу innodb_monitor с помощью следующего оператора, MySQL будет записывать систему в файл журнала ошибок каждые 15 секунд:
CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB
Если вам больше не нужно экспортировать в файл журнала ошибок
;, просто удалите. Эта таблица может быть:
DROP TABLE innodb_monitor
5. Как регулярно удалять огромные файлы журналов?
Просто установите время истечения срока действия журнала в файле конфигурации запуска:
expire_logs_days=10
Примечания:
1. Сосредоточьтесь на индексе
. Ниже в качестве примера используется таблица TSK_TASK, иллюстрирующая процесс оптимизации операторов SQL. Таблица TSK_TASK используется для сохранения задач мониторинга системы. Соответствующие поля и индексы:
ID: первичный ключ;
MON_TIME: время создания индекса;
STATUS_ID: состояние внешнего ключа, установленное с помощью SYS_HIER_INFO.ID.
Примечание. MySQL автоматически создаст индексы для внешних ключей. В ходе процесса оптимизации было обнаружено, что эти автоматически созданные индексы внешних ключей будут вызывать ненужное влияние на эффективность операторов SQL. Требуется особое внимание!
Во-первых, мы обнаружили в файле журнала, что выполнение следующего оператора было относительно медленным, более 10 секунд:
# Query_time: 18 Lock_time: 0 Rows_sent: 295 Rows_examined: 88143
select * from TSK_TASK WHERE STATUS_ID = 1064 и MON_TIME >= ' 2007-11 -22' и MON_TIME < '2007-11-23'
Получается, что среди 88143 записей необходимо найти 295 записей, удовлетворяющих условиям, что, конечно, медленно. Быстро используйте оператор EXPLAIN, чтобы проверить использование индекса:
+----+-------------+----------+------+- ---------
| идентификатор_типа | тип | возможные_ключи | длина_ключа | строки +
------------+ ----------+-----------
1 | ПРОСТОЙ | TSK_TASK | ref | FK_task_status_id_TO_SYS_HIER_INFO,TSK_TASK_KEY_MON_TIME
| +-------------+----------+------+--------- --Видно
, что там доступны два индекса: FK_task_status_id_TO_SYS_HIER_INFO, TSK_TASK_KEY_MON_TIME, а индекс внешнего ключа для STATUS_ID используется при окончательном выполнении оператора.
Взглянем еще раз на индекс таблицы TSK_TASK:
+----------+-------------------------- -- --------
| Имя_ключа | Имя_столбца | Мощность |
+----------+-----------+------ -- ---------------
| TSK_TASK | ИДЕНТИФИКАТОР | 999149 |
FK_task_status_ID_TO_SYS_HIER_INFO | STATUS_ID 16
|
-------------------------В Oracle или других реляционных базах данных условия WHERE Порядок полей в индексе играет важную роль при выборе индекс. Давайте изменим порядок полей, поместим STATUS_ID в конец и снова EXPLAIN:
EXPLAIN select * from TSK_TASK WHERE MON_TIME >= '2007-11-22' и MON_TIME < '2007-11-23' и STATUS_ID = 1064,
но это так
;никакого эффекта, MySQL по-прежнему использует индекс внешнего ключа STATUS_ID, созданный системой.
После тщательного анализа оказывается, что атрибут Cardinality (то есть количество уникальных значений в индексе) играет чрезвычайно важную роль при выборе индекса. MySQL выбирает индекс с меньшим количеством уникальных значений. в индексе как индекс всего оператора.
Если для этого оператора вы используете FK_task_status_id_TO_SYS_HIER_INFO в качестве индекса, а таблица TSK_TASK хранит данные в течение многих дней, количество сканируемых записей будет большим, а скорость будет низкой. Доступно несколько решений оптимизации:
если задач в день не так много, мы удаляем индекс FK_task_status_id_TO_SYS_HIER_INFO, тогда MySQL будет использовать индекс TSK_TASK_KEY_MON_TIME, а затем сканировать записи со STATUS_ID 1064 в данных этого дня, что не медленно ;
Если задач в день много, нам нужно удалить индексы FK_task_status_id_TO_SYS_HIER_INFO и TSK_TASK_KEY_MON_TIME, а затем создать совместный индекс STATUS_ID, MON_TIME, что определенно будет очень эффективно.
Поэтому рекомендуется не использовать внешние ключи для таблиц с большим количеством записей, чтобы избежать серьезного снижения эффективности производительности.
2. Старайтесь контролировать количество записей в каждой таблице.
Когда количество записей в таблице велико, управление и обслуживание будут очень затруднительными. Например, обслуживание индекса займет много времени, что приведет к серьезным нарушениям работы. нормальная работа системы.
Для таблиц, объем данных которых продолжает расти с течением времени, мы можем различать данные реального времени и исторические данные на основе времени. Мы можем использовать программу фонового обслуживания для регулярного перемещения данных из таблицы реального времени в историческую таблицу, тем самым контролируя. количество записей в таблице реального времени и повышение производительности запросов и эффективности работы. Но учтите, что время каждого хода должно быть достаточно коротким, чтобы не влиять на запись данных в обычной программе. Если это займет слишком много времени, это может вызвать проблему взаимоблокировки.
3. Стратегия хеширования (разделения) данных.
Когда количество клиентов достигает определенного масштаба, одна база данных не сможет поддерживать более высокий одновременный доступ. В это время вы можете рассмотреть возможность хеширования (разделения) данных о клиентах в несколько баз данных для этого. Распределите нагрузку. Улучшите общую производительность и эффективность системы.