博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【原创】基于MySQL 水平分区的优化示例
阅读量:6588 次
发布时间:2019-06-24

本文共 1178 字,大约阅读时间需要 3 分钟。

   
我们知道,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://iqqno.baihongyu.com/

你可能感兴趣的文章
Linux写时拷贝技术(copy-on-write)
查看>>
opencv视频读取问题
查看>>
java Iterator Fail-fast机制
查看>>
Java堆外内存之五:堆外内存管理类ByteBuffer
查看>>
HTML5 input placeholder 颜色修改
查看>>
TJ/T808 终端通讯协议设计与实现(码农本色)
查看>>
分布式搜索引擎Elasticsearch的查询与过滤
查看>>
SolidEdge 工程图中如何给零件添加纹理或贴图
查看>>
【Java面试题】14 super.getClass()方法调用
查看>>
六种流行的语言---C、C++、python、Java、php、C#比较[转]
查看>>
AP INVOICES IMPORT API(NOT request)
查看>>
怎样面试程序猿
查看>>
Redhat6.5安装DB2 Express-C版本
查看>>
php的http数据传输get/post...
查看>>
【剑指Offer面试题】 九度OJ1368:二叉树中和为某一值的路径
查看>>
checkbox的name与JavaBean的交互时发现的一个现象
查看>>
基于Token的身份验证——JWT(转)
查看>>
Maven(五)之Maven配置阿里云镜像飞快下jar包
查看>>
Mysql加锁过程详解(5)-innodb 多版本并发控制原理详解
查看>>
script 里写 html 模版
查看>>