我真的可以使用一些帮助来优化我的网站上用于显示排名的表格。我已经阅读了很多关于如何优化查询以及如何正确使用索引的内容,但即使在实现我认为可行的更改之后,也几乎看不到任何改进。我的快速修复只是使用前100,000名排名(每日更新并存储在不同的表格中)来提高现在的速度,但我真的不喜欢这个选项。
所以我有一个表,用于存储类似于以下内容的用户信息:
表'缓存':
id (Primary key)
name
region
country
score
存在关于用户的其他变量,但我不认为它们在这里是相关的,因为它们没有在排名中使用。
用户可以查看3个基本排名页面:
世界观:
SELECT cache name,region,country,score FROM cache ORDER BY score DESC LIMIT 0,26
区域视图:
SELECT name,region,country,score FROM cache WHERE region='Europe' ORDER BY score DESC LIMIT 0,26
和国家/地区视图:
SELECT name,region,country,score FROM cache WHERE region='Europe' AND country='Germany' ORDER BY score DESC LIMIT 0,26
我已经尝试了几乎所有我能想到的索引组合,以帮助缓解数据库的工作,虽然有些似乎有点帮助我找不到一个只返回26行的地区和国家/地区查询(仅仅是“得分”的索引,世界排名非常快)。
我觉得我可能会遗漏一些基本的东西,任何帮助都会非常感激!
一点额外信息:缓存表目前约为920兆字节,总计略多于800,000行。如果您可以使用更多信息,请告诉我。
答案 0 :(得分:2)
您的世界排名会从得分指数中受益,因为得分是查询中唯一的标准。它排序的逻辑序列内置于查询中。这很好。
其他查询将受益于区域索引。然而,类似于@Matt所表示的,区域,国家和得分的综合指数可能是最好的选择。注意,密钥的三列应该是区域,国家,分数序列。
答案 1 :(得分:0)
将一个指数放在国家,得分,地区。索引太多会让你失望。
答案 2 :(得分:0)
我们在谈论多少条记录?
我不是SQL大师,但在这种情况下,如果只是改变索引没有做到这一点。我会考虑使用表结构来查看我可以获得的性能提升。
id(pk)
LocationId(index)
命名
分数
LocationId(pk)
CountryId(索引)可能是
RegionId(索引)可能
CountryId
名称
RegionId
名字
LocationId(主键)
CountryId
RegionId
CountryId 名称
RegionId 名称
Procs中的临时表允许您在每种情况下选择位置ID。它可以减少您遇到的所有问题的复杂性:您将对1个查询计划进行故障排除,而不是3个。
努力会很高,收益会一直持续到你完成,所以我建议先看一下索引方法。
祝你好运