在为PT站保种组制作统计页面时，遇到数据库查询问题。通过LEFT JOIN连接users、peers、torrents和conserve表，发现JOIN顺序对结果有显著影响。当先连接users与peers，再连接torrents和conserve时，无法正确筛选出用户保种的种子。调整为先连接users与conserve，再连接peers和torrents，才能得到期望的结果。这表明LEFT JOIN的顺序对于包含NULL值的查询至关重要。
先说背景吧 是这样的 我在给一个pt站的保种组做个统计页面 统计方法如下
一个用户在给很多种子做种 他也从保种列表(种子列表的一部分)中选择了一些进行做种
统计的内容是:一个用户在保种列表里选择了希望保种的种子 同时他正在保种 计算这些种子的数量和容量
要求即使用户没有从保种列表中选择 也要显示出来
数据库中有这么几个表
用户 users
种子 torrents
用户做种 peers
保种 conserve
起初我用这样的查询 先将users与peers连接 再连接torrents 这样找到用所正在做种的所有种子
然后连接conserve 筛选出他选择保种的种子
可是结果却是 conserve连接根本没生效 找到的是用所正在做种的所有种子 而且不管conserve连接后面的条件怎么修改结果都不变
SELECT users.id as id, COUNT(torrents.id) as number, SUM(torrents.size) as size
FROM users
LEFT JOIN peers
ON users.id=peers.userid AND peers.seeder='yes'
LEFT JOIN torrents
ON peers.torrent=torrents.id
LEFT JOIN conserve
ON users.id=conserve.uid AND peers.torrent=conserve.tid
WHERE users.class>=11
GROUP BY users.id
我对left join也比较陌生 对他的执行顺序一直弄不大明白 在多次尝试后 找到了下面这样的查询语句
也就是先将users与conserve连接 再连接peers跟torrents 结果就是我所需要的
SELECT users.id as id, COUNT(torrents.id) as number, SUM(torrents.size) as size
FROM users
LEFT JOIN conserve
ON users.id=conserve.uid
LEFT JOIN peers
ON users.id=peers.userid AND peers.seeder='yes' AND peers.torrent=conserve.tid
LEFT JOIN torrents
ON peers.torrent=torrents.id
WHERE users.class>=11
GROUP BY users.id
其他顺序也尝试过 都不行 必须要先连接conserve
另外我还试过将
LEFT JOIN torrents
ON peers.torrent=torrents.id
改为
LEFT JOIN torrents
ON conserve.tid=torrents.id
扫一扫
2116
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
