我正在尝试改善表中具有约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”可以帮助您进行计数(不重复),并且将所有内容都包含在索引中,引擎不必转到原始数据页面即可获取任何其他值。因此,它可以直接从索引处理您的查询。

07-28 02:18
查看更多