Помогите оптимизировать MySQL запрос

Question

(с использованием MySQL 4.1.22)

Я не могу заставить этот запрос использовать индекс для большой таблицы (200 000+ строк), он выполняет полное сканирование таблицы. Запрос занимает около 1,2 секунды прямо сейчас. Я хочу, чтобы получилось менее 0,2 секунды, если это возможно.

Вот мой запрос:

SELECT st_issues.issue_id, st_issues.cat_id,st_categories.name AS cat_name, st_issues.status_id,st_statuses.name AS status_name, st_issues.priority_id,st_priorities.name AS priority_name,st_priorities.color AS color, st_issues.assigned_cid,assigned_u.firstname,assigned_u.lastname,assigned_u.screenname, message, rating, created_by_email,created_by_cid,created_by_uid,by_user.firstname AS by_firstname,by_user.lastname AS by_lastname,by_user.screenname AS by_screenname, st_issues.browser,from_url,created_by_store,created,st_issues.stamp
FROM st_issues
 JOIN st_categories ON (st_issues.cat_id=st_categories.cat_id)
 JOIN st_statuses ON (st_issues.status_id=st_statuses.status_id)
 JOIN st_priorities ON (st_issues.priority_id=st_priorities.priority_id)
 LEFT JOIN users AS assigned_u ON (assigned_u.cid=st_issues.assigned_cid)
 LEFT JOIN users AS by_user ON (by_user.uid=st_issues.created_by_uid)
 LEFT JOIN st_issue_changes ON (st_issues.issue_id=st_issue_changes.issue_id AND change_id=0)
WHERE st_issues.assigned_cid=0

Результаты объяснения:

1, 'SIMPLE', 'st_issues', 'ALL', '', '', , '', 4, 'Using where'
1, 'SIMPLE', 'st_categories', 'eq_ref', 'PRIMARY', 'PRIMARY', 1, 'sg.st_issues.cat_id', 1, ''
1, 'SIMPLE', 'st_priorities', 'eq_ref', 'PRIMARY', 'PRIMARY', 1, 'sg.st_issues.priority_id', 1, ''
1, 'SIMPLE', 'assigned_u', 'ref', 'cid', 'cid', 8, 'sg.st_issues.assigned_cid', 1, ''
1, 'SIMPLE', 'st_statuses', 'ALL', 'PRIMARY', '', , '', 4, 'Using where'
1, 'SIMPLE', 'by_user', 'ALL', '', '', , '', 221623, ''
1, 'SIMPLE', 'st_issue_changes', 'eq_ref', 'PRIMARY', 'PRIMARY', 6, 'sg.st_issues.issue_id,const', 1, ''

Очевидно, что проблема связана с объединением by_user, поскольку оно не использует индекс.

Вот некоторые определения таблицы 'users':

CREATE TABLE  `users` (
  `cid` double unsigned NOT NULL auto_increment,
  `uid` varchar(20) NOT NULL default '',
...
  `firstname` varchar(20) default NULL,
  `lastname` varchar(20) default NULL,
...
  PRIMARY KEY  (`uid`),
...
) ENGINE=InnoDB

У кого-нибудь есть идеи, почему он не использует первичный ключ в объединении?
У кого-нибудь есть идеи или подсказки, как ускорить этот запрос?

(я могу добавить определения таблиц других таблиц, если необходимо / желательно)

Edit:

Вот определение таблицы для st_issues:

CREATE TABLE  `st_issues` (
  `issue_id` int(10) unsigned NOT NULL auto_increment,
  `cat_id` tinyint(3) unsigned NOT NULL default '0',
  `status_id` tinyint(3) unsigned NOT NULL default '0',
  `priority_id` tinyint(3) unsigned NOT NULL default '0',
  `assigned_cid` int(10) unsigned NOT NULL default '0',
  `rating` tinyint(4) default NULL,
  `created_by_email` varchar(255) NOT NULL default '',
  `created_by_cid` int(10) unsigned NOT NULL default '0',
  `created_by_uid` varchar(20) NOT NULL default '',
  `created_by_store` tinyint(3) unsigned NOT NULL default '0',
  `browser` varchar(255) NOT NULL default '',
  `from_url` varchar(255) NOT NULL default '',
  `created` datetime NOT NULL default '0000-00-00 00:00:00',
  `stamp` datetime NOT NULL default '0000-00-00 00:00:00',
  PRIMARY KEY  (`issue_id`),
  KEY `idx_create_by_cid` (`created_by_cid`),
  KEY `idx_create_by_uid` (`created_by_uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Answer 1

Это все определение таблицы пользователей?

Потому что это говорит:

) ДВИГАТЕЛЬ = InnoDB

тогда как st_issues говорит:

) ДВИГАТЕЛЬ = CHARSET ПО УМОЛЧАНИЮ InnoDB = utf8;

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

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

Answer 2

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

• Добавить индекс на st_issues.assigned_cid.

• Измените первичный ключ таблицы users на cid вместо uid.

• Измените условие соединения для by_user, чтобы использовать cid вместо uid:

  LEFT JOIN users AS by_user ON (by_user.cid=st_issues.created_by_cid)
  

Затем я получил следующий EXPLAIN отчет (хотя с нулевыми строками данных):

+----+-------------+------------------+--------+---------------+--------------+---------+-------------------------------+------+-------------+
| id | select_type | table            | type   | possible_keys | key          | key_len | ref                           | rows | Extra       |
+----+-------------+------------------+--------+---------------+--------------+---------+-------------------------------+------+-------------+
|  1 | SIMPLE      | st_issues        | ref    | assigned_cid  | assigned_cid | 4       | const                         |    1 |             | 
|  1 | SIMPLE      | st_categories    | eq_ref | PRIMARY       | PRIMARY      | 1       | test.st_issues.cat_id         |    1 |             | 
|  1 | SIMPLE      | st_statuses      | eq_ref | PRIMARY       | PRIMARY      | 1       | test.st_issues.status_id      |    1 |             | 
|  1 | SIMPLE      | st_priorities    | eq_ref | PRIMARY       | PRIMARY      | 1       | test.st_issues.priority_id    |    1 |             | 
|  1 | SIMPLE      | assigned_u       | eq_ref | PRIMARY       | PRIMARY      | 8       | test.st_issues.assigned_cid   |    1 |             | 
|  1 | SIMPLE      | by_user          | eq_ref | PRIMARY       | PRIMARY      | 8       | test.st_issues.created_by_cid |    1 |             | 
|  1 | SIMPLE      | st_issue_changes | eq_ref | PRIMARY       | PRIMARY      | 8       | test.st_issues.issue_id,const |    1 | Using index | 
+----+-------------+------------------+--------+---------------+--------------+---------+-------------------------------+------+-------------+

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

Еще одна вещь, которую я бы предложил, - определить таблицы поиска st_categories и st_statuses с помощью естественного ключа , названия категории или статуса. Затем используйте этот естественный ключ из таблицы st_issues вместо использования псевдоключа tinyint. Преимущество состоит в том, что вам не нужно выполнять эти объединения, чтобы получить название категории или статуса; это уже в таблице st_issues.