#mysql #performance
#mysql #Производительность
Вопрос:
Я пытаюсь добиться максимальной производительности от приложения, которое обновляет индексированные строки, многократно заменяя данные в поле varchar. Это поле varchar будет обновляться данными одинакового размера при последующих обновлениях (поэтому одна строка никогда не увеличивается). К моему полному замешательству, я обнаружил, что производительность напрямую связана с размером самого поля и далека от производительности прямой замены данных в файле файловой системы. т.е. размер поля 1k на порядок быстрее, чем размер поля 50k. (в пределах ограничения размера строки) Если строка существует в базе данных, а размер не меняется, почему обновление влечет за собой такие большие накладные расходы?
я использую innodb и отключил двоичное ведение журнала. я исключил накладные расходы на связь, используя строки, сгенерированные sql. пробовал использовать myisam, и это было примерно в 2-3 раза быстрее, но все равно слишком медленно. я понимаю, что база данных имеет накладные расходы, но опять же я просто заменяю данные в одном поле данными равного размера. что делает БД, кроме прямой замены битов?
приблизительная производительность # 81 обновление / сек (строка 60 кб) 1111 обновлений / сек (строка 1 кб)
производительность файловой системы: 1428 обновлений / сек (строка 60 кб)
обновления, которые я делаю, — это вставка … при обновлении дубликата ключа. прямые обновления выполняются примерно на 50% быстрее, но все еще смехотворно медленно для того, что он делает.
Могут ли какие-либо эксперты просветить меня? Есть ли способ улучшить эти цифры?
Комментарии:
1. Индексы на 50 КБ varchar? Вы, вероятно, обнаружите, что хеширование индекса — это то, что отнимает дополнительное время.
2. просто чтобы уточнить, что поле, которое я обновляю, НЕ является частью индекса / ключа. ключ, который я использую для строки, — это просто int
3. Рональдо Я не могу использовать тип данных char, потому что длина поля должна быть больше 255. тем не менее, я использовал ROW_FORMAT=FIXED при объявлении таблицы.
Ответ №1:
Я обратился к вопросу в StackExchange администратора базы данных относительно использования CHAR против VARCHAR. Пожалуйста, прочитайте все ответы, а не только мои.
Имейте в виду и кое-что еще. InnoDB имеет gen_clust_index, внутренний кластеризованный индекс идентификатора строки для всех таблиц InnoDB, по одному на таблицу InnoDB. Если вы измените что-либо в первичном ключе, это даст gen_clust_index настоящую тренировку по повторной настройке.