我们正在将SugarCRM与MySQL 5.5数据库一起使用，并且在经常出现的查询中看到性能不佳。
不幸的是，由于SugarCRM的性质，无法对查询进行重新排序。我已经尝试通过索引进行优化，但我还没有走得太远。也就是说，我也不是很擅长这样做。
你能否建议任何可以改善我们结果的备用索引并避免使用filesort？
查询：
SELECT DISTINCT cases.id, cases.case_number, cases.status, cases.name,
cases.date_entered,
cases.assigned_user_id, cases.system_id
FROM cases
INNER JOIN team_sets_teams tst ON tst.team_set_id = cases.team_set_id
INNER JOIN team_memberships team_memberships ON tst.team_id = team_memberships.team_id
AND team_memberships.user_id = 'f09ab586-986c-a6f6-0c2e-4d1f1432b6ec'
AND team_memberships.deleted=0
ORDER BY cases.case_number DESC
LIMIT 0,11;
EXPLAIN结果：
select_type table type possible_keys key ref rows Extra
SIMPLE team_memberships ref team_id,user_id,idx_team_membership idx_team_membership const 26 Using where; Using index; Using temporary; Using filesort
SIMPLE tst ref idx_ud_set_id,idx_ud_team_id,idx_ud_team_set_id idx_ud_team_id sugarcrm.team_memberships.team_id 7 Using where
SIMPLE cases ref idx_cases_tmst_id,idx_cases_created idx_cases_tmst_id sugarcrm.tst.team_set_id 5 Using where
表格定义：
CREATE TABLE `cases` (
`id` char(36) NOT NULL,
`name` varchar(255) DEFAULT NULL,
`date_entered` datetime DEFAULT NULL,
`date_modified` datetime DEFAULT NULL,
`modified_user_id` char(36) DEFAULT NULL,
`created_by` char(36) DEFAULT NULL,
`description` text,
`deleted` tinyint(1) DEFAULT '0',
`assigned_user_id` char(36) DEFAULT NULL,
`team_id` char(36) DEFAULT NULL,
`case_number` int(11) NOT NULL AUTO_INCREMENT,
`type` varchar(255) DEFAULT NULL,
`status` varchar(100) DEFAULT NULL,
`priority` varchar(100) DEFAULT NULL,
`resolution` text,
`system_id` int(11) DEFAULT NULL,
`work_log` text,
`account_id` char(36) DEFAULT NULL,
`portal_viewable` tinyint(1) DEFAULT '0',
`team_set_id` char(36) DEFAULT NULL,
`parent_id` char(36) DEFAULT NULL,
`parent_type` varchar(255) DEFAULT 'Cases',
PRIMARY KEY (`id`),
UNIQUE KEY `casesnumk` (`case_number`),
UNIQUE KEY `case_number` (`case_number`,`system_id`),
KEY `idx_case_name` (`name`),
KEY `idx_account_id` (`account_id`),
KEY `idx_cases_stat_del` (`assigned_user_id`,`status`,`deleted`),
KEY `idx_cases_tmst_id` (`team_set_id`),
KEY `date_modified` (`date_modified`),
KEY `modified_user_id` (`modified_user_id`),
KEY `idx_cases_created` (`team_set_id`,`date_entered`),
KEY `team_id` (`team_id`),
KEY `idx_cases_del` (`deleted`),
KEY `idx_cases_date_entered` (`date_entered`),
KEY `idx_cases_status` (`status`),
KEY `idx_cases_parent_id` (`parent_id`),
KEY `idx_cases_priority` (`priority`)
) ENGINE=InnoDB
CREATE TABLE `team_sets_teams` (
`id` char(36) NOT NULL,
`team_set_id` char(36) DEFAULT NULL,
`team_id` char(36) DEFAULT NULL,
`date_modified` datetime DEFAULT NULL,
`deleted` tinyint(1) DEFAULT '0',
PRIMARY KEY (`id`),
KEY `idx_ud_set_id` (`team_set_id`,`team_id`),
KEY `idx_ud_team_id` (`team_id`),
KEY `idx_ud_team_set_id` (`team_set_id`),
KEY `idx_tst_deleted` (`deleted`)
) ENGINE=InnoDB
CREATE TABLE `team_memberships` (
`id` char(36) NOT NULL,
`team_id` char(36) DEFAULT NULL,
`user_id` char(36) DEFAULT NULL,
`explicit_assign` tinyint(1) DEFAULT '0',
`implicit_assign` tinyint(1) DEFAULT '0',
`date_modified` datetime DEFAULT NULL,
`deleted` tinyint(1) DEFAULT '0',
PRIMARY KEY (`id`),
KEY `date_modified` (`date_modified`),
KEY `team_id` (`team_id`),
KEY `user_id` (`user_id`),
KEY `idx_team_membership` (`user_id`,`team_id`,`deleted`)
) ENGINE=InnoDB
答案 0 :(得分：1)
从Ubuntu 10.04服务器切换到12.04时，我遇到了类似的问题。因为InnoDB是Ubuntu 12.04中打包的较新MySQL版本的默认引擎。我在MySQL服务器设置上玩了一些，比如query_cache_size，innodb_buffer_pool_size，innodb_log_buffer_size，它大大提高了性能。
答案 1 :(得分：1)
请尝试以下索引：
mysql> show indexes from team_memberships;
+------------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+------------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| team_memberships | 0 | PRIMARY | 1 | id | A | 665 | NULL | NULL | | BTREE | | |
| team_memberships | 1 | idx_team_membership | 1 | user_id | A | 665 | NULL | NULL | YES | BTREE | | |
| team_memberships | 1 | idx_team_membership | 2 | team_id | A | 665 | NULL | NULL | YES | BTREE | | |
| team_memberships | 1 | idx_teammemb_team_user | 1 | team_id | A | 665 | NULL | NULL | YES | BTREE | | |
| team_memberships | 1 | idx_teammemb_team_user | 2 | user_id | A | 665 | NULL | NULL | YES | BTREE | | |
| team_memberships | 1 | idx_team_deleted_user | 1 | user_id | A | 665 | NULL | NULL | YES | BTREE | | |
| team_memberships | 1 | idx_team_deleted_user | 2 | deleted | A | 665 | NULL | NULL | YES | BTREE | | |
| team_memberships | 1 | idx_team_deleted_user | 3 | team_id | A | 665 | NULL | NULL | YES | BTREE | | |
+------------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
mysql> show indexes from cases;
+-------+------------+--------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+--------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| cases | 0 | PRIMARY | 1 | id | A | 6 | NULL | NULL | | BTREE | | |
| cases | 0 | casesnumk | 1 | case_number | A | 6 | NULL | NULL | | BTREE | | |
| cases | 0 | case_number | 1 | case_number | A | 6 | NULL | NULL | | BTREE | | |
| cases | 0 | case_number | 2 | system_id | A | 6 | NULL | NULL | YES | BTREE | | |
| cases | 1 | idx_case_name | 1 | name | A | 6 | NULL | NULL | YES | BTREE | | |
| cases | 1 | idx_account_id | 1 | account_id | A | 6 | NULL | NULL | YES | BTREE | | |
| cases | 1 | idx_cases_stat_del | 1 | assigned_user_id | A | 3 | NULL | NULL | YES | BTREE | | |
| cases | 1 | idx_cases_stat_del | 2 | status | A | 6 | NULL | NULL | YES | BTREE | | |
| cases | 1 | idx_cases_stat_del | 3 | deleted | A | 6 | NULL | NULL | YES | BTREE | | |
| cases | 1 | idx_cases_tmst_id | 1 | team_set_id | A | 3 | NULL | NULL | YES | BTREE | | |
| cases | 1 | deleted | 1 | deleted | A | 3 | NULL | NULL | YES | BTREE | | |
| cases | 1 | team_id | 1 | team_id | A | 3 | NULL | NULL | YES | BTREE | | |
+-------+------------+--------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
mysql> show indexes from team_sets_teams;
+-----------------+------------+--------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-----------------+------------+--------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| team_sets_teams | 1 | idx_ud_set_id | 1 | team_set_id | A | 13 | NULL | NULL | YES | BTREE | | |
| team_sets_teams | 1 | idx_ud_set_id | 2 | team_id | A | 13 | NULL | NULL | YES | BTREE | | |
| team_sets_teams | 1 | idx_ud_team_id | 1 | team_id | A | 13 | NULL | NULL | YES | BTREE | | |
| team_sets_teams | 1 | deleted | 1 | deleted | A | 2 | NULL | NULL | YES | BTREE | | |
| team_sets_teams | 1 | idx_ud_team_set_id | 1 | team_set_id | A | 13 | NULL | NULL | YES | BTREE | | |
+-----------------+------------+--------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
答案 2 :(得分：0)
大部分时间都花在将临时表复制到磁盘上。当临时表中的数据太大而MySQL无法按照其配置设置保存在RAM中时，会发生这种情况。
尝试增加tmp_table_size和max_heap_table_size MySQL设置。这应该可以防止将临时表移动到磁盘上，从而加快查询速度（如果您的服务器有足够的RAM来处理它;这将取决于您在SugarCRM中同时拥有多少用户）。
这里的瓶颈现在看起来是你的磁盘i / o - 将服务器升级到我们的SSD也会有性能优势，如果不是这个查询（增加了上述设置），但对于SugarCRM整体来说。如果您无法增加上述设置以将临时表保存在RAM中，那么获得SSD将是下一个最佳选择。