2012-03-16 2 views
5

У меня есть таблица с 17 миллионами строк. Мне нужно захватить 1 столбец этой таблицы и вставить все это в другую таблицу. Вот что я сделал:mysql innodb vs myisam inserts

INSERT IGNORE INTO table1(name) SELECT name FROM main WHERE ID < 500001 

InnoDB выполняет примерно в 3 минуты и 45 секунд

Однако MyISAM выполняется в чуть ниже 4-х секунд. Почему разница?

Я вижу, что все восхваляют InnoDB, но, честно говоря, я не вижу, как это лучше для меня. Это намного медленнее. Я понимаю, что это здорово для целостности и еще много чего, но многие мои таблицы не будут обновляться (просто читать). Должен ли я даже беспокоиться о InnoDB?

+0

Я использую только InnoDB, когда я работаю с реляционными таблицами. В противном случае, если у вас нет внешних ключей, MyISAM - это то, что я предпочитаю! –

+0

просто указать, есть индекс для обеих таблиц. «главная» таблица в настоящее время является myisam. – nick

+0

ben, я бы хотел использовать реляционные таблицы, но я буду иметь дело с возможными сотнями миллионов строк - мне также нужно индексировать десятки столбцов, поэтому я не знаю, в каком направлении идти. целостность не является большой проблемой. не для этой части, по крайней мере. – nick

ответ

12

Разница, скорее всего, обусловлена ​​конфигурацией innoDB, которая требует немного более тонкой настройки, чем myISAM. Идея innoDB заключается в том, чтобы хранить большую часть ваших данных в памяти и выполнять очистку/чтение на диск только тогда, когда у вас есть несколько запасных циклов процессора.

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

, но многие из моих таблиц не будет обновляться

Вы все еще можете получить подъем производительности от InnoDB, если вы делаете 99% чтение. Если вы настроите свой размер пула буферов для хранения всей своей базы данных в памяти, InnoDB НИКОГДА не придется идти на диск, чтобы получать ваши данные, даже если он пропускает кеш запросов mysql. В MyISAM есть хорошая возможность прочитать строку с диска, и вы покидаете операционную систему, чтобы выполнять кеширование и оптимизацию для вас.

InnoDB-буфер бассейн размер

Моя первая догадка проверить innodb_buffer_pool_size каких кораблей из коробки, установленной на 8Й. Рекомендуется, чтобы это составляло около 80% общей памяти. После того, как вы нажмете этот предел, производительность InnoDB будет значительно снижаться, потому что он должен очистить что-то из буфера, чтобы освободить место для новых данных, которые могут быть дорогими

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

Загрузка таблицы обычно случается раз
Подумайте о том, что если вы действительно хотите, чтобы настроить вашу базу данных для размещения «вставки 17million строк». Как часто вы это делаете? В этом случае MyISAM может быть более быстрым, но когда у вас есть 100 одновременных подключений, все чтение и изменение этой таблицы в одно и то же время, вы найдете хорошо настроенный innoDB, который победит, и MyISAM задохнется от блокировок таблиц.

Как MyISAM видит эту операцию
MyISAM будет очень хорошо это без какой-либо настройки, потому что под одеялом, вы просто добавляя каждую строку в файл (и обновление индекса). Ваша ОС и кэширование дисков будут обрабатывать все эти проблемы с производительностью.

Как InnoDB видит эту операцию
Innodb будет знать таблицу нуждается в записи, поэтому он бросает строку в буфер вставки. Вы не даете ему времени до следующей вставки, поэтому у innoDB нет времени на работу с буфером, он заканчивается из комнаты и вынужден «удерживать» вставку, когда он записывает в пул буферов и обновляет индексы. Затем ваш буферный пул заполняется, и innoDB вынужден «задержать» вставку и вывести некоторую страницу из пула буферов на диск. И вы продолжаете бросать в нее вставки, как сумасшедшие. Обратите внимание, что когда вы настроите InnoDB, чтобы дать вам подсказку MySQL> очень быстро после этого, InnoDB все равно будет скремблироваться под обложками, чтобы догнать его в свободное время, но будет готов выполнить новую транзакцию для вас.

ПРОЧИТАТЬ:
http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
http://dev.mysql.com/doc/refman/5.0/en/innodb-tuning.html (см сыпучие Советы по загрузке данных)

+0

Пожалуйста, любые эксперты по эффективности MySQL (особенно из Percona) могут исправить меня, если я поступил не так или оставил что-нибудь. Я обновлю ответ. – FlipMcF

+0

Немного неточно с «достижением предела размера innodb-buffer-pool». Flushing на самом деле связан с ударом «innodb_max_dirty_pages_pct». Наверное, это расщепление волос на этот вопрос. – FlipMcF

+0

Также хорошо читайте для вас: http://www.mysqlperformanceblog.com/2007/05/24/predicting-how-long-data-load-would-take/ – FlipMcF

1

Вы хотите сказать, что прямо ДО некоторой степени. InnoDB работает медленнее, чем MyISAM, но в каких случаях? Все сделано не для удовлетворения требований каждого. INNODB - это механизм транзакционной базы данных, а MyISAM - нет. Поэтому для обеспечения соответствия ACID и механизма хранения данных, связанных с транзакциями, мы должны оплачивать его затраты с точки зрения времени отклика.

Далее InnoDB работает быстрее, если он правильно настроен с использованием файла my.ini или другого конфигурационного файла.

В конце концов, я могу понять следующие причины, почему люди хвалят InnoDB:

  1. Это ACID податливыми и транзакция поддерживается двигатель
  2. Он принимает блокировки на уровне строк, работая на столе в то время как MyISAM замки взять таблицу уровня
  3. InnoDB высоко настраиваемый для многоядерных/мульти-технологических машин для улучшения параллелизм

И последнее, но не наименьшее комментарий от моего боковая сторона; все может удовлетворить потребности «каждого», поэтому он зависит только от того, в каком сценарии вы сравниваете оба двигателя.

Смежные вопросы