我正在尝试改善表中具有约2000万行的数据库的查询时间:
以下是我正在运行的查询
`select DATE(timestamp) as timestamp, count(id) as authentications, count(distinct userid) as unique_users from `logs` where `org_id` = '54' and `timestamp` between '2016-09-14 09:00:00' and '2017-08-21 09:37:59' group by DATE(timestamp) order by `timestamp` asc`
该查询大约需要20-30秒才能完成(特定的
org id
大约有6-7百万条记录要通过)根据分析器,其花费95%的时间用于对结果进行排序。
我还有一个正在使用的索引(请参阅下面的说明):
1个简单日志
ref by_org_id_and_timestamp,org_id by_org_id_and_timestamp 4 const 6231240 Using index condition; Using where; Using filesort
表结构为:
id int(10) unsigned NO PRI auto_increment
org_id int(11) NO MUL
profile varchar(256) NO
linehash varchar(50) NO UNI
timestamp datetime NO
userid varchar(256) NO
server_id varchar(1024) NO
access_id int(11) NO
关于它为什么要花这么长时间或20-30秒是我将要获得的最好成绩的任何想法吗?
感谢您的关注(并希望您的帮助!)
------显示创建表日志------
id int(10) unsigned NOT NULL AUTO_INCREMENT, org_id int(11) NOT NULL, profile varchar(256) COLLATE utf8_unicode_ci NOT NULL, linehash varchar(50) COLLATE utf8_unicode_ci NOT NULL, timestamp datetime NOT NULL, userid varchar(256) COLLATE utf8_unicode_ci NOT NULL, server_id varchar(1024) COLLATE utf8_unicode_ci NOT NULL, access_id int(11) NOT NULL, PRIMARY KEY (id), UNIQUE KEY logs_linehash_unique (linehash), KEY by_org_id_and_timestamp (org_id,timestamp), KEY org_id (org_id), KEY by_org_id_and_timestamp_userid (org_id,timestamp,userid(255))
最佳答案
除了询问索引之外,我还将您的“ count(id)”更改为“ count(*)”。
我还会在...的桌子上有一个覆盖指数...
(org_id,timestamp,userid)
org_id和时间戳覆盖您的where条件。使用“ userID”可以帮助您进行计数(不重复),并且将所有内容都包含在索引中,引擎不必转到原始数据页面即可获取任何其他值。因此,它可以直接从索引处理您的查询。