基于MySQL 水平分区的优化示例

我们知道，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优化。MySQL 5.5 新增SIGNAL异常处理JDBC操作MySQL时注意的一些细节相关资讯 MySQL优化

MySQL中索引和优化的用法总结（今 14:24）
MySQL优化技术（04月09日）
关于skip_name_resolve参数的总结（03月26日）

MySQL优化 - 开启MySQL慢查询日志（05月12日）
MySQL explain执行计划优化（04月09日）
MySQL数据库的优化（03月05日）

本文评论查看全部评论（0）

评论声明