Mysql, что если слишком много данных в таблице

Question

Данные увеличиваются в одной таблице каждый день, это может снизить производительность.Я думал, смогу ли я создать триггер, который перемещает таблицу А в А1 и создает новую таблицу А каждый период времени, чтобы вставка или обновление могли быть быстрее в таблице А. Является ли это правильным способом сохранения производительности?Если нет, что мне делать?(например, вставьте или обновите 1000 строк в секунду в таблице A, какова производительность после 3 лет?)

Мы разрабатываем программное обеспечение для завода.Существуют производственные линии, на которых изготавливаются печатные платы.Нам нужно вставлять почти 60 записей в секунду в течение многих лет.(1000 строк кажутся преувеличенными)

Answer 1

Во-первых, вы говорите о нескольких терабайтах для одной таблицы.Ваш диск такой большой?Да, MySQL может справиться с такой большой таблицей.

Замедлится ли она?Это зависит от

• Индексы.Если у вас есть «случайные» индексы, INSERTs замедлится примерно до 1 вставки за удар диска.На вращающемся жестком диске это только около 100 в секунду.SSD может обрабатывать 1000 / сек.Пожалуйста, укажите SHOW CREATE TABLE.
• Есть ли в таблице AUTO_INCREMENT?Если это так, он должен быть BIGINT, а не INT.Но, если возможно, избавьтесь от всего этого вместе (чтобы сэкономить место).Опять же, давайте посмотрим, на SHOW.
• «точечные» запросы (загрузка одной строки через индекс) в основном не влияет размер таблицы.В таблице с триллионными строками они будут примерно в два раза медленнее, чем в таблице с миллионными строками.Точечный запрос займет миллисекунды или десятки миллисекунд;ничего страшного.
• Сканирование таблицы займет часы или дни;надеюсь, вы этого не делаете.
• Сканирование миллиардной строки части таблицы займет дни или недели, если вы не используете PRIMARY KEY или не имеете «покрывающего» индекса.Давайте посмотрим на запросы и SHOW.

Лучший метод - не хранить данные.Суммируйте его, как только он прибудет, сохраните итоги, затем подберите необработанные данные.(Хорошо, вы можете хранить raw в файле csv на тот случай, если вам нужно создать новую сводную таблицу или исправить ошибку в существующей.)

Наличие нескольких сводных таблиц вместо необработанные данные сократят данные до 1 ТБ и позволят соответствующим запросам выполняться в 10 раз быстрее.(Хорошо, точечные запросы будут только немного быстрее.)

PARTITIONing (или иначе разделить таблицу)?Это зависит.Давайте посмотрим на запросы и SHOW.Во многих ситуациях PARTITIONing ничего не ускоряет.

Будете ли вы удалять или изменять существующие строки?Надеюсь нет.Это добавляет больше аспектов проблем.Если, с другой стороны, вам нужно удалить «старые» данные, то это отличное применение для PARTITIONing.Для данных за 3 года я бы PARTITION BY RANGE(TO_DAYS(..)) и имел бы ежемесячные разделы.Тогда ежемесячный DROP PARTITION будет очень быстрым.

Answer 2

Маловероятно, что 1000 таблиц строк работают достаточно плохо, так как создание копии таблицы время от времени является общим чистым выигрышем.И вообще, что может иметь новая таблица, которую не имела бы старая таблица, что улучшило бы производительность?

Ключом к эффективной работе таблиц является интеллектуальное проектирование таблиц и управление индексами.Таким образом, миллиардные таблицы строк эффективны в геопространственной работе, каталогах библиотек, астрономии, и как интернет-поисковые системы находят полезные данные и т. Д.

Каждый определенный индекс оказывает большее влияние на mysql, особенно во время вставки строк.Предполагая, что операций чтения больше, чем вставок, это является преимуществом, поскольку большинство запросов быстро выполняются благодаря подходящему индексу.

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

Answer 3

Мне кажется, что с самого начала вы используете MySQL как-то не так.

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

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

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

Answer 4

Очень большие данные могут снизить производительность сервера, поэтому есть способ справиться с этим:

1) вам нужно создать другую таблицу для хранения архивных данных (старых данных) с использованием механизма хранения архивов.(https://dev.mysql.com/doc/refman/8.0/en/archive-storage-engine.html)

2) создайте задание / планировщик MySQL для перемещения старых записей в таблицу архива.расписание во временном интервале, когда сервер максимально простаивает.

3) после перемещения старых записей в архивную таблицу, переиндексируйте исходную таблицу.

это послужит повышению производительности.