Как я могу улучшить производительность базы данных MySQL?

Для файла.csv используйте LOAD DATA INFILE...

Вы используете InnoDB? Сколько у вас RAM? Какова ценность innodb_buffer_pool_size? Это может быть неправильно настроено - на основе замедления запросов при увеличении данных.

Давайте посмотрим на медленный запрос. И SHOW CREATE TABLE. Часто необходим "составной" индекс. Или переформулировка SELECT.

Я применил индекс в записи, где мне кажется, что мне это нужно

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

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

В настоящее время во многих отраслях промышленности используются две разные схемы OLAP для отчетности и аналитики и OLTP для хранения данных в режиме реального времени (включая некоторые отчеты в режиме реального времени).

Какую операцию вы хотите ускорить?

insert операцию

Хороший способ ускорить это - вставить записи в пакет. Например, добавьте 1000 записей в каждый оператор insert:

insert into test values (value_list),(value_list)...(value_list);

другие операции

Если ваш стол получит десятки миллионов записей, все будет замедляться. Это довольно часто. Чтобы ускорить это в этой ситуации, вот несколько советов:

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

Цель базы данных - хранить огромную информацию. Я думаю, что проблема не в вашей базе данных, это должны быть плохие запросы, объединения, буфер базы данных, индекс и кеш. Это следующая причина, из-за которой ваш ответ замедляется. Для получения дополнительной информации проверьте эту ссылку

Прежде всего, нам может быть полезно, какие именно данные вы хотите сохранить.

Обычно нет смысла хранить такой огромный объем данных за 3 дня, потому что никто никогда не сможет использовать это эффективным способом. Поэтому лучше сохранить данные перед хранением в базе данных.

например

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

Это все, конечно, возможно только в том случае, если данные базы данных доступны только для чтения. Если данные в базе данных изменены из приложения (и не только добавлены CSV-импортом), тогда использование более одной таблицы будет подвержено ошибкам.