9.3.7.2. Задание привилегий

Для задания привилегий предназначены инструкции GRANT и REVOKE. Можно также непосредственно манипулировать таблицами привилегий. Но тогда надо выполнить после внесения изменений инструкцию FLUSH PRIVILEGES, после исполнения которой в буфер системы будет перезагружена таблица привилегий. Пароли для таблицы user создаются с помощью функции password().

Проверить существующие привилегии можно:

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

• с помощью инструкции SHOW GRANTS.

Пользователям должно разрешаться выполнение только тех действий, которые от них и ожидаются.

Большинству пользователей не нужны глобальные привилегии. Эти привилегии предназначены только для администраторов баз данных.

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

Старайтесь использовать пароли, которые невозможно ни угадать, ни подсмотреть. Нельзя хранить пароли в незашифрованном виде.

Очень часто под сервер баз данных выделяют отдельный компьютер. В этом случае можно запретить все подключения к серверу, кроме тех, которые устанавливаются через порт 3306, контролируемый программой MySQL.

9.3.8. Оптимизация

9.3.8.1. Оптимизация запросов

Мир реляционных баз данных – это мир математических операций над множествами, в котором мы постоянно ищем пути ускорения работы наших запросов. К счастью, эти пути существуют. Это – индексирование таблиц, позволяющее ускорить их просмотр.

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

Неиндексированная таблица представляет собой беспорядочный набор строк. При поиске определенной записи необходимо будет проверить все строки (записи) таблицы на истинность проверяемого условия. Для этого потребуется (по крайней мере – теоретически) сканирование (т.е. перебор с просмотром) всей таблицы от начала до конца. Это будет очень медленно и неэффективно.

Для ускорения работы создаются специальные файлы – индексы.

Разные СУБД имеют различные возможности в отношении индексирования. MySQL таблица может иметь до 16 ключей, каждый из которых может иметь до 15 полей. Максимальная поддерживаемая длина ключа 120 байт. Вы можете увеличить длину ключа, изменяя N_MAX_KEY_LENGTH в файле nisam.h и перекомпилировав пакет. Ключи могут иметь имена. В случае первичного ключа имя будет всегда PRIMARY.

Обратите внимание, что длинные ключи могут привести к низкой эффективности.

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

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

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

1. Делается выборка и просмотр содержимого первой строки первой таблицы, удовлетворяющей условию запроса.

2. Непосредственно в индексе второй таблицы ищется строка второй таблицы, удовлетворяющая условию выборки из первой таблицы. Аналогично, непосредственно в индексе третьей таблицы ищется строка в таблице, удовлетворяющая условию выборки из первой таблицы.

3. Переходим к следующей строке в первой таблице и повторяем предыдущую процедуру. И так до полного просмотра всех строк первой таблицы.

Полный просмотр первой таблицы совмещается с прямым просмотром второй и третьей таблиц.

Помимо ускорения поиска записей для выборок (в условии WHERE) индексы могут улучшить производительность и для следующих типов операций:

• Ускоряется поиск максимального и минимального значений индексируемого столбца (функции min() и max()).

• Индексы можно использовать для ускорения сортировки с помощью конструкции ORDER BY.

• Иногда можно избежать чтения из файла данных, если достаточно данных, полученных из индекса.

Недостатки, свойственные использованию индексов:

• индексный файл занимает место на диске,

• индексы ускоряют поиск данных, но замедляют операции добавления, удаления и модификации в индексируемых столбцах,

Правила выбора индексов:

• Необходимо индексировать искомые, а не выбираемые столбцы;

• Желательно использовать уникальные индексы (т.е. не имеющие повторяющихся значений);

• Желательно использовать максимально короткие индексы;

• Не следует злоупотреблять индексированием. Золотое правило – создание только тех индексов, в которых есть непосредственная необходимость. Правило «кашу маслом не испортишь» не подходит для работы с СУБД MySQL;

• Индексы есть смысл использовать при применении операций сравнения (<,<=,=,>=,>) и операций BETWEEN и LIKE. Если же значения столбца используются в других операциях, их индексировать нет смысла;