Изучаем sql
Обратная сторона индексации
жүктеу/скачать 1,6 Mb. Pdf көрінісі
|
Изучаем SQL ( PDFDrive )
| Обратная сторона индексации
Если индексы – это так замечательно, почему бы не индексировать все подряд? Чтобы понять, почему большее количество индексов не всегда хорошо, надо помнить, что каждый индекс – это таблица (особого ти па, но все равно таблица). Поэтому при каждом добавлении или удале нии строки из таблицы все ее индексы должны быть модифицирова ны. При обновлении строки все задействованные индексы столбца или столбцов тоже должны изменяться. Следовательно, чем больше индек сов, тем больше работы приходится выполнять серверу для обновле ния всех объектов схемы. А это очень замедляет процесс. Индексам требуется некоторое количество памяти, а также некоторое внимание администраторов, поэтому наилучшая стратегия – добавлять Ограничения 251 индекс только при возникновении вполне определенной необходимо сти. Если индекс нужен только для конкретной цели, например для выполнения программы по ежемесячному обслуживанию, всегда мож но добавить индекс, выполнить программу и удалить индекс до того момента, пока он не понадобится вновь. Для хранилищ данных, где индексы очень нужны в рабочие часы (поскольку пользователи состав ляют отчеты и выполняют случайные запросы), но становятся пробле мой при загрузке данных в хранилище в ночное время, общепринятой практикой является уничтожение индексов перед загрузкой данных и их повторное создание перед открытием хранилищ для работы. Ограничения Ограничение – это просто некоторое ограничивающее условие, нала гаемое на один или более столбцов таблицы. Есть несколько разных типов ограничений, включая: Ограничения первичного ключа (Primarykey constraints) Идентифицируют столбец или столбцы, гарантирующие уникаль ность в рамках таблицы. Ограничения внешнего ключа (Foreignkey constraints) На один или более столбцов накладывается такое ограничение: они могут содержать только значения, содержащиеся в столбцах первич ного ключа другой таблицы. Также могут ограничиваться допусти мые значения других таблиц, если установлены правила update cas cade (каскадное обновление) или delete cascade (каскадное удаление). Ограничения уникальности (Unique constraints) На один или более столбцов накладывается ограничение: они могут содержать только уникальные в рамках таблицы значения. Проверочные ограничения целостности (Check constraints) Ограничивают допустимые значения столбца. Без ограничений под сомнением может оказаться непротиворечивость базы данных. Например, если сервер допускает изменение ID клиента в таблице customer без изменения этого же ID клиента в таблице ac count , все может закончиться тем, что счета больше не будут указывать на соответствующие записи клиентов (это явление известно как «оси ротевшие» строки (orphaned rows)). Но если заданы ограничения пер вичного и внешнего ключей, сервер или сформирует ошибку в случае попытки изменения или удаления данных, на которые ссылаются дру гие таблицы, или распространит изменения на другие таблицы (более подробно об этом чуть позже). Если при работе с сервером MySQL требуются ограничения внеш него ключа, в таблицах должен использоваться механизм хра нения InnoDB. |