У мене є таблиця MySQL InnoDB з 1 000 000 записів. Це занадто багато? Або бази даних можуть впоратися з цим та іншим? Я запитую, тому що я помітив, що деякі запити (наприклад, отримання останнього рядка з таблиці) повільніші (секунди) в таблиці з 1 мільйоном рядків, ніж у одному із 100.
Відповіді:
У мене є таблиця MySQL InnoDB зі 1000000 регістрами. Це занадто багато?
Ні, 1000000 рядків (записи AKA) - це не надто багато для бази даних.
Я запитую, тому що я помітив, що деякі запити (наприклад, отримання останнього реєстру таблиці) повільніші (секунди) в таблиці з 1 мільйоном регістрів, ніж в одному із 100.
У цій заяві є багато що врахувати. Звичайними підозрюваними є:
У мене є база даних із понад 97 000 000 записів ( файл даних 30 Гб ), і я не маю проблем.
Тільки не забудьте визначити та покращити індекс таблиці .
Тож очевидно, що 1000000 - це НЕ БАГАТО! (Але якщо ви не індексуєте; так, це БАГАТО)
Використовуйте "пояснити", щоб вивчити ваш запит і перевірити, чи не є щось не так із планом запиту.
EXPLAIN- новачкам чи ні.
EXPLAIN ;)
Я думаю, це поширена помилка - розмір - це лише одна частина рівняння, коли мова йде про масштабованість бази даних. Є й інші складні (або складніші) проблеми:
Наскільки великий робочий набір (тобто скільки даних потрібно завантажити в пам’ять і активно працювати над ними). Якщо ви просто вставляєте дані, а потім нічого з ними не робите, це насправді легко вирішити.
Який рівень паралельності потрібен? Чи є лише один користувач, який вставляє / читає, або у нас багато тисяч клієнтів, що працюють одночасно?
Які рівні обіцяності / довговічності та послідовності виконання необхідні? Чи мусимо ми переконатись, що зможемо виконати кожну комісію. Це нормально, якщо середня транзакція є швидкою, або ми хочемо переконатися, що всі транзакції надійно швидкі (контроль якості шести сигм, наприклад - http://www.mysqlperformanceblog.com/2010/06/07/performance-optimization- і-шість сигм / ).
Вам потрібно робити якісь операційні проблеми, наприклад, ЗМІНИТИ схему таблиці? У InnoDB це можливо, але неймовірно повільно, оскільки часто доводиться створювати тимчасову таблицю на передньому плані (блокуючи всі з'єднання).
Отже, я збираюся зазначити дві обмежувальні проблеми:
Якщо ви маєте на увазі 1 мільйон рядків, це залежить від способу індексації та конфігурації обладнання. Мільйон рядків - це не велика кількість для корпоративної бази даних або навіть для бази даних розробників про гідне обладнання.
якщо ви маєте на увазі 1 мільйон стовпців (не впевнений, що це навіть можливо в MySQL), тоді так, це здається трохи великим і, ймовірно, спричинить проблеми.
Зареєструватися? Ви маєте на увазі запис?
Мільйон записів сьогодні не є великою проблемою для бази даних. Якщо ви зіткнетеся з якоюсь проблемою, швидше за все, це не сама система баз даних, а саме обладнання, на якому ви її використовуєте. Ви, швидше за все, не зіткнетеся з проблемою з БД до того, як у вас закінчиться обладнання.
Зараз, очевидно, деякі запити повільніші за інші, але якщо два дуже подібні запити виконуються в дуже різний час, вам потрібно з’ясувати, яким є план виконання бази даних, та оптимізувати для нього, тобто використовувати правильні індекси, належну нормалізацію тощо.
До речі, у таблиці немає такого поняття, як "останній" запис, з логічної точки зору їм не властивий порядок.
SELECT LAST_INSERT_ID()замість цього запиту.
Я бачив нерозділені таблиці з декількома мільярдами (індексованими) записами, які самостійно приєдналися для аналітичної роботи. Зрештою ми розділили цю річ, але чесно кажучи, ми не побачили такої великої різниці.
Тим не менш, це було в Oracle, і я не тестував цей обсяг даних у MySQL. Індекси - твій друг :)
Якщо припустити, що ви маєте на увазі "записи" під "реєстри" ні, це не надто багато, MySQL дуже добре масштабується і може вмістити стільки записів, скільки у вас є місця на жорсткому диску.
Очевидно, що пошукові запити будуть повільнішими. Насправді цього неможливо обійти, окрім як переконатися, що поля правильно проіндексовані.
Чим більша таблиця (як у більшій кількості рядків у ній), тим повільніше виконуються запити, якщо немає індексів. Як тільки ви додасте правильні індекси, ефективність вашого запиту повинна покращитися або принаймні не погіршуватися настільки, наскільки зростає таблиця. Однак якщо сам запит повертає більше рядків із збільшенням таблиці, ви знову почнете бачити погіршення.
Хоча 1 млн рядків не так багато, це також залежить від того, скільки пам'яті у вас на сервері БД. Якщо таблиця занадто велика, щоб її можна було кешувати в пам'яті сервером, тоді запити будуть повільнішими.
Використання наданого запиту буде надзвичайно повільним через використання методу сортування злиття для сортування даних.
Я б порадив переглянути дизайн, щоб ви використовували індекси для його отримання або переконувались, що він уже упорядкований таким чином, тому сортування не потрібно.