这个查询非常慢。它非常简单,使用的3个表在联接和WHERE子句中的所有列上都进行了索引。如何优化该查询的查询或表?
这是缓慢的查询。它需要15-20秒才能运行。
SELECT
user.id,
user.name,
user.key,
user.secret,
account.id,
account.name,
account.admin,
setting.attribute,
setting.value
FROM user
INNER JOIN account ON account.id = user.account_id
INNER JOIN setting ON setting.user_id = user.id
AND setting.deleted = 0
WHERE user.deleted = 0这很可能是由setting表上的联接引起的,因为下面两个查询总共需要大约5秒。虽然,5秒似乎还有点长?
SELECT
user.id,
user.name,
user.user_key,
user.secret,
account.id,
account.name,
account.admin
FROM user
INNER JOIN account ON account.user_id = user.id
WHERE user.deleted = 0
SELECT
setting.user_id,
setting.attribute,
setting.value
FROM setting
WHERE setting.deleted = 0对慢速查询的解释:
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
1, 'SIMPLE', 'user', 'ALL', 'PRIMARY,idx_id,idx_deleted', null, null, null, 600, 'Using where'
1, 'SIMPLE', 'account', 'eq_ref', 'PRIMARY', 'PRIMARY', '8', 'user.account_id', 1, null
1, 'SIMPLE', 'setting', 'ref', 'attribute_version_unique,idx_user_id,indx_deleted', 'attribute_version_unique', '8', 'user.id', 35, 'Using where'模式:
CREATE TABLE user
(
id BIGINT(20) unsigned PRIMARY KEY NOT NULL AUTO_INCREMENT,
name VARCHAR(45) NOT NULL,
user_key VARCHAR(45) NOT NULL,
secret VARCHAR(16),
account_id BIGINT(20) unsigned NOT NULL,
name VARCHAR(40) NOT NULL,
demo TINYINT(1) DEFAULT '0' NOT NULL,
details VARCHAR(4000),
date_created DATETIME NOT NULL,
date_modified DATETIME NOT NULL,
deleted TINYINT(1) DEFAULT '0' NOT NULL
);
CREATE INDEX idx_date_modified ON user (date_modified);
CREATE INDEX idx_deleted ON user (deleted);
CREATE INDEX idx_id ON pub_application (id);
CREATE UNIQUE INDEX idx_name_unique ON user (user_key);CREATE TABLE account
(
id BIGINT(20) unsigned PRIMARY KEY NOT NULL AUTO_INCREMENT,
name VARCHAR(100) NOT NULL,
display_name VARCHAR(100),
admin TINYINT(1) DEFAULT '0' NOT NULL,
visibility VARCHAR(15) DEFAULT 'public',
cost DOUBLE,
monthly_fee VARCHAR(300),
date_created DATETIME NOT NULL,
date_modified DATETIME NOT NULL,
deleted TINYINT(1) DEFAULT '0'
);
CREATE INDEX idx_date_modified ON account (date_modified);CREATE TABLE setting
(
id BIGINT(20) unsigned PRIMARY KEY NOT NULL AUTO_INCREMENT,
user_id BIGINT(20) unsigned NOT NULL,
attribute VARCHAR(45) NOT NULL,
value VARCHAR(4000),
date_created DATETIME NOT NULL,
date_modified DATETIME NOT NULL,
deleted TINYINT(1) DEFAULT '0' NOT NULL
);
CREATE UNIQUE INDEX attribute_version_unique ON setting (user_id, attribute);
CREATE INDEX idx_user_id ON setting (user_id);
CREATE INDEX idx_date_modified ON setting (date_modified);
CREATE INDEX indx_deleted ON setting (deleted);发布于 2016-12-08 15:48:52
恕我直言,你偶然发现了一个常见的反模式。索引“所有列”通常是一个无用的举动。当满足查询时,MySQL (截至2016年末)最多可以利用每个表的一个索引。因此,额外的索引可能不会帮助查询,而且肯定会增加INSERT和UPDATE操作的开销。
这个查询可以通过某种目的设计的复合覆盖索引来改进。
在您的user表上尝试此索引。它是一个覆盖索引:用于包含满足查询所需的所有列。它是按照与WHERE子句匹配的顺序组织的。
CREATE INDEX idx_user_account_setting
ON user (deleted , account_id, id, name, key, secret);此覆盖索引可能对setting表有所帮助。
CREATE INDEX idx_setting_user
ON setting (user_id, deleted , attribute, value);也试试这个,如果第一列没有帮助的话,切换前两列的顺序。
CREATE INDEX idx_setting_user_alt
ON setting (deleted, user_id, attribute, value);最后在account上试试这个。
CREATE INDEX idx_account_user
ON account (id, name, admin);请,如果这些建议有助于留下简短的评论,告诉他们有多大的帮助。
看看这个。http://use-the-index-luke.com/
https://stackoverflow.com/questions/41042939
复制相似问题