Производительность MySQL - 1 миллион записей - выберите Int перед текстовым полем

Question

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

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

2. Выполните запрос SQL SELECT для соответствия INT, где INT - это идентификатор пользователя, а затем соответствует текстовому полю.

Вариант 1 обеспечит очевидное увеличение производительности. Но может ли вариант номер 2 получить выигрыш? В заявлении, если мы сначала сопоставим INT, это приведет к сокращению результата до только совпадающих записей, а затем выполнит поиск в текстовом поле. Например ..

$user_id = 1001; 
$domain_name = "mydomain.com"; 
$query = $database->prepare("SELECT * FROM domains_table WHERE user_id = $user_id && domain_name = $domain_name"); 

Где переключая положение user_id и domain_name в приведенном выше запросе уничтожит производительность. Является ли совпадение с user_id первым преимуществом здесь?

Answer 1

Если есть индекс по user_id оптимизатор запросов будет выяснить, что является правильным для того, чтобы соответствовать их.

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

Короткий рассказ: Вариант 1 не обеспечит прирост производительности. Переупорядочение условий в запросе не обеспечит прирост производительности - оптимизатор запросов уже вычисляет его без вашей помощи. Единственное, что улучшит производительность, - это индекс для user_id.

EDIT: Требуется добавить что-то о составных индексах. В некоторых ответах предлагаемый составной индекс (user_id, domain) может работать лучше для вас. Это действительно ускорит запросы, в которых вы сопоставляетесь как с user_id, так и с доменом. Однако индексы не являются бесплатными - каждый замедляет время вставки и добавление нового индекса может замедлить другие, потому что все индексы больше не могут храниться в памяти. Поэтому, если вы знаете, что всегда будете запрашивать пользователя user_id, вы должны пойти дальше и использовать составной индекс. Однако, если только некоторые из ваших запросов будут user_id, домен, в то время как другие будут user_id и othercol, user_id и othercol2 ... Тогда ваш может быть лучше с индексом только для user_id.

Answer 2

Стол из миллиона строк не очень большой. Шутки в сторону.

Если вы создаете составной индекс в полях user и domain, запрос, который вы указали в своем вопросе, будет достаточно эффективным без каких-либо изменений для использования целых идентификаторов.

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

Время, затрачиваемое на чтение информации о том, как работает планирование индексирования и выполнения запросов в MySQL, будет потрачено достаточно времени.

Ваш первый вариант (отдельные таблицы для отдельных пользователей) - это гораздо худшая идея, чем правильная индексация одной таблицы.Это по многим причинам, но среди них главное - это просто не будет грациозно масштабироваться, если и когда вы начнете иметь тысячи пользователей.

Answer 3

Вы продолжаете говорить, что вещи «очевидны». Вы оценили их, чтобы сравнить, или вы делаете предположения?

Используя индекс, поиск строки может быть очень быстрым. И, конечно, гораздо быстрее, чем поиск целого числа, если у вас нет есть индекс.

Как только вы используете индекс, разница между целым поиском и строковым поиском практически незаметна.

Лучший показатель будет составной индекс на оба колонке:

ALTER TABLE domains_table ADD INDEX (user_id, domain_name); 

Think из телефонной книги. Книга сортируется по фамилии, затем по имени. Если вы ищете «Смит, Джон», вы легко сходите на поиск ко всем Смитам, а затем внутри этого подмножества имена сортируются по первому имени, поэтому вы можете легко искать всех тех, кто назван Джоном. Вот как работает составной индекс.

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

В других комментариях вы узнали, что оптимизатор может изменить порядок условий в предложении WHERE для соответствия порядку столбцов в индексе. Это правда. Это задача оптимизатора запросов, и все продукты RDBMS, которые вы, скорее всего, будете использовать (включая MySQL), достаточно умен, чтобы это сделать.

Возможно, вы хотели бы прочитать мою презентацию How to Design Indexes, Really. Или видео со мной, представляя этот разговор: https://www.youtube.com/watch?v=ELR7-RdU9XU

Существует также отличный сайт со множеством подсказок по индексированию: Use the Index, Luke.