Что касается индексации, правильно ли индексировать все поля, которые будут искать (в рамках WHERE), чтобы ускорить выбор? Например, моя база данных содержит таблицу профилей, в которой хранятся данные пользователя, такие как имя, intrestCode, zip, description и email. Запись профиля идентифицируется столбцом PRIMARY id, который однозначно соответствует идентификатору пользователя. Я сделал индекс zip и intrestCode, так как профили будут искать по zip и, возможно, intrestCode (SELECT `blah`,`blah`... FROM profile WHERE zip=?
, SELECT `blah`,`blah`... FROM profile WHERE zip=? && intrestCode=?
). Правильно ли я это делаю?Правильное индексирование MySQL
ответ
Звуки в основном правильные. Вы должны знать, что вы не можете использовать два различных индексов на одной и той же таблицы в том же запросе, так что если вы запускали
CREATE INDEX `zip` ON `profile` (`zip`);
CREATE INDEX `intrestCode` ON `profile` (`intrestCode`);
то запрос
SELECT `blah`,`blah`... FROM profile WHERE zip=? && intrestCode=?
может смотреть только на одну таблицу из индекс. Секрет состоит в том, что вы можете создать один индекс на двух столах, например, так:
CREATE INDEX `zip+intrestCode` ON `profile` (`zip`, `intrestCode`);
MySQL может использовать это для запросов, которые используют либо zip
один в ИНЕКЕ, или использовать как zip
и intrestCode
, но не для запросов, которые используют только intrestCode
в предложении WHERE.
(Это происходит потому, что каждый индекс охватывает всю таблицу. Если MySQL был попробовать и посмотреть zip
и intrestCode
из разных таблиц, то это было бы извлечения много нерелевантных строк из второго индекса. Поэтому он смотрит только на один индекс. Если вы хотите, чтобы он использовал индекс в обоих столбцах, вам нужно иметь один индекс, который включает оба столбца.)
Я считаю, что в принципе да. Вы должны следить за своей базой данных, чтобы столкнуться с дополнительными проблемами и оптимизировать свои запросы и таблицы на основе результатов.
Данные о привязке к отношениям индексирования - это немного искусства. Лучший подход - посмотреть на все различные запросы, которые вы будете делать, и поместить индексы в соответствующие столбцы. Используйте EXPLAIN
, чтобы узнать, какие индексы будут использоваться в запросе.
Однако помните, что MySQL может использовать только один индекс из таблицы за раз. Вот почему вы можете сразу поместить индекс в несколько столбцов. И MySQL может использовать индекс с несколькими столбцами, если ему нужны только столбцы в начале индекса. В вашем примере я бы поставил многоколоночный индекс zip
и intrestCode
вместе, потому что это поможет обоим запросам. Таким образом, вам не нужен отдельный индекс только zip
.
Итак, как бы ускорить SELECT 'email',' name' FROM 'profiles' WHERE' zip' =? && 'intrestCode' =? , Как видите, он использует 2 столбца. Я бы не использовал 2 отдельных индекса? – user974896
Вы используете индекс с несколькими столбцами: 'ALTER TABLE profile ADD INDEX (zip, intrestCode)' – staticsan
Как правило, вы хотите добавить индексы в столбцы, в которые вы присоединяетесь или находитесь в своем предложении where , Помните, что индекс в двух столбцах отличается от одного индекса для каждого из двух столбцов. Также, если у вас есть указатель на несколько столбцов, порядок имеет значение.
Скажем, у вас есть два столбца A и B и имеют индекс из двух столбцов в порядке A, а затем B.Есть три случая:
- Где положение против столбца A: используется индекс
- Где положение против столбца B: индекс не используется
- Где положение против столбцов A и B: используется индекс
Как и staticsan, индексирование - это искусство, и нет правил, применяющих 100% времени. Используйте план объяснения, чтобы увидеть, как выполняется ваш запрос, и сделать соответствующие изменения.
- 1. Правильное индексирование запроса на присоединение
- 2. Правильное индексирование с postgres db
- 3. MySQL - удаление или индексирование?
- 4. Оптимизация и индексирование MySQL
- 5. Индексирование колонки MySql TEXT?
- 6. Индексирование столбцов в mysql
- 7. MYSQL многоколоночное индексирование
- 8. Индексирование таблицы MySQL
- 9. Индексирование datetime в MySQL
- 10. MySQL - Индексирование строк
- 11. Индексирование этого запроса mysql
- 12. MySQL - индексирование для сравнения строк
- 13. Индексирование Mysql Group BY Query
- 14. MySQL - индексирование внешних символов innodb
- 15. Индексирование MySQL - необязательные критерии поиска
- 16. MySQL индексирование char (1) столбцов
- 17. Индексирование MySQL и использование filesort
- 18. MySQL: полнотекстовое индексирование предыдущих записей?
- 19. MySQL MyISAM индексирование текстового столбца
- 20. Индексирование зависимых подзапросов в MySQL
- 21. Mysql индексирование и присоединяется к
- 22. Mysql индексирование ситуация с DISTINCT
- 23. MySQL Индексирование: инвертированное или переадресованное
- 24. Индексирование разделов таблицы в MySql
- 25. Индексирование таблицы mysql для выбора
- 26. индексирование MySQL в Apache Solr
- 27. MySql, индексирование и ускорение запроса
- 28. MYSQL IFNULL правильное использование
- 29. ? Правильное произношение MySQL?
- 30. правильное использование MySQL Query
Проблема в том, что я не знаю, как пользователи хотят искать. Некоторые из них могут искать только по почтовому индексу, некоторые из них могут искать только по интересам, а некоторые могут захотеть выполнить поиск по обоим. Это похоже на обычное явление. Нет решения (за исключением многих таблиц)? Будет ли строиться многоцветный индекс и подстановочные знаки неиспользуемых полей? Только для Zip: SELECT * FROM профилей, где zip =? && intrestCode LIKE '%'. Только для кода Intrest: SELECT * из профилей WHERE zip LIKE '%' && intrestCode =?. Для обоих: SELECT * из профилей WHERE zip =? && intrestCode = ?. – user974896
Нет. Между полями должна быть строгая связь. Если у вас есть два поля, вы можете легко создать два индекса: один на 'zip' и' intrestCode' и один на 'intrestCode'. Если у вас больше полей, становится сложнее учитывать все комбинации. В этот момент, вероятно, лучше всего создать один индекс для каждого поля и позволить оптимизатору выбрать лучший (событие, хотя вы не можете получить такой же коэффициент эффективности). Возможно, не стоит создавать многоколонные индексы вообще в зависимости от размера БД. Здесь необходимы некоторые судебные решения. –
Еще один вопрос, добавив несколько индексов для покрытия многих комбинаций, фактически замедляющих работу (приходите UPDATE, INSERT или даже SELECT время?), Или это просто дорого в плане дискового пространства. Из-за низкой стоимости дисковое пространство является почти бесконечным ресурсом. – user974896