gpt4 book ai didi

mysql - 是否有可能更快地获得查询?

转载 作者:可可西里 更新时间:2023-11-01 07:51:08 24 4
gpt4 key购买 nike

我是 SQL 的新手,需要帮助我有 4 个表:

helmet                                  arm
+------+---------+-----+--------+ +------+---------+-----+--------+
| id | name | def | weight | | id | name | def | weight |
+------+---------+-----+--------+ +------+---------+-----+--------+
| 1 | head1 | 5 | 2.2 | | 1 | arm1 | 4 | 2.7 |
| 2 | head2 | 6 | 2.9 | | 2 | arm2 | 5 | 3.1 |
| 3 | head3 | 7 | 3.5 | | 3 | arm3 | 2 | 1.8 |
+------+---------+-----+--------+ +------+---------+-----+--------+

body leg
+------+---------+-----+--------+ +------+---------+-----+--------+
| id | name | def | weight | | id | name | def | weight |
+------+---------+-----+--------+ +------+---------+-----+--------+
| 1 | body1 | 10 | 5.5 | | 1 | leg1 | 8 | 3.5 |
| 2 | body2 | 5 | 2.4 | | 2 | leg2 | 5 | 2.0 |
| 3 | body3 | 17 | 6.9 | | 3 | leg3 | 8 | 1.8 |
+------+---------+-----+--------+ +------+---------+-----+--------+`

我正在寻找最高的 totaldef which totalweight <= input
像这样:总重量 <= 10

查询:

select 
helmet.name as hname, body.name as bname,
arm.name as aname, leg.name as lname,
helmet.poise + body.poise + arm.poise + leg.poise as totalpoise,
helmet.weight + body.weight + arm.weight + leg.weight as totalweight
from
helmet
inner join
body on 1=1
inner join
arm on 1=1
inner join
leg on 1=1
where
helmet.weight + body.weight + arm.weight + leg.weight <= 10
order by
totalpoise desc
limit 5

结果:

+-------+-------+-------+-------+----------+-------------+
| hname | bname | aname | lname | totaldef | totalweight |
+-------+-------+------ +-------+----------+-------------+
| head2 | body2 | arm1 | leg3 | 23 | 9.8 |
| head1 | body2 | arm2 | leg3 | 23 | 9.5 |
| head3 | body2 | arm3 | leg3 | 22 | 9.5 |
| head1 | body2 | arm1 | leg3 | 22 | 9.1 |
| head2 | body2 | arm3 | leg3 | 21 | 8.9 |
+-------+-------+-------+-------+----------+-------------+

问题是每个表大约有 100 行,因此可能的结果是 1 亿多行。查询需要很长时间。我不确定这与我的硬件或数据库或查询类型有关。

P.S:我使用 HDD 并有 8GB 内存。我已经在 MySQL 和 PostgreSQL 上进行了测试。

更新我还没有创建索引。

这是解释计划吗? explain plan

需要多长时间?这取决于输入。在 MySQL 上大约需要几分钟 - 几个小时。
在 PostgreSQL 上大约需要 30 秒 - 2 分钟。

更新 2 我的表格永远不会改变。那么我可以将所有结果存储在一个表中吗?有帮助吗?

更新 3 我考虑分区。它可能快得多,但问题是如果下分区中的某些 [armor set] 的 totaldef 比上分区中的 [armor set] 多。示例:

[head1,arm1,body1,leg1][totaldef 25][totalweight 9.9]
[head2,arm2,body2,leg2][totaldef 20][totalweight 11.0]

所以分区总重量 >10 会错过那个 [armor set],因为它在其他分区中。

这是供任何想要测试的人使用的 CSV 文件。 CSV file

更新 4 我认为最快的方法是创建 materialized view但我想性能的关键是对其进行排序。我不知道哪种排序可以帮助物化 View 或索引,但我对它们都进行了排序并且很有用。

没想到会得到这么多帮助。谢谢。

最佳答案

A materialized view具有适当索引的性能相当不错,在我使用 Postgresql 配置的老化 SSD 桌面上运行 1.8 秒:

create materialized view v as
select
h.name as hname, b.name as bname, a.name as aname, l.name as lname,
total_poise, total_weight
from
helmet h
cross join
body b
cross join
arm a
cross join
leg l
cross join lateral (
select
h.weight + b.weight + l.weight + a.weight as total_weight,
h.poise + b.poise + l.poise + a.poise as total_poise
) total
order by total_poise desc, total_weight
;

create index v_index on v (total_poise desc, total_weight);

执行与分析:

select *
from v
where total_weight <= 10
order by total_poise desc, total_weight
limit 5
;
hname | bname | aname | lname | total_poise | total_weight
-----------------------+--------------------------+------------------------+--------------------------+-------------+--------------
Fume Sorcerer Mask+10 | Moon Butterfly Wings+5 | Velstadt`s Gauntlets+5 | Prisoner`s Waistcloth+10 | 20 | 9.4
Fume Sorcerer Mask+10 | Lion Warrior Cape+10 | Velstadt`s Gauntlets+5 | Prisoner`s Waistcloth+10 | 20 | 9.5
Fume Sorcerer Mask+10 | Red Lion Warrior Cape+10 | Velstadt`s Gauntlets+5 | Prisoner`s Waistcloth+10 | 20 | 9.5
Fume Sorcerer Mask+10 | Moon Butterfly Wings+5 | Velstadt`s Gauntlets+5 | Lion Warrior Skirt+10 | 20 | 9.6
Fume Sorcerer Mask+10 | Moon Butterfly Wings+5 | Velstadt`s Gauntlets+5 | Moon Butterfly Skirt+10 | 20 | 9.6


explain analyze
select *
from v
where total_weight <= 10
order by total_poise desc, total_weight
limit 5
;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.57..11.71 rows=5 width=88) (actual time=1847.680..1847.694 rows=5 loops=1)
-> Index Scan using v_index on v (cost=0.57..11191615.70 rows=5020071 width=88) (actual time=1847.678..1847.691 rows=5 loops=1)
Index Cond: (total_weight <= '10'::double precision)
Planning time: 0.126 ms
Execution time: 1847.722 ms

关于mysql - 是否有可能更快地获得查询?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42312741/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com