基于MySQL 水平分区的优化示例
2012-07-26 08:47
344 查看
我们知道,MYSQL 5.1开始支持水平分区功能。 我们来尝试下如何在已经分区的表上面做查询优化。
总体来说,优化的原则和对单独的表做优化是一样的,保证对磁盘上表的扫描次数减小。
我们的表结构如下:
这里已经插入2W多行数据进行测试。
看看这条查询。
SELECT * FROM t1 WHERE system_type IN (1,2)
UNION ALL
SELECT * FROM t1 WHERE system_type = 3;
这条语句对system_type字段过滤了两次,然后进行了一次UNION ALL。 但是不知道,其实对两个分区一共进行了三次全表扫描。
我们改成这样:
SELECT * FROM t1 WHERE system_type IN (1,3)
UNION ALL
SELECT * FROM t1 WHERE system_type = 2;
看似简简单单的改变,我们把对两个分区的扫描从三次减少到了两次。 但是这样,开销也很大,能不能把UNION ALL去掉呢?当然可以。
SELECT * FROM t1 WHERE system_type >0 and system_type < 4;
去掉了UNION ALL,但是遇到的问题是对分区的扫描变成了范围查找,而且上下限不固定,相对来说,还有优化的空间。
我们改下对system_type列的过滤条件,变成如下:
SELECT * FROM t1 WHERE system_type in(1,2,3);
id select_type
table partitions
type possible_keys
key key_len
ref rows
Extra
1 SIMPLE
t1 r0,r1
ALL \N
\N \N \N
17719 Using where
现在,依然是范围扫描,但是上下限就很明了了。这样对扫描分区来说,很快的找到上下限,比之前来的要快,开销来的要小点了。
但是貌似还可以优化, 虽然过滤条件的上下限明显了,但是对于区域之内的扫描还是全分区(相当于整个表的全表。)。
OK,那现在给这个列加上索引吧。
ALTER TABLE t1 ANALYZE PARTITION r0,r1;
SELECT * FROM t1 WHERE system_type in(1,2,3);
id select_type
table partitions
type possible_keys
key key_len
ref rows
Extra
1 SIMPLE
t1 r0,r1
range NewIndex1
NewIndex1 1
\N 6462
Using where
当然,我们的例子非常简单, 这里只是为了演示下在水平分区下如何进行SQL优化。
http://blog.csdn.net/yueliangdao0608/article/details/7779108
总体来说,优化的原则和对单独的表做优化是一样的,保证对磁盘上表的扫描次数减小。
我们的表结构如下:
这里已经插入2W多行数据进行测试。
看看这条查询。
SELECT * FROM t1 WHERE system_type IN (1,2)
UNION ALL
SELECT * FROM t1 WHERE system_type = 3;
这条语句对system_type字段过滤了两次,然后进行了一次UNION ALL。 但是不知道,其实对两个分区一共进行了三次全表扫描。
我们改成这样:
SELECT * FROM t1 WHERE system_type IN (1,3)
UNION ALL
SELECT * FROM t1 WHERE system_type = 2;
看似简简单单的改变,我们把对两个分区的扫描从三次减少到了两次。 但是这样,开销也很大,能不能把UNION ALL去掉呢?当然可以。
SELECT * FROM t1 WHERE system_type >0 and system_type < 4;
去掉了UNION ALL,但是遇到的问题是对分区的扫描变成了范围查找,而且上下限不固定,相对来说,还有优化的空间。
我们改下对system_type列的过滤条件,变成如下:
SELECT * FROM t1 WHERE system_type in(1,2,3);
id select_type
table partitions
type possible_keys
key key_len
ref rows
Extra
1 SIMPLE
t1 r0,r1
ALL \N
\N \N \N
17719 Using where
现在,依然是范围扫描,但是上下限就很明了了。这样对扫描分区来说,很快的找到上下限,比之前来的要快,开销来的要小点了。
但是貌似还可以优化, 虽然过滤条件的上下限明显了,但是对于区域之内的扫描还是全分区(相当于整个表的全表。)。
OK,那现在给这个列加上索引吧。
ALTER TABLE t1 ANALYZE PARTITION r0,r1;
SELECT * FROM t1 WHERE system_type in(1,2,3);
id select_type
table partitions
type possible_keys
key key_len
ref rows
Extra
1 SIMPLE
t1 r0,r1
range NewIndex1
NewIndex1 1
\N 6462
Using where
当然,我们的例子非常简单, 这里只是为了演示下在水平分区下如何进行SQL优化。
http://blog.csdn.net/yueliangdao0608/article/details/7779108
相关文章推荐
- 基于MySQL 水平分区的优化示例
- 基于MySQL 水平分区的优化示例
- 【原创】基于MySQL 水平分区的优化示例
- 基于MYCAT的MYSQL主从与读写分离配置详解与示例
- 十六、mysql 分区之 简单sql优化1
- mysql中的优化, 简单的说了一下垂直分表, 水平分表(有几种模运算),读写分离.
- Python3.6基于正则实现的计算器示例【无优化简单注释版】
- MYSQL IN 与 EXISTS 的优化示例介绍
- Mysql优化实验(一)-- 分区
- mysql查询优化之基于索引的排序
- MySQL水平分割示例
- vsftpd的基于pam_mysql的虚拟用户配置示例
- MySQL基于时间字段进行分区的方案总结
- 索引的分析和优化(基于MySQL)
- 【mysql的设计与优化专题(4)】表的垂直拆分和水平拆分
- mysql 【mysql的设计与优化专题】表的垂直拆分和水平拆分
- MySQL 5.5 range分区增加删除处理的方法示例
- MySQL数据库优化(六)——MySQL分表和表分区
- 【MySQL】基于MySQL的SQL优化(一)——从用explain关键字分析SQL语句开始
- mysql优化篇之表分区