Question

我目前正在开发一个需要优化的网站...因为首页大约需要15-20秒才能加载我认为一些优化会很好。

这是MySQL慢查询日志中出现的一个查询：

SELECT a.user,a.id
FROM `profil_perso` pp
INNER JOIN `acces` a ON pp.parrain = a.id
INNER JOIN `acces` ap ON ap.id = pp.id
WHERE pp.parrain_visibilite = '1'
  AND a.actif = 1
GROUP BY a.id
ORDER BY ap.depuis DESC LIMIT 15;

在profil_perso上（~207K行 - 包含电子邮件和个人资料），perso_id是主键，还有id（外键）+ {{1} （referer）+ parrain（显示引用者）是索引。

在parrain_visibilite上有acces这是主键，还有depuis（注册日期）被编入索引

基准测试显示了这一点：

第一次：1.94532990456
上次：1.94532990456
平均时间：0.0389438009262

我试着这样说：

id

基准仍显示：

第一次：1.96376991272
上次：1.96376991272
平均时间：0.0393264245987

任何降低查询时间的提示？

这是完整的索引：

access：

SELECT DISTINCT a.id, a.user
FROM `profil_perso` pp
LEFT JOIN `acces` a ON pp.parrain = a.id
WHERE pp.parrain_visibilite = 1
  AND a.actif = 1
  AND pp.id != 0
ORDER BY pp.id DESC LIMIT 15;

profil_perso：

id (primary)
derniere_visite -- last visit
pays_id -- country_id
depuis -- registration time
perso_id -- foreign key to profil_perso primary key
actif -- account status
compte_premium -- if account is premium

Answer 1

运行EXPLAIN SELECT DISTINCT a.id .....;

这将有助于向您显示缺少索引等的位置。

Answer 2

为什么这里有两个JOIN？

在acces (actif, depuis)上创建综合索引：

CREATE INDEX ix_acces_actif_depuis ON acces (actif, depuis)

，在profil_perso (parrain, parrain_visibilite)上创建一个综合索引：

CREATE INDEX ix_profilperso_parrain_parrainvisibilite ON profil_perso (parrain, parrain_visibilite)

试试这个：

SELECT  a.user, a.id
FROM    acces a
JOIN    profil_perso p
ON      pp.parrain = a.id
        AND pp.parrain_visibilite = 1
WHERE   a.actif = 1
ORDER BY
        a.actif DESC, a.depuis DESC
LIMIT 15

此查询将使用actif上的索引来避免排序，并使用profil_perso上的索引来查找并过滤掉不可见的parrain。

由于此处有LIMIT 15，因此此查询应该是即时的。

它还有助于了解您的actif字段的选择性。

要解决这个问题，请运行：

SELECT COUNT(DISTINCT actif) / COUNT(*)
FROM   acces

Answer 3

正确的答案取决于数据的分布（记录计数，字段的基数和字段组合等）和模式，如查询表达式。即使给出了这些信息，我们也只能提供测试建议，这只会带来更多的测试建议。

但是我们可以从第一次剪切开始，其中包含所涉及的表的模式，以及当前EXPLAIN的结果（运行twise，second和first结果）。

Answer 4

一般来说，您需要确保正确设置您的indecies - 不仅是主键，还包括表连接中使用的外键。

此外，对于您过滤/订购的任何字段，通常最好具有已定义的内容 - 因此，请再次确保这些内容已正确设置。

然而，我认为这里的重大表现可能是你正在排序207k记录以检索最后15个插入的事实 - 你能以不同的方式实现同样的目标吗？

MySQL查询优化

4 个答案: