MySql-WAMP-огромная таблица очень медленная (20 миллионов строк)

Так я написал этой! вчера и получил идеальный ответ, который требовал сначала запустить этот код: ALTER TABLE MYTABLE AUTO_INCREMENT=10000001;

Я запустил его несколько раз, но перезапустил WAMP через пару часов он не работает. После запуска в течение ночи (12 часов) код все еще не был запущен.

Мне интересно, если мой размер таблицы базы данных за пределами mysql или моего компьютера или обоих.

, Я подозреваю это правильное индексирование или какой-то другой фактор может сильно повлиять на мою производительность. Я знаю, что 20 миллионов-это много строк, но это слишком много?

Я мало знаю об индексах, кроме того, что они важны. Я попытался добавить их в поля name и state, что, по-моему, мне удалось.

между прочим, я пытаюсь добавить уникальное поле идентификатора, о котором вчера был мой пост.

таким образом, вопрос: 20 миллионов строк вне объем MySql? Если нет, мне не хватает индекса или какой-то другой настройки, которая помогла бы лучше работать с этими 20 миллионами строк? Могу ли я поместить индексы на все столбцы и сделать это супер быстро?

Как всегда, спасибо заранее...

вот спецификации:

Мой компьютер XP, работает под управлением WAMPSERVER, Win32 NTFS, Intel Duo Core, T9300 @ 2.50 GHz, 1.17 GHz, 1.98 GB или RAM

БД: 1 Таблица, 20 миллионов строк Размер таблиц: Данные 4.4 Гига, Индексы 1.3 Гига, Общая 5.8 Гигов

индексы настраиваются в полях "бизнес-имя" и "состояние"

поля таблицы выглядят следующим образом:

`BUSINESS NAME` TEXT NOT NULL, 
`ADDRESS` TEXT NOT NULL, 
`CITY` TEXT NOT NULL, 
`STATE` TEXT NOT NULL, 
`ZIP CODE` TEXT NOT NULL, 
`COUNTY` TEXT NOT NULL, 
`WEB ADDRESS` TEXT NOT NULL, 
`PHONE NUMBER` TEXT NOT NULL, 
`FAX NUMBER` TEXT NOT NULL, 
`CONTACT NAME` TEXT NOT NULL, 
`TITLE` TEXT NOT NULL, 
`GENDER` TEXT NOT NULL, 
`EMPLOYEE` TEXT NOT NULL, 
`SALES` TEXT NOT NULL, 
`MAJOR DIVISION DESCRIPTION` TEXT NOT NULL, 
`SIC 2 CODE DESCRIPTION` TEXT NOT NULL, 
`SIC 4 CODE` TEXT NOT NULL, 
`SIC 4 CODE DESCRIPTION` TEXT NOT NULL 

3 ответов


ответы:

  • 20 миллионов строк вполне в пределах возможностей MySQL. Я работаю над базой данных, которая имеет более 500 миллионов строк в одной из своих таблиц. Реструктуризация таблицы может занять несколько часов, но обычные запросы не являются проблемой, если им помогает индекс.

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

  • Я бы не рекомендовал использовать TEXT тип данных для


Это займет много времени, потому что у вас есть только 2GB RAM и 6GB данных/индексов, и это заставит тонну обмена между ОЗУ и диском. Но с этим ничего не поделаешь.

вы можете попробовать запустить это в пакетах.

создайте отдельную пустую таблицу с включенным в нее столбцом auto_increment. Затем вставьте свои записи в определенное количество за раз (скажем, 1 состояние за раз). Это может помочь ему идти быстрее, так как вы должны быть в состоянии для обработки этих меньших наборов данных полностью в памяти вместо подкачки на диск.

вы, вероятно, получите гораздо лучшие ответы на это, если он включен dba.stackexchange.com и еще.


Я считаю, что оборудование в порядке, но вам нужно сэкономить свои ресурсы намного лучше.

оптимизация структуры БД!

  • не используйте TEXT!
  • для номеров телефонов используйте bigint unsigned. Любые знаки или альфа должны быть проанализированы и преобразованы.
  • для любого другого Альфа-числового столбца используйте, например,varchar([32-256]).
  • zip-код-это конечно mediumint unsigned.
  • пол должен быть enum('Male','Female')
  • продажи может быть int unsigned
  • государство должно быть enum('Alaska',...)
  • страна должна быть enum('Albania',...)

при построении большого индекса самый быстрый способ-создать новую таблицу и сделать INSERT INTO ... SELECT FROM ... а то ALTER TABLE ....

изменение полей состояния и страны на перечисление резко уменьшит размер индексов.