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

Question

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

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

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

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

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

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

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

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

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

Мой компьютер - XP, работает под управлением WAMPSERVER, Win32 NTFS, Intel Duo Core, T9300 @ 2,50 ГГц, 1,17 ГГц, 1,98 ГБ или 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 

Answer 1

Некоторые ответы:

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

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

• Я бы не рекомендовал использовать TEXT тип данных для каждые столбец.Нет причин, по которым вам нужно TEXT для большинства этих столбцов.

• Не создавайте индекс для каждого столбца, особенно если вы настаиваете на использовании TEXT типов данных.Вы даже не можете индексировать столбец TEXT, если не определите индекс prefix .В общем, выбирайте индексы для поддержки конкретных запросов.

Вероятно, у вас есть много других вопросов, основанных на вышеизложенном, но в одном посте StackOverflow слишком много вопросов для обсуждения.Возможно, вы захотите пройти обучение или почитать книгу, если собираетесь работать с базами данных.
Я рекомендую Высокопроизводительный MySQL, 2-е издание .

---

Повторное наблюдениевопросы:

Для настройки MySQL вот хорошее начало: http://www.mysqlperformanceblog.com/2006/09/29/what-to-tune-in-mysql-server-after-installation/

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

Тип данных TEXT может хранить до 64 КБ, что избыточно для номера телефона или штата.Я бы использовал CHAR (10) для типичного номера телефона в США.Я бы использовал CHAR (2) для штата США.В общем, используйте самый компактный и экономичный тип данных, который поддерживает диапазон данных, который вам нужен в данном столбце.

Answer 2

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

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

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

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

Answer 3

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

Оптимизация структуры базы данных!

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

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

Изменение полей State и Country на enum приведет к значительному уменьшению размера индексов.