[решено] Чем KEY отдличается от INDEX? - Компьютерный форум OSzone.net

Влад, существует MySQL, версии которого несколько отличаются друг от друга и все - от стандарта SQL
Поэтому, наверное, можно эксперементировать, а можно посмотреть, что предлагает реляционная модель данных и что из этого имеется в MySQL
индекс (index) в реляционных базах данных вообще - *своего рода предметный указатель по атрибутам (полям), дающие ссылки на строки (записи), в которых встречается то, или иное значение. Таким образом, индекс обеспечивает увеличение скорости доступа - выборок.
Лучше поцитируем что-нибудь умное :) (Справочное руководство по языку SQL ( Версия 6.0 Part Number 778-V6.0 * * * * Ноябрь 1988 (Пересмотрено - Февраль 1990):

Цитата:

Справочное руководство по языку SQL * * * *1-8
* * * * Индексы * * * * * * * * * * * * * * * * * * *
* * * * В системах управления реляционными базами данных ORACLE *индексы используются с двумя целями:
* * * * * * ** индексы обеспечивают быстрый доступ к строкам таблицы
* * * * * * ** индексы обеспечивают уникальность строк внутри таблицы.

* * * * Обеспечение быстрого доступа * * * * * * * * *
* * * * Индексы обеспечивают *более быстрый доступ к данным для операций, возвращающих небольшие части строк таблицы. Например, * индекс на столбце EMPNO таблицы EMP дает возможность системе ORACLE непосредственно обратиться к служащему с номером 7544 вместо сканирования *всей таблицы для поиска данного сотрудника.
* * * * ORACLE не ограничивает количество *индексов, *которые *можно создавать на одной таблице; *однако для определения индексируемых столбцов надо использовать одно практическое правило.
* * * * Практическое правило: *SQL - операторы, *запрашивающие менее 10-15% *строк *таблицы *выполняются быстрее с использованием индекса. Обсуждение преимуществ использования индексов можно найти *в *разделе *"Настройка SQL - операторов и приложений" Главы 2 документа "ORACLE RDBMS *Performance *Tuning *Guide" * * (Руководство *по настройке производительности ORACLE RDBMS).
Общая дискуссия об индексах ведется в Главе 5 "Пользователь *ские *объекты *базы данных" документа "ORACLE RDBMS *database Administrator's Guide" (ORACLE RDBMS Руководство администратора базы данных).

* * * * Обеспечение уникальности * * * * * * * * * * *
* * * * Уникальность индексов *обеспечивает *требование * отсутствия дублирующихся строк *в *таблице. *В *общем случае необходимо строить уникальный индекс на основном ключе *каждой таблицы.
* * * * В редких *случаях правда необходимо хранить в таблице дублирующиеся строки и для их обеспечения ORACLE не требует *обязательного создания уникального индекса.

*Уфф! умная цитата окончена. Что касается MySQL - то имеющаяся по этому поводу документация так и говорит:

Цитата:

Индексы применяются для быстрого поиска строк с указанным значением одного столбца. Без индекса чтение таблицы осуществляется по всей таблице начиная с первой записи, пока не будут найдены соответствующие строки. Чем больше таблица, тем больше накладные расходы. Если же таблица содержит индекс по рассматриваемым столбцам, то MySQL может быстро определить позицию для поиска в середине файла данных без просмотра всех данных. Для таблицы, содержащей 1000 строк, это будет как минимум в 100 раз быстрее по сравнению с последовательным перебором всех записей. Однако в случае, когда необходим доступ почти ко всем 1000 строкам, быстрее будет последовательное чтение, так как при этом не требуется операций поиска по диску.

Причем, по докам в MySQl различается аж 3 типа индексов: PRIMARY, UNIQUE, и INDEX и хранятся они (опять же по докам) в виде B-деревьев. Проблемы, естественно (и не только в MySQL) возникают при работе с текстом.
Еще один момент - и не только в MySQL: СУБД "выбирают", использовать ли индекс, или обойтись без него. Хорошо, если правильно :(

Теперь ключ (Key) - в релизах MySQl имеет несколько невыраженный характер (в отличие от тестовых новых версий), о чем, помнится, писалось в руководстве по MySQL. (поэтому primary key там отличается от index только свойством primary и, *требованием к уникальности данных)
В общем же случае в реляционных базах данных ключи работают для сохранения целостности данных (я упоминала о внешнем ключе - в MySQL он появился, насколько я понимаю только в последних версиях и не для всех типов таблиц, а в стандарте SQL это понятие имеется) Существуют по крайней мере 3 типа ключей (может что еще кто знает - поправте):
- candidate (по-моему, в MySQL нет, или есть, но в последних версиях) Уникальные поля (одно, или комбинация из нескольких), однозначно идентифицирующие запись.
- primary (имеется в MySQL) отличается от candidate единственностью.
- foreign (только в последних версиях MySQL) - набор атрибутов (полей), *присутствующих в нескольких таблицах и являющимся первичным ключеи для одной из них. Обеспечивают связь данных нескольких таблиц и целостность данных (не висят мертвые души в одних таблицах при удалении данных из других таблиц.

Ну, и по поводу оптимизации: ANALYZE TABLE, OPTIMIZE TABLE применять, несомненно стоит, хотя бы потому, что при изменении таблиц (удалении, добавлении записей) надо оптимизировать (дефрагментировать) файловое *пространство и перестроить индексы и ключи. (в старые добрые времена при сбоях в машине, аварийном выключении питания и т.д. надо было переиндексировать таблицы - тогда они назывались базами данных, - замечательной тогда СУБД FoxPRO, а то индексы ломались в хлам) При этом - NB - MySQL - не единственная СУБД, в Oracle, Postgresql данные хранятся просто совсем не так (хотя мы и видим все те же таблицы) Уфф Все надоело писать, пусть желающие правят-дописывают :)