8.2.5. Другие Подсказки по Оптимизации

Используйте персистентные соединения с базой данных, чтобы избежать издержек соединения. Если невозможно использовать персистентные соединения, и Вы инициируете много новых соединений с базой данных, можно хотеть изменить значение thread_cache_size переменная. См. Раздел 8.11.2, "Настраивая Параметры Сервера".

Всегда проверяйте, используют ли все Ваши запросы действительно индексирование этого, Вы создали в таблицах. В MySQL можно сделать это с EXPLAIN оператор. См. Раздел 8.8.1, "Оптимизируя Запросы с EXPLAIN".

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

MyISAM поддерживает параллельные вставки: Если у таблицы нет никаких свободных блоков в середине файла данных, Вы можете INSERT новые строки в это в то же самое время, когда другие потоки читают из таблицы. Если важно быть в состоянии сделать это, рассмотреть использование таблицы способами, которые избегают удалять строки. Другая возможность состоит в том, чтобы работать OPTIMIZE TABLE дефрагментировать таблицу после того, как Вы удалили много строк от этого. Это поведение изменяется, устанавливая concurrent_insert переменная. Можно вынудить новые строки быть добавленными (и поэтому разрешить параллельные вставки), даже в таблицах, которые удалили строки. См. Раздел 8.10.3, "Параллельные Вставки".

Устранить любые проблемы сжатия, которые, возможно, произошли с ARCHIVE таблицы, можно использовать OPTIMIZE TABLE. См. Раздел 14.6," ARCHIVE Механизм хранения".

Использовать ALTER TABLE ... ORDER BY expr1, expr2, ... если Вы обычно получаете строки в expr1, expr2, ... порядок. При использовании этой опции после обширных изменений к таблице можно быть в состоянии получить более высокую производительность.

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

SELECT * FROM tbl_name  WHERE hash_col=MD5(CONCAT(col1,col2))  AND col1='constant' AND col2='constant';

Для MyISAM таблицы, которые часто изменяются, пытаются избежать всех столбцов переменной длины (VARCHAR, BLOB, и TEXT). Таблица использует динамический формат строки, если это включает даже единственный столбец переменной длины. См. Главу 14, Механизмы Хранения.

Обычно не полезно разделить таблицу на различные таблицы только, потому что строки становятся большими. В доступе к строке самый большой хит производительности является поиском на диске, должен был найти первый байт строки. После обнаружения данных самые современные диски могут считать всю строку достаточно быстро для большинства приложений. Единственные случаи, где разделение таблицы имеет заметное значение, - то, если это - a MyISAM таблица используя динамический формат строки, который можно изменить на фиксированный размер строки, или если Вы очень часто должны сканировать таблицу, но не нуждаться в большинстве столбцов. См. Главу 14, Механизмы Хранения.

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

UPDATE tbl_name SET count_col=count_col+1 WHERE key_col=constant;

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

Если Вы должны собрать статистические данные от больших таблиц журнала, используйте сводные таблицы вместо того, чтобы сканировать всю таблицу журнала. Поддержание сводок должно быть намного быстрее чем попытка вычислить "живую" статистику. Регенерация новых сводных таблиц от журналов, когда вещи изменяются (в зависимости от бизнес-решений) быстрее чем изменение рабочего приложения.

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

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

В некоторых случаях удобно упаковать и хранить данные в a BLOB столбец. В этом случае следует обеспечить код в своем приложении, чтобы упаковать и распаковать информацию, но это может сохранить много доступов на некотором этапе. Это практично, когда у Вас есть данные, которые не соответствуют хорошо структуре таблицы строк-и-столбцов.

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

Сохраненные подпрограммы или UDFs (определяемые пользователем функции) могут быть хорошим способом получить производительность для некоторых задач. См. Раздел 18.2, "Используя Сохраненные Подпрограммы (Процедуры и Функции)", и Раздел 22.3, "Добавляя Новые Функции к MySQL", для получения дополнительной информации.

Можно увеличить производительность, кэшируя запросы или ответы в Вашем приложении, и затем выполнение многих вставляет или обновляет вместе. Если Ваша система баз данных поддерживает блокировки таблицы (как делает MySQL), это должно помочь гарантировать, что индексировать кэш только сбрасывается однажды после всех обновлений. Можно также использовать в своих интересах кэш запроса MySQL, чтобы достигнуть подобных результатов; см. Раздел 8.9.3, "MySQL Query Cache".

Используйте многократную строку INSERT операторы, чтобы сохранить много строк одним SQL-оператором. (Это - относительно переносимый метод.)

Использовать LOAD DATA INFILE загрузить большие объемы данных. Это быстрее чем использование INSERT операторы.

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

Использовать OPTIMIZE TABLE время от времени избегать фрагментации с динамическим форматом MyISAM таблицы. См. Раздел 14.3.3,"MyISAM Табличные Форматы Хранения".

Использовать MEMORY таблицы когда возможный, чтобы получить больше скорости. См. Раздел 14.4," MEMORY Механизм хранения". MEMORY таблицы полезны для некритических данных, к которым часто получают доступ, такие как информация о последнем выведенном на экран баннере для пользователей, которым не включали cookie в их Веб-браузере. Сеансы пользователя являются другой альтернативой, доступной во многих средах Веб-приложения для того, чтобы обработать энергозависимые данные состояния.

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

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

Попытайтесь сохранить имена столбцов простыми. Например, в таблице называется customer, используйте имя столбца name вместо customer_name. Чтобы сделать Ваши имена переносимыми на другие SQL-серверы, рассмотрите хранение их короче чем 18 символов.

Если Вы нуждаетесь в действительно высокой скорости, смотрите на низкоуровневые интерфейсы для хранения данных, которое поддерживают различные SQL-серверы. Например, получая доступ к MySQL MyISAM механизм хранения непосредственно, Вы могли получить увеличение скорости двух - пяти раз по сравнению с использованием интерфейса SQL. Чтобы быть в состоянии сделать это, данные должны быть на том же самом сервере как приложение, и обычно к этому должен только получить доступ один процесс (потому что внешний захват файла является действительно медленным). Можно было устранить эти проблемы, представляя низкий уровень MyISAM команды в сервере MySQL (это могло быть одним легким способом получить больше производительности если нужно). Тщательно разрабатывая интерфейс базы данных, должно быть довольно легко поддерживать этот тип оптимизации.

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

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

Объявление a MyISAM таблица с DELAY_KEY_WRITE=1 табличная опция делает, индексируют обновления быстрее, потому что они не сбрасываются к диску, пока таблица не закрывается. Нижняя сторона - то, что, если что-то уничтожает сервер, в то время как такая таблица открыта, следует гарантировать, что таблица хорошо, выполняя сервер с --myisam-recover-options опция, или работая myisamchk прежде, чем перезапустить сервер. (Однако, даже в этом случае, ничего недопустимо потерять при использовании DELAY_KEY_WRITE, потому что ключевая информация может всегда быть сгенерирована от строк данных.)

Использовать INSERT LOW_PRIORITY для поддерживаемых нетранзакционных таблиц, когда Вы хотите дать SELECT операторы более высокий приоритет чем Ваши вставки.

Использовать SELECT HIGH_PRIORITY для поддерживаемых нетранзакционных таблиц, чтобы получить извлечения, которые проходят, минуя очередь. Таким образом, SELECT выполняется, даже если есть другой клиент, ожидающий, чтобы сделать запись.

LOW_PRIORITY и HIGH_PRIORITY имейте эффект только для нетранзакционных механизмов хранения, которые используют только блокировку на уровне таблицы.