Помогло бы добавить индекс в столбец BIGINT в MySQL?

У меня есть таблица, в которой будут миллионы записей, и столбец со значениями BIGINT(20) , которые уникальны для каждой строки. Они не являются первичным ключом, но во время определенных операций тысячи SELECT используют этот столбец в WHERE .

Вопрос: добавит ли индекс в этот столбец, когда количество записей возрастет до миллионов? Я знаю, что это будет для текстового значения, но я не знаком с тем, что индекс будет делать для INT или BIGINT .

Пример SELECT который будет происходить тысячи раз, подобен этому:

 `SELECT * FROM table1 WHERE my_big_number=19287319283784 

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

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

Имейте в виду, что добавление индекса в большую таблицу может занять значительное количество времени, поэтому проверьте его перед производственными данными перед тем, как применить его к своей производственной системе. Вероятно, таблица будет заблокирована на время выполнения инструкции ALTER TABLE .

Как всегда, используйте EXPLAIN в своих запросах, чтобы определить их страtagsю исполнения. В вашем случае это будет что-то вроде:

 EXPLAIN SELECT * FROM table1 WHERE my_big_number=19287319283784 

Это улучшит производительность вашего поиска (SELECT) (на основе ваших примерных запросов), но это также сделает ваши вставки / обновления медленнее. Ваш размер БД также будет увеличиваться. Вам нужно посмотреть, как часто вы выполняете эти вызовы SELECT или INSERT. Если вы совершаете много звонков SELECT, это должно улучшить общую производительность.

У меня таблица с 22 миллионами строк на небольшом экземпляре amazon ec2. Таким образом, это не самая быстрая серверная среда. У меня есть это:

 CREATE TABLE huge ( myid int not null AUTO_INCREMENT PRIMARY KEY, version int not null, mykey char(40) not null, myvalue char(40) not null, productid int not null ); CREATE INDEX prod_ver_index ON huge(productid,version); 

Этот вызов заканчивается мгновенно:

 select * from huge where productid=3333 and version=1988210878; 

Что касается inserts , я могу делать 100 / сек в PHP, но если я вставляю 1000 вложений в массив, используйте implode в этой же таблице, я получаю 3400 вставок в секунду. Естественно, ваши данные не поступают именно так. Просто говорю, что сервер относительно быстро. Но, как предлагает тадман, и он хотел сказать, что EXPLAIN не рассматривает, перед типичным заявлением, чтобы увидеть, показывает ли ключевой столбец индекс, который будет использоваться, чтобы вы его запускали.

Общие комментарии

Для медленной отладки запроса поместите слово EXPLAIN перед select слова (независимо от того, насколько сложным может быть select/join ) и запустите его. Хотя запрос не будет выполняться обычным образом при разрешении набора результатов, движок db будет производить (почти сразу) план выполнения, который он попытается выполнить. Этот план может быть отменен, когда выполняется реальный запрос (тот, который перед тем, как поставить EXPLAIN перед ним), но он является основным ключом к недостаткам схемы.

Вывод EXPLAIN кажется загадочным для первого чтения. Недолго. После прочтения нескольких статей об этом, например, « Использование EXPLAIN для написания более простых запросов MySQL» , обычно можно определить, какие разделы запроса используют какие индексы, использовать их и делать медленные таблицы, медленнее, где клаузулы, производные и временные таблицы ,

Используя вывод EXPLAIN по сравнению с вашей схемой, вы можете получить представление о страtagsях создания индекса (таких как composite и covering индексы), чтобы получить значительную производительность запросов.

разделение

Совместное использование этого вывода EXPLAIN вывода схемы с другими (например, в вопросах stackoverflow) ускоряет получение более точных ответов на производительность. Вывод схемы выводится с помощью таких операторов, как show create table myTableName . Спасибо, что поделились.

  • Каков самый быстрый способ высокопроизводительного последовательного ввода-вывода файлов в C ++?
  • Сколько Include я могу использовать в ObjectSet в EntityFramework для сохранения производительности?
  • Каковы плюсы и минусы выполнения вычислений в sql в вашем приложении
  • Самый быстрый способ перебрать все символы в строке
  • Почему мой SSH-вход медленный?
  • Относительная производительность std :: vector vs. std :: list vs. std :: slist?
  • Система и прерывания, вызывающие высокий CPU
  • Есть ли преимущество использования карты над unordered_map в случае тривиальных ключей?
  • В java, эффективнее ли использовать байты или короткие вместо int и float вместо double?
  • Почему std :: vector :: operator от 5 до 10 раз быстрее, чем std :: vector :: at ()?
  • Могу ли я улучшить производительность этого регулярного выражения дальше
  • Давайте будем гением компьютера.