Я вот не могу совсем полностю понять какие типы индексов нужны в каких случаях. как rule of thumb - я понял что индексы выгодны только если будет частный поиски по значениям т.к. они замедляют запись в таблицу, но убыстряют поиски т.е. лучший пример - это добавления нового пользоваеля (он реже регистрируется, чем заходит на сайт) Вот правильно ли я понимаю что юзер должен 'user_name' => array( //Уникальное нужно для создания индекса 'type' => 'VARCHAR', 'constraint' => '100', 'unique' => TRUE, уникальным и после чего создать индекс "ALTER TABLE `site_users` DROP INDEX `user_name`, ADD UNIQUE INDEX `user_name` (`user_name`); Для чего нужны тогда - FULLTEXT SPATIAL Ну т.е. например для поиска по статье? И еще я не могу понять зачем нужен KEY (не primary key - это понятно основное поле для индификации записи).
Ну что сказать.. изучай мануалы MySQL. Ключи могут быть не только праймари, но и внешние, чтобы связывать данные в таблицах между собой. Заранее бомбить индексы не стоит. Для сборки модели БД можно юзать визуальные среды типа MySQL WorkBench, он сам позаботится о большей части индексов очевидных. А не очевидные надо втыкать только когда начнут появляться записи в логе медленных запросов. Вот тут, по ссылке, можно подчерпнуть много полезной инфы.
один вопрос, Есть таблица статей, где есть id статьи далее есть таблица пользователей, где есть id пользователя, я создаю таблицу, которая будет содержать сохранение в избранное статьи, таблица должна содержать примари кеу или нет?
я до сих пор как то плаваю в вопросе индексов.. поэтому стараюсь делать несколько простых запросов вместо одного сложного)
Это все к вопросу об автоматизации , у меня в таблице будет несколько тысяч записей и поэтому задаюсь вопросом изначально я всегда предпочитаю один большой запрос , чем несколько маленьких
с несколько тысячами записей в базе можно даже особо не заморачиваться над вопросом ускорения) все равно быстро найдет) даже если сильно накосячить)
в 99 случаях структуры баз простейшие.. что там проектировать то.. а для одного процента - есть супер мега специалисты по БД...
третья? Обеспечивающая многие-ко-многим связь? В 95% случаев праймари кей там не нужен. А индекс можно строить мультиколоночный, по паре пользователь-статья. --- Добавлено --- На самом деле нет. Это твоя личная выборка такая на твое счастье
на выборке 100 записей могут начинаться проблемы в сложных запросах. Количество записей в выборке как и количество записей не единственный критерий для скорости выполнения.
Вопрос который любили задавать в последней команде кандидатам: сколько индексов на запрос может задействовать MySql? ну и далее... какой выход? А почему может понадобится 2 индекса? Какие кейсы? А есть СУБД которые могут? Грубо говоря, получается так, что верный ответ на каждый вопрос (в сочетании с опытом применения и возможности разъяснения) это +10-20к размеру чека разработчика Это к вопросу важности темы.
Вообще, как по мне, сначала проектируем БД и систему, потом курим эксплейны на запросах, где они неочевидны, потом тестим, прицепив тот же Mysqltuner или его аналоги, потом делаем выводы. А еще подумай, что этот индекс, по-хорошему, должен быть UNIQUE. Чтобы не удивляться, что у тебя связи плодятся дублирующиеся. Но, опять же, зависит от того, что ты делать собираешься. А еще почитай про денормализацию данных. Удивишься, но некоторые вещи проще и правильнее хранить не в таблице многие-ко-многим, или M:N, а, к примеру, в виде того же JSON. И не в отдельной таблице, а как часть одной из родительских. Исходя из способа обращения с данными. Частоты использования. А еще подумай о кешировании. Что-то, конечно сам MySQL кеширует, отдавая тебе готовые выборки, вместо проведения реальных, но, если ты берешь какие-то крайне редко изменяемые данные каким-то сложнячим запросом то, мб стоит сохранить результат этого запроса куда-нибудь себе? Да хоть в сессию. Ну, конечно, если это согласуется со здравым смыслом. Крч, я к чему веду - серебряной пули нет. Нельзя добиться успеха по инструкции. Нельзя построить годную систему по мануалам. В 95% случаев эти мануалы и гайды - последствия "синдрома выжившего" или "ошибки выжившего". Когнитивного искажения. Изучай документацию к тому, с чем работаешь, делай выводы. Ссылку по индексам и паттернам/антипаттернам выше я уже дал.