查询执行时间过长

Question

1. 我的查询大约需要2800秒才能得到输出。
2. 我们也有索引，但没有运气。
3. 我的目标是在2到3秒内得到输出。
4. 如果可能的话，请重写查询。 查询:选择ttl.id，ttl.url，ttl.canonical_url_id，从t_target_url ttl中选择ttl.own_domain_id=476和ttl.type != 10顺序，由ttl.week_entrances desc限制550000；解释计划：+----+-------------+-------+------+--------------------------------+---------------------------+---------+-------+--------+------+--------------------------------+---------------------------+---------+-------+----------+- own_domain_id_type_status，使用where，键入\ own_domain_id_type_status _(_使用文件\+----+-------------+-------+------+--------------------------------+---------------------------+---------+-------+表: t_target_url Create : CREATE t\_target\_url ( id int(11) NOT NULL AUTO_INCREMENTown\_domain\_id int(11)默认NULL，url varchar(2000) NOT NULL，create\_date日期时间默认NULL，friendly\_name varchar(255)默认NULL，section\_name\_id int(11)默认空，type int(11)默认NULL，status int(11)默认NULL，week\_entrances int(11)默认空注释‘最后7天入口’，week\_bounces int(11)默认空注释‘持续7天反弹’，canonical\_url\_id int(11)默认注释‘主URL ID’，不允许规范的规范，密钥id (id)，密钥urlindex (url(255))，密钥own\_domain\_id\_type\_status (own\_domain\_id，type，status)，密钥canonical\_url\_id (canonical\_url\_id)，密钥type (type，d32) ENGINE=InnoDB AUTO_INCREMENT=227984392按范围(type) (分区值小于(0)引擎= InnoDB，分区值小于(1)引擎= InnoDB，分区p2值小于(2) ENGINE = InnoDB，分区pEOW值小于MAXVALUE ENGINE = InnoDB) */ 1行

Answer 1

您的查询本身看起来很好，但是，order子句和可能的50万条记录可能是您的杀手。我会添加一个索引来帮助优化这个部分

( own_domain_id，week_entrances，类型)

因此，这样，您首先按下您的关键键"own_domain_id"，然后一切都已经有序。类型是for != 10，因此任何其他类型，如果在第二个索引位置，则会导致更多的问题。

评论反馈。

为了简化起见，where子句的关键键是"ttl.own_domain_id=476“。您只关心域ID 476的数据。现在，假设您有15种“类型”，跨越所有不同的星期入口，例如

own_domain_id   type   week_entrances
476             1      1000
476             1      1700
476             1      850
476             2      15000
476             2      4250
476             2      12000
476             7      2500
476             7      5300
476            10      1250
476            10      4100
476            12      8000
476            12      3150
476            15      5750
476            15      27000

这显然不是为了扩大你的50万容量，而是显示样本数据。如果有了类型!= 10，它仍然需要浏览id=476的所有记录，但是只排除了类型= 10的记录，然后它必须按每周入口顺序排列所有数据，这需要花费更多的时间。通过将周入口作为第二个位置中键的一部分，然后类型，数据将能够在返回的结果集中按正确的顺序进行优化。然而，当它到达"!= 10“的类型时，当遇到它们时，它仍然会跳过这些类型。以下是上述样本的订正指数数据。

own_domain_id   week_entrances  type   
476             850             1
476             1000            1
476             1250            10
476             1700            1
476             2500            7
476             3150            12
476             4100            10
476             4250            2
476             5300            7
476             5750            15
476             8000            12
476             12000           2
476             15000           2
476             27000           15

因此，正如您所看到的，数据已经按索引预先排序，应用降序对引擎来说没有问题，只需按反向顺序提取记录并跳过10的值。

这有用吗？

其他评论反馈每个萨勒曼。

想一想另一种方法，一家有10个不同分支地点的商店，每个分店都有自己的销售。交易收据存储在盒子里(字面意思)。如果您在给定日期查找所有事务，请想一想如何通过这些框。

Box 1 = Store #1 only, and transactions sorted by date
Box 2 = Store #2 only, and transactions sorted by date
Box ...
Box 10 = Store #10 only, sorted by date.

你得翻看10个盒子，把所有的日期都拿出来.或者在最初的问题中，除了一个日期之外，每一笔交易都要按美元的交易金额排列，而不管交易的日期是什么.那会是多么的混乱啊。

如果您将箱子的预组排序，而不管是哪一家商店

Box 1 = Sales from $1 - $1000 (all properly sorted by amount)
Box 2 = Sales from $1001 - $2000 (properly sorted)
Box ...
Box 10... same...

您仍然需要遍历所有的框，并将它们按顺序排列，但至少，当您正在查看事务时，您只需将排除日期的一个抛出即可忽略。

索引有助于预先组织引擎如何根据您的标准最好地通过它们。