我想运行这些查询:
select url from weixin_kol_status where created_at>'2015-12-11 00:00:00' and created_at<'2015-12-11 23:59:59';
和
select url from weixin_kol_status where userid in ('...') and created_at>'2015-12-11 00:00:00' and created_at<'2015-12-11 23:59:59';
...使用此表定义:
CREATE TABLE `weixin_kol_status` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`url` varchar(512) NOT NULL,
`created_at` datetime NOT NULL,
`title` varchar(512) NOT NULL DEFAULT '',
`text` text,
`attitudes_count` int(11) NOT NULL DEFAULT '0',
`readcount` int(11) NOT NULL DEFAULT '0',
`reposts_count` int(11) NOT NULL DEFAULT '0',
`comments_count` int(11) NOT NULL DEFAULT '0',
`userid` varchar(32) NOT NULL,
`screen_name` varchar(32) NOT NULL,
`type` tinyint(4) NOT NULL DEFAULT '0',
`ext_data` text,
`is_topline` tinyint(4) NOT NULL DEFAULT '0',
`is_business` tinyint(4) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_url` (`url`(255)),
KEY `idx_userid` (`userid`),
KEY `idx_name` (`screen_name`),
KEY `idx_created_at` (`created_at`)
) ENGINE=InnoDB AUTO_INCREMENT=328727437 DEFAULT CHARSET=utf8 |
rows = 328727437;
查询需要几分钟时间。如何优化查询?我如何使用覆盖索引?
执行计划是:
explain select id from weixin_kol_status where created_at>='2015-12-11 00:00:00' and created_at<='2015-12-11 23:59:59'\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: weixin_kol_status
type: range
possible_keys: idx_created_at
key: idx_created_at
key_len: 5
ref: NULL
rows: 1433704
Extra: Using where; Using index
1 row in set (0.00 sec)
和
explain select id from weixin_kol_status where created_at='2015-12-11 00:00:00'\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: weixin_kol_status
type: ref
possible_keys: idx_created_at
key: idx_created_at
key_len: 5
ref: const
rows: 1
Extra: Using index
1 row in set (0.00 sec)
但是为什么第一个查询Extra: Using where; Using index
和第二个查询Extra: Using index
。第一个查询是否没有使用覆盖索引?
答案 0 :(得分:2)
如何使用覆盖索引?
你知道covering index是什么吗?它是一个索引,包含查询所需的所有列。
select url from weixin_kol_status where created_at>'2015-12-11 00:00:00' and created_at<'2015-12-11 23:59:59';
最小覆盖指数类似于
KEY `idx_created_url` (`created_at`, `url`)
而
select url from weixin_kol_status where userid in ('...') and created_at>'2015-12-11 00:00:00' and created_at<'2015-12-11 23:59:59';
最小覆盖指数可能
KEY `idx_created_user_url` (`created_at`, `userid`, `url`)
也将涵盖第一个查询或
KEY `idx_user_created_url` (`userid`, `created_at`, `url`)
这对第一个查询不起作用,但可能更好地优化第二个查询。
您可能需要写出url(512)
而不仅仅是url
。 VARCHAR
列不能很好地编制索引。如果您收到有关索引值太宽的错误,则可能无法对此查询使用覆盖索引。
覆盖索引很有用,因为它可以从内存中的索引中回答所有内容而无需转到磁盘上的表。由于内存比磁盘快,因此可以加快查询速度。当然,如果您的索引被分页,您仍然需要从磁盘加载它。因此,如果你受到记忆限制,这可能没有用。
请注意,查询每个表只使用一个索引,因此每列上的单独索引不会覆盖任何一个查询。您需要一个复合索引来一次覆盖所有需要的列。
作为旁注,我认为您的>
和<
应分别为>=
和<=
。可能不会有太大的区别,但你似乎每天都要跳两秒钟。
答案 1 :(得分:0)
有几个问题
<div id="x">Lorem ipsum dolor sit amet.</div>
将前255个字符限制为唯一;这可能是不可取的。
如果您需要强制使用长字符串(UNIQUE(url(255))
)的唯一性,请使用url
添加另一列,并将该列MD5(url)
设为一列。 (或类似的东西。)
索引中每列的限制为767个字节,因此如果您尝试创建UNIQUE
,则会得到INDEX(created_at, url)
,其中不覆盖,因为并非所有INDEX(created_at, url(255))
都在索引中。
url
这两个问题都没有用,因为他们没有使用您要问的EXPLAINs
。首先,它说SELECTs
,因为你说Using index
;实际查询是SELECT id
。这会导致大的性能差异。
你有一张非常大的桌子。我认为SELECT url
无法帮助提高速度。
这是表达1天PARTITIONing
的更好方式:
WHERE
加快速度
这是一种可以帮助两种查询的离墙技术。而不是
created_at >= '2015-12-11'
AND created_at < '2015-12-11' + INTERVAL 1 DAY
这样做:
PRIMARY KEY (`id`),
KEY `idx_created_at` (`created_at`)
这将在PRIMARY KEY(created_at, id),
INDEX(id)
上“群集”,从而显着减少I / O,特别是对于第一个created_at
。是的,SELECT
可以只是AUTO_INCREMENT
,而不是INDEXed
也不是UNIQUE
。
警告:要进行更改,需要花费数小时和大量磁盘空间。