没有合适的资源?快使用搜索试试~ 我知道了~
MySQL中distinct语句去查询重复记录及相关的性能讨论
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉

温馨提示


试读
3页
在 MySQL 查询中,可能会包含重复值。这并不成问题,不过,有时您也许希望仅仅列出不同(distinct)的值。 关键词 DISTINCT 用于返回唯一不同的值,就是去重啦。用法也很简单: SELECT DISTINCT * FROM tableName DISTINCT 这个关键字来过滤掉多余的重复记录只保留一条。 另外,如果要对某个字段去重,可以试下: SELECT *, COUNT(DISTINCT nowamagic) FROM table GROUP BY nowamagic 这个用法,MySQL的版本不能太低。 在编写查询之前,我们甚至应该对过滤条件进行排序,真正高效的条
资源推荐
资源详情
资源评论




















MySQL中中distinct语句去查询重复记录及相关的性能讨论语句去查询重复记录及相关的性能讨论
在 MySQL 查询中,可能会包含重复值。这并不成问题,不过,有时您也许希望仅仅列出不同(distinct)的值。
关键词 DISTINCT 用于返回唯一不同的值,就是去重啦。用法也很简单:
SELECT DISTINCT * FROM tableName
DISTINCT 这个关键字来过滤掉多余的重复记录只保留一条。
另外,如果要对某个字段去重,可以试下:
SELECT *, COUNT(DISTINCT nowamagic) FROM table GROUP BY nowamagic
这个用法,MySQL的版本不能太低。
在编写查询之前,我们甚至应该对过滤条件进行排序,真正高效的条件(可能有多个,涉到同的表)是查询的主要驱动力,低
效条件只起辅助作用。那么定义高效过滤条件的准则是什呢?首先,要看过滤条件能否尽快减少必须处理的数据量。所以,我
们必须倍加关注条件的写方式。
假设有四个表: customers 、 orders 、 orderdetail 、 articles ,现在假设 SQL 要处理的问题是:找出最近六个月内居住在
Gotham 市、订购了蝙蝠车的所有客户。当然,编写这个查询有多种方法, ANSI SQL 的推崇者可能写出下列语句:
select distinct c.custname
from customers c
join orders o
on o.custid = c.custid
join orderdetail od
on od.ordid = o.ordid
join articles a
on a.artid = od.artid
where c.city = 'GOTHAM'
and a.artname = 'BATMOBILE'
and o.ordered >= somefunc
其中, somefunc 是个函数,返回距今六个月前的具体日期。注意上面用了 distinct ,因为考虑到某个客户可以是大买家,最
近订购了好几台蝙蝠车。
暂不考虑优化器将如何改写此查询,我们先看一下这段代码的含义。首先,来自 customers 表的数据应只保留城市名为
Gotham 的记录。接着,搜索 orders 表,这意味着 custid 字段最好有索引,否则只有通过排序、合并或扫描 orders 表建立一
个哈希表才能保证查询速度。对 orders 表 ,还要针对订单日期进行过滤:如果优化器比较聪明,它会在连接( join )前先过
滤掉一些数据,从而减少后面要处理的数据量;不太聪明的优化器则可能会先做连接,再作过滤,这时在连接中指定过滤条件
利于提高性能,例如:
join orders o
on o.custid = c.custid
and a.ordered >= somefunc
注意,如果是:
left outer join orders o on
o.custid = c.custid
and a.ordered >= somefunc
此处关于left表的筛选条件将失效,因为是左外连接,左表的所有列都将出现在这次连接结果集中)。
即使过滤条件与连接( join )无关,优化器也会受到过滤条件的影响。例如,若 orderdetail 的主键为( ordid, artid ),即
ordid 为索引的第一个属性,那么我们可以利用索引找到与订单相关的记录。但如果主键是( artid, ordid )就太不幸了(注
意,就关系理论而言 ,无论哪个版本都是完全一样),此时的访问效率比( ordid, artid )作为索引时要差,甚至一些数据库
产品无法使用该索引(注 3 ),唯一的希望就是在ordid 上加独立索引了。
连接了表 orderdetail 和 orders 之后,来看 articles 表,这不会有问题,因为表 order 包括 artid 字段。最后,检查 articles 中
的值是否为 Batmobile 。查询就这样结束了,因为用了 distinct ,通过层层筛选的客户名还必须要排序,以剔除重复项目。
避免在最高层使用 distinct 应该是一条基本规则 。原因在于,即使我们遗漏了连接的某个条件, distinct 也会使查询 ” 看似正
确 ” 地执行 —— 无可否认,发现重复数据容易,发现数据不准确很难,所以避免在最高层使用 distinct 应该是一条基本规则。
发现结果不正确更难,例如,如果恰巧有多位客户都叫 ” Wayne ” , distinct 不但会剔除由同个客户的多张订单产生的重复项
目,也会剔除由名字相同的不同客户产生的重复项目。事实上,应该同时返回具唯一性的客户 ID 和客户名,以保证得到蝙蝠
车买家的完整清单。
要摆脱 distinct ,可考虑以下思路:客户在 Gohtam 市,而且满足存在性测试,即在最近六个月订购过蝙蝠车。注意,多数
(但非全部) SQL 方言支持以下语法:
select c.custname

weixin_38639471
- 粉丝: 8
- 资源: 933
上传资源 快速赚钱
我的内容管理 展开
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助


安全验证
文档复制为VIP权益,开通VIP直接复制

- 1
- 2
前往页