Mysql分区执行计划疑惑

yananguo_1985 2010-07-08 06:41:55
最近在做Mysql分区测试的时候发现一个问题,希望能够得到大家的解答,在此希望高手帮忙。谢谢

首先建立Mysql分区表:


CREATE TABLE `businesslog` (
`UserId` VARCHAR(300) COLLATE utf8_bin NOT NULL,
`ServiceId` VARCHAR(300) COLLATE utf8_bin NOT NULL,
`CreatedDateTime` DATETIME NOT NULL
) ENGINE=MYISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin
PARTITION BY RANGE (YEAR(`CreatedDateTime`))
(PARTITION p0 VALUES LESS THAN (2000) ENGINE = MYISAM,
PARTITION p1 VALUES LESS THAN (2001) ENGINE = MYISAM,
PARTITION p2 VALUES LESS THAN (2002) ENGINE = MYISAM,
PARTITION p3 VALUES LESS THAN (2003) ENGINE = MYISAM,
PARTITION p4 VALUES LESS THAN (2004) ENGINE = MYISAM,
PARTITION p5 VALUES LESS THAN (2005) ENGINE = MYISAM,
PARTITION p6 VALUES LESS THAN (2006) ENGINE = MYISAM,
PARTITION p7 VALUES LESS THAN (2007) ENGINE = MYISAM,
PARTITION p8 VALUES LESS THAN (2008) ENGINE = MYISAM,
PARTITION p9 VALUES LESS THAN (2009) ENGINE = MYISAM,
PARTITION p10 VALUES LESS THAN (2010) ENGINE = MYISAM,
PARTITION p12 VALUES LESS THAN MAXVALUE ENGINE = MYISAM)



然后向表中插入1000多万行记录
数据分布如下:
SELECT YEAR(CreatedDateTime),COUNT(1) FROM businesslog
GROUP BY YEAR(CreatedDateTime)
--------------------------------
YEAR(CreatedDateTime) count(1)
1999 867940
2000 867940
2001 867940
2002 867940
2003 867940
2004 867940
2005 867940
2006 867940
2007 867940
2008 867940
2009 867940
2010 867940
2011 867940


现在执行执行计划:
EXPLAIN PARTITIONS
SELECT COUNT(1) FROM businesslog
WHERE CreatedDateTime>=DATE'2001-01-01' AND CreatedDateTime<=DATE'2001-12-31'

查看结果
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: businesslog
partitions: p2
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 11283220
Extra: Using where
1 row in set (0.03 sec)

可以看到查询对分区p2进行了扫描,和想象的结果一样,可是发现rows: 11283220显示的是表所有的行数,想象中的应该是
867940啊,怎么会出现这样的问题?希望高手解答。谢谢!
...全文
97 8 打赏 收藏 转发到动态 举报
写回复
用AI写文章
8 条回复
切换为时间正序
请发表友善的回复…
发表回复
maikelsong 2011-05-25
  • 打赏
  • 举报
回复
学习了。哈哈
wminjay 2010-07-13
  • 打赏
  • 举报
回复
mark
懒得去死 2010-07-13
  • 打赏
  • 举报
回复
GROUP BY用ALL是正常的。
但是你后面的那个查询分析就不正常了。
ACMAIN_CHM 2010-07-09
  • 打赏
  • 举报
回复
[Quote]这个是Mysql本身的BUG吗?[/Quote]对MYISAM引擎来说,这个数字只是用于估计值。谈不上是BUG,很多数据库产品都是这样。毕竟不可能真的在执行SQL查询之前就去把所有的数据都预先得到。这也是为什么有时MYSQL优化后的执行计划并不一定是最优的计划。
wwwwb 2010-07-09
  • 打赏
  • 举报
回复
应该不是BUG,MYSQL计算的大致数,并不是准确的
yananguo_1985 2010-07-09
  • 打赏
  • 举报
回复
这个是Mysql本身的BUG吗?
沉沦 2010-07-09
  • 打赏
  • 举报
回复
这个rows只是mysql的估算。。并不准确。。
ACMAIN_CHM 2010-07-08
  • 打赏
  • 举报
回复
rows: 11283220 是从表信息中获取的统计数据,并不准确。

56,677

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧