Как сделать MySQL разделение таблицы в рельсах?

0

Я работаю над веб-картой Rails, которая имеет таблицу mysql exam_scores с 35 миллионами записей (что может удвоиться через 2 года!). В таблице index_exam_scores_on_student_id_and_exam_id. все равно требуется много времени для выполнения запросов, поскольку это огромная таблица !. поэтому я искал решение для решения этой ситуации.

SHOW CREATE TABLE exam_scores;

  CREATE TABLE 'exam_scores' (
 'id' int(11) NOT NULL AUTO_INCREMENT,
 'student_id' int(11) DEFAULT NULL,
 'exam_id' int(11) DEFAULT NULL,
 'marks' decimal(7,2) DEFAULT NULL,
 'created_at' datetime DEFAULT NULL,
 'year' int(11) DEFAULT NULL,
 'result' tinyint(1) DEFAULT NULL,
 PRIMARY KEY ('id'),
 UNIQUE KEY 'index_exam_scores_on_student_id_and_exam_id' ('student_id','exam_id')
) ENGINE=InnoDB AUTO_INCREMENT=3542275 DEFAULT CHARSET=utf8

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

  • 0
    Что бы это ни стоило, разделение на MySQL вряд ли сильно поможет с проблемой производительности запросов в таблице с 35 миллионами строк. Ваша таблица определенно велика , но она невелика . Индексация, скорее всего, решит такую проблему. Пожалуйста, прочтите это и обратите особое внимание на раздел о производительности запросов. meta.stackoverflow.com/a/271056
  • 1
    Таким образом, у вас есть уникальный индекс для student_id / exam_id. Но каковы фактические запросы (которые медленные)? Пользуются ли они этим индексом?
Показать ещё 2 комментария
Теги:
query-performance

1 ответ

0

PARTITIONing редко помогает производительности. Чтобы помочь вам, мы должны видеть медленные запросы. Может быть, некоторым может помочь.

Между тем есть и другие вещи, которые могут улучшить производительность.

  • У вас есть миллиарды студентов? Вероятно, вам не нужен 4-байтовый INT для student_id и exam_id. Выбор меньшего типа данных, такого как 2-байтовый SMALLINT UNSIGNED (диапазон 0..65535), уменьшит размер данных. Убедитесь, что они совместимы между таблицами. Меньше → больше cacheable → быстрее.
  • Вы используете id где-нибудь еще? Вы, вероятно, можете избавиться от него и вместо этого продвигать ключ UNIQUE к PRIMARY KEY(student_id, exam_id). Это приведет к тому, что любые запросы, связанные с WHERE student_id = constant выполняться быстрее.
  • Существует двухбайтовый тип данных YEAR.
  • created_at ли использовано для чего-нибудь? (Он пахнет чем-то, предоставленным некоторыми рамками).

Ещё вопросы

Сообщество Overcoder
Наверх
Меню