MySQL
Советы по производительности Mysql

Оптимизация выписок

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

1. Всякий раз, когда мы используем, где в большой таблице, мы должны убедиться, что столбец в где предложение индексируется или нет. Пример: - выберите * у сотрудника, где user_id> 2000. user_id, если проиндексирован, то ускорит оценку запроса atlot. Индексы также очень важны во время соединений и внешних ключей.

2. Когда вам понадобится меньший раздел контента, а затем извлечение целых данных из таблицы, попробуйте использовать лимит. Вместо этого пишут Ex: - Выберите * у сотрудника. Если вам нужно только первое 20 сотрудников из lakhs, тогда просто используйте лимит Ex: - Выберите * у сотрудника LIMIT 20.

3. Вы также можете оптимизировать свой запрос, указав имя столбца, которое вы хотите в наборе результатов. Вместо этого пишут Ex: - Выберите * у сотрудника. Просто укажите имя столбца, из которого вам нужны данные, если в таблице много столбцов, и вы хотите иметь данные для нескольких из них. Пример: - Выберите идентификатор, имя сотрудника.

4. Индексный столбец, если вы используете для проверки значения NULL в разделе where. Если у вас есть оператор SELECT * FROM tbl_name WHERE key_col IS NULL; то, если key_col проиндексирован, запрос будет оцениваться быстрее.

Оптимизация структуры хранилища для таблиц InnoDB

1. В InnoDB, имеющий длинный PRIMARY KEY (либо один столбец с длинным значением, либо несколько столбцов, которые образуют длинное составное значение), тратит много дискового пространства. Значение первичного ключа для строки дублируется во всех вторичных индексных записях, указывающих на одну и ту же строку. Создайте столбец AUTO_INCREMENT в качестве первичного ключа, если ваш первичный ключ длинный.
2. Используйте тип данных VARCHAR вместо CHAR для хранения строк переменной длины или для столбцов со многими значениями NULL. Столбец CHAR (N) всегда принимает N символов для хранения данных, даже если строка короче или ее значение равно NULL. Меньшие таблицы лучше подходят для пула буферов и уменьшают дисковый ввод-вывод.

При использовании формата строки COMPACT (формат InnoDB по умолчанию) и наборов символов переменной длины, таких как utf8 или sjis, столбцы CHAR (N) занимают переменную площадь, но по меньшей мере N байтов.

3. Для больших таблиц или содержащих много повторяющихся текстовых или числовых данных, используйте формат строки COMPRESSED. Меньше дискового ввода-вывода требуется для переноса данных в буферный пул или для полного сканирования таблиц. Прежде чем принимать постоянное решение, измерьте объем сжатия, который вы можете достичь, используя формат COMPRESSED или COMPACT. Предостережение: тесты редко показывают лучше сжатия 2: 1, и в buffer_pool для COMPRESSED много накладных расходов.
4. Как только ваши данные достигнут стабильного размера, или растущая таблица увеличится на десятки или несколько сотен мегабайт, подумайте об использовании инструкции OPTIMIZE TABLE для реорганизации таблицы и сжатия любого потерянного пространства. Для реорганизованных таблиц требуется меньше операций ввода-вывода диска для полного сканирования таблиц. Это простой способ, который может повысить производительность, когда другие методы, такие как улучшение использования индекса или кода приложения настройки, нецелесообразны. Предостережение . Независимо от размера таблицы, OPTIMIZE TABLE следует выполнять только редко. Это потому, что это дорого, и редко улучшает таблицу настолько, что стоит того. InnoDB неплохо держит свои B + деревья свободными от много потерянного пространства.

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

Построение составного индекса

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

• = столбцы (столбцы) из WHERE . (например, INDEX(a,b,...) для WHERE a=12 AND b='xyz' ... )
• IN column (s); оптимизатор может проскочить через индекс.
• Один «диапазон» (например, x BETWEEN 3 AND 9 , name LIKE 'J%' ). Он не будет использовать ничего в первом столбце диапазона.
• Все столбцы в GROUP BY , чтобы
• Все столбцы в ORDER BY по порядку. Работает только в том случае, если все ASC или все DESC или вы используете 8.0.

Примечания и исключения:

• Не дублируйте столбцы.
• Пропускайте все случаи, которые не применяются.
• Если вы не используете все столбцы WHERE , нет необходимости переходить к GROUP BY и т. Д.
• Бывают случаи, когда полезно индексировать только столбцы ORDER BY , игнорируя WHERE .
• Не «спрячь» столбец в функции (например, DATE(x) = ... не может использовать x в индексе.)
• text_col(99) «Префикс» (например, text_col(99) ) вряд ли будет полезно; может повредить.

Подробнее и советы .