Оптимизация структуры таблиц MySQL. Нужен совет - PullRequest
Новая
       6

Оптимизация структуры таблиц MySQL. Нужен совет

1 голос
/ 29 октября 2010

У меня есть эти структуры таблиц, и, хотя это работает, использование EXPLAIN для определенных SQL-запросов дает «Использование временного; Использование filesort 'на одной из таблиц. Это может снизить производительность, если таблица заполнится тысячами данных. Ниже приведены структура таблицы и пояснения к системе. 

CREATE TABLE IF NOT EXISTS `jobapp` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `fullname` varchar(50) NOT NULL,
  `icno` varchar(14) NOT NULL,
  `status` tinyint(1) NOT NULL DEFAULT '1',
  `timestamp` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `icno` (`icno`)
) ENGINE=MyISAM;

CREATE TABLE IF NOT EXISTS `jobapplied` (
  `appid` int(11) NOT NULL,
  `jid` int(11) NOT NULL,
  `jobstatus` tinyint(1) NOT NULL,
  `timestamp` int(10) NOT NULL,
  KEY `jid` (`jid`),
  KEY `appid` (`appid`)
) ENGINE=MyISAM;

Запрос, который я пробовал, который дает вышеупомянутое утверждение: 

EXPLAIN SELECT japp.id, japp.fullname, japp.icno, japp.status, japped.jid, japped.jobstatus
FROM jobapp AS japp
INNER JOIN jobapplied AS japped ON japp.id = japped.appid
WHERE japped.jid = '85'
AND japped.jobstatus = '2'
AND japp.status = '2'
ORDER BY japp.`timestamp` DESC

Эта система предназначена для набора новых сотрудников. После того, как регистрация открыта, сотни заявителей будут зарегистрированы за один раз. Им разрешено выбирать 5 разных работ. Позже, в конце сеанса регистрации, администратор будет проходить каждую работу по очереди. Я использовал одну таблицу (jobapplied) для хранения 2 элементов (идентификатор заявителя, идентификатор задания), чтобы записать, кто и что применял. И это таблица, которая вызывает вышеупомянутое утверждение. Я понимаю, что в этой таблице нет ПЕРВИЧНОГО ключа, но позже я просто не могу найти другого способа, чтобы администратор мог конкретно искать, какую работу подал.

Какой-нибудь совет, как мне оптимизировать стол?

Ответы [ 2 ]

1 голос
/ 10 февраля 2011

Помимо отсутствующих индексов и первичных ключей, упомянутых другими.,.

Это может снизить производительность после заполнения таблицы тысячами данных.

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

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

  • загрузить чистую версию базы данных с тысячами строк
  • "объяснить" интересующий вас запрос

FWIW, последний тест, который я выполнилНапример, около миллиарда строк - около 50 миллионов в каждой из 20 таблиц.План выполнения для этого запроса, который включал около 20 левых внешних объединений, сильно отличался от того, который был для образцов данных (всего несколько тысяч строк).

0 голосов
/ 29 октября 2010

Вы упорядочиваете по jobapp.timestamp, но индекс для метки времени отсутствует, поэтому потребуется сортировка таблиц (и, вероятно, временная), попробуйте добавить и индексировать метку времени для jobapp, например, KEY timid (timestamp, id)

...