此查询非常慢。它非常简单,使用的3个表在JOIN和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
可能是问题是由设置表上的连接引起的,因为以下两个查询总共花费大约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);
答案 0 :(得分:3)
尊敬的是,你偶然发现了一个共同的反模式。索引“所有列”通常是无用的移动。 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);
如果这些建议有助于留下简短的评论,请说明他们帮助了多少。