MySQL随机函数RAND() 概率不稳定

MySQL随机函数RAND() 概率不稳定

说明一下问题

在一下查询的时候,虽然都是使用RAND()<(20/100)进行随机筛选数据,但是前者获取的比例并不在20%左右,而是在5%左右。

唯一不同的地方在与子查询里面的条件a.pos_sn = b.pos_sna.merchant_code = b.merchant_code,并且其他条件都一样。

【这两个条件不影响子查询的结果,子查询的结果是一模一样的】

代码 一

问题代码,随机数来的概率小很多,改成RAND()<(0.7)又突然概率超过70% ε=(´ο`*)))唉

  explain 
select p_i.*
    from table_order o_i
    left join (
    			select a.order_id as order_id,IFNULL(sum(b.trade_amount),0) as sumamount
    			from table_info a
    			left join table_deal b on a.merchant_code = b.merchant_code  --出问题的条件
    			GROUP BY a.order_id
    ) t_a on t_a.order_id = o_i.id
    left join table_info p_i on p_i.order_id = o_i.id 
    where t_a.sumamount = 0   and RAND()<(20/100)    --就是这里 随机一下
    	and p_i.id is not null

数据量为450 概率结果为 10-50之间跳动

分析结果:

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	PRIMARY	<derived2>	ALL	2	50	Using where
1	PRIMARY	o_i	eq_ref	PRIMARY,idx_pou	PRIMARY	8	t_a.order_id	1	5	Using where
1	PRIMARY	p_i	ref	PRIMARY,idx_pos_opu_id	idx_pos_opu_id	8	t_a.order_id	222042	90	Using index condition
2	DERIVED	a	range	idx_pos_opu_id	idx_pos_opu_id	8	2	10	Using index condition; Using where; Using temporary; Using filesort
2	DERIVED	b	range	pos_sn,idx_trade_time	idx_trade_time	6	1	100	Using where; Using join buffer (Block Nested Loop)

1 PRIMARY ALL 2 50 Using where

代码二

这个代码是没问题的,可以使用

  explain 
select  p_i.*
    from table_order o_i
    left join (
    			select a.order_id as order_id,IFNULL(sum(b.trade_amount),0) as sumamount
    			from table_info a
    			left join table_deal b on a.pos_sn = b.pos_sn    --出问题的条件
    			GROUP BY a.order_id
    ) t_a on t_a.order_id = o_i.id
    left join table_info p_i on p_i.order_id = o_i.id 
    where t_a.sumamount = 0   and  RAND()<(20/100) --就是这里 随机一下
    	and p_i.id is not null

** 数据量为450 概率结果为 80-120之间跳动**

分析结果:

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	PRIMARY	o_i	ALL	PRIMARY	25	4	Using where
1	PRIMARY	p_i	ref	PRIMARY,idx_pos_opu_id	idx_pos_opu_id	8	chuangshoubao.o_i.id	12865	90	Using index condition
1	PRIMARY	<derived2>	ref	<auto_key0>	<auto_key0>	23	chuangshoubao.o_i.id,const	10	100	Using where; Using index
2	DERIVED	a	range	idx_pos_opu_id	idx_pos_opu_id	8	662	10	Using index condition; Using where
2	DERIVED	b	ref	idx_mer_code,idx_trade_time	idx_mer_code	96	chuangshoubao.a.merchant_code	10	100	Using where

1 PRIMARY ref <auto_key0> <auto_key0> 23 chuangshoubao.o_i.id,const 10 100 Using where; Using index

分析处理

根据参考资料:https://www.cnblogs.com/lYng/p/9441467.html

这里的derived是叫做派生表的东东:解释为子查询–>在From后where前的子查询 。

MySQL 5.7开始优化器引入derived_merge,可以理解为Oracle的子查询展开,有优化器参数optimizer_switch='derived_merge=ON’来控制,默认为打开。

但是仍然有很多限制,当派生子查询存在以下操作时该特性无法生效:UNION 、GROUP BY、DISTINCT、LIMIT/OFFSET以及聚合操作

这里对比之后,猜测是索引之类的导致有问题的SQL子查询,使用了全表查询。

最后在核对了索引之后,结果依旧。【索引没有问题】

最后,发现是merchant_code这个字段被设置为is not null 导致的【这个是pos_sn字段唯一的区别了】

去掉不为空的限制之后,就突然妥妥的没问题了(ノ`Д)ノ

完全不知道这中间发生了什么?.?
路过的大佬,有没有了解的,留个资料链接呀

2019-03-13 小杭

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小_杭

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值