MySQL 5.5 分区之高级分区实例及性能分析

上次我们介绍了:MySQL 5.5 分区之truncate分区详解,本文我们主要介绍一下MySQL 5.5 分区之高级分区实例及性能分析,接下来我们就开始一一介绍这部分内容。

为了帮助你更好地掌握新功能,我们再来看一个更高级一点的例子,对于比较务实的读者更有意义,下面是表的定义脚本:

  1. CREATE TABLE employees (    
  2.   emp_no int(11) NOT NULL,    
  3.   birth_date date NOT NULL,    
  4.   first_name varchar(14) NOT NULL,    
  5.   last_name varchar(16) NOT NULL,    
  6.   gender char(1) DEFAULT NULL,    
  7.   hire_date date NOT NULL   
  8. ENGINE=MyISAM    
  9. PARTITION BY RANGE  COLUMNS(gender,hire_date)    
  10. (PARTITION p01 VALUES LESS THAN ('F','1990-01-01') ,    
  11. PARTITION p02 VALUES LESS THAN ('F','2000-01-01') ,    
  12. PARTITION p03 VALUES LESS THAN ('F',MAXVALUE) ,    
  13. PARTITION p04 VALUES LESS THAN ('M','1990-01-01') ,    
  14. PARTITION p05 VALUES LESS THAN ('M','2000-01-01') ,    
  15. PARTITION p06 VALUES LESS THAN ('M',MAXVALUE) ,    
  16. PARTITION p07 VALUES LESS THAN (MAXVALUE,MAXVALUE)  

和上面的例子不同,这个例子更好理解,***个分区用来存储雇佣于1990年以前的女职员,第二个分区存储股用于1990-2000年之间的女职员,第三个分区存储所有剩下的女职员。对于分区p04到p06,我们策略是一样的,只不过存储的是男职员。***一个分区是控制情况。

看完后你可能要问,我怎么知道某一行存储在那个分区中的?有两个办法,***个办法是使用与分区定义相同的条件作为查询条件进行查询。

  1. SELECT   
  2. CASE   
  3.   WHEN gender = 'F' AND hire_date < '1990-01-01'   
  4.   THEN 'p1'   
  5.   WHEN gender = 'F' AND hire_date < '2000-01-01'   
  6.   THEN 'p2'   
  7.   WHEN gender = 'F' AND hire_date < '2999-01-01'   
  8.   THEN 'p3'   
  9.   WHEN gender = 'M' AND hire_date < '1990-01-01'   
  10.   THEN 'p4'   
  11.   WHEN gender = 'M' AND hire_date < '2000-01-01'   
  12.   THEN 'p5'   
  13.   WHEN gender = 'M' AND hire_date < '2999-01-01'   
  14.   THEN 'p6'   
  15. ELSE   
  16.   'p7'   
  17. END as p,    
  18. COUNT(*) AS rows   
  19. FROM employees    
  20. GROUP BY p;    
  21.  
  22. +------+-------+    
  23. | p    | rows  |    
  24. +------+-------+    
  25. | p1   | 66212 |    
  26. | p2   | 53832 |    
  27. | p3   |     7 |    
  28. | p4   | 98585 |    
  29. | p5   | 81382 |    
  30. | p6   |     6 |    
  31. +------+-------+  

如果表是MyISAM或ARCHIVE,你可以信任由INFORMATION_SCHEMA提供的统计信息。

  1. SELECT   
  2.   partition_name part,    
  3.   partition_expression expr,    
  4.   partition_description descr,    
  5.   table_rows    
  6. FROM   
  7.   INFORMATION_SCHEMA.partitions    
  8. WHERE   
  9.   TABLE_SCHEMA = schema()    
  10.   AND TABLE_NAME='employees';    
  11. +------+------------------+-------------------+------------+    
  12. | part | expr             | descr             | table_rows |    
  13. +------+------------------+-------------------+------------+    
  14. | p01  | gender,hire_date | 'F','1990-01-01'  |      66212 |    
  15. | p02  | gender,hire_date | 'F','2000-01-01'  |      53832 |    
  16. | p03  | gender,hire_date | 'F',MAXVALUE      |          7 |    
  17. | p04  | gender,hire_date | 'M','1990-01-01'  |      98585 |    
  18. | p05  | gender,hire_date | 'M','2000-01-01'  |      81382 |    
  19. | p06  | gender,hire_date | 'M',MAXVALUE      |          6 |    
  20. | p07  | gender,hire_date | MAXVALUE,MAXVALUE |          0 |    
  21. +------+------------------+-------------------+------------+  

如果存储引擎是InnoDB,上面的值就是一个近似值,如果你需要确切的值,那你就不能信任它们。

另一个问题是它的性能,这些增强触发了分区修整吗?答案毫不含糊,是的。与MySQL 5.1有所不同,在5.1中日期分区只能与两个函数工作,在MySQL 5.5中,任何使用了COLUMNS关键字定义的分区都可以使用分区修整,下面还是测试一下吧。

  1. select count(*) from employees where gender='F' and hire_date < '1990-01-01';    
  2. +----------+    
  3. | count(*) |    
  4. +----------+    
  5. |    66212 |    
  6. +----------+    
  7. 1 row in set (0.05 sec)    
  8.  
  9. explain partitions select count(*) from employees where gender='F' and hire_date < '1990-01-01'\G    
  10. *************************** 1. row ***************************    
  11.            id: 1    
  12.   select_type: SIMPLE    
  13.         table: employees    
  14.    partitions: p01    
  15.          type: ALL   
  16. possible_keys: NULL   
  17.           key: NULL   
  18.       key_len: NULL   
  19.           ref: NULL   
  20.          rows: 300024    
  21.         Extra: Using where  

使用定义***个分区的条件,我们获得了一个非常优化的查询,不仅如此,部分条件也将从分区修整中受益。

  1. select count(*) from employees where gender='F';    
  2. +----------+    
  3. | count(*) |    
  4. +----------+    
  5. |   120051 |    
  6. +----------+    
  7. 1 row in set (0.12 sec)    
  8.  
  9. explain partitions select count(*) from employees where gender='F'\G    
  10. *************************** 1. row ***************************    
  11.            id: 1    
  12.   select_type: SIMPLE    
  13.         table: employees    
  14.    partitions: p01,p02,p03,p04    
  15.          type: ALL   
  16. possible_keys: NULL   
  17.           key: NULL   
  18.       key_len: NULL   
  19.           ref: NULL   
  20.          rows: 300024    
  21.         Extra: Using where 

它和复合索引的算法一样,如果你的条件指的是索引最左边的部分,MySQL将会使用它。与此类似,如果你的条件指的是分区定义最左边的部分,MySQL将会尽可能修整。它和复合索引一起出现,如果你只使用最右边的条件,分区修整不会工作。

  1. select count(*) from employees where hire_date < '1990-01-01';    
  2. +----------+    
  3. | count(*) |    
  4. +----------+    
  5. |   164797 |    
  6. +----------+    
  7. 1 row in set (0.18 sec)    
  8.  
  9. explain partitions select count(*) from employees where hire_date < '1990-01-01'\G    
  10. *************************** 1. row ***************************    
  11.            id: 1    
  12.   select_type: SIMPLE    
  13.         table: employees    
  14.    partitions: p01,p02,p03,p04,p05,p06,p07    
  15.          type: ALL   
  16. possible_keys: NULL   
  17.           key: NULL   
  18.       key_len: NULL   
  19.           ref: NULL   
  20.          rows: 300024    
  21.         Extra: Using where 

如果不用分区定义的***部分,使用分区定义的第二部分,那么将会发生全表扫描,在设计分区和编写查询时要紧记这一条。

关于MySQL 5.5 分区之高级分区实例及性能分析的知识就介绍到这里了,希望本次的介绍能够对您有所收获!

原文出处:http://lujia35.iteye.com/blog/718899。

【编辑推荐】

  1. MySQL 5.5 分区之多列分区详解
  2. MySQL 5.5 分区之非整数列分区详解
  3. MySQL数据库MVCC多版本并发控制简介
  4. 适合初学者的MySQL学习笔记之MySQL管理心得
  5. MySQL数据库将多条记录的单个字段合并成一条记录

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/240710.html<

(0)
管理的头像管理
上一篇2025-04-24 00:12
下一篇 2025-04-24 00:14

相关推荐

  • 服务器域名解析失败怎么排查,是什么原因造成的?

    服务器域名解析失败的根本原因在于DNS系统无法将域名正确转换为IP地址,排查应遵循从客户端到服务端的顺序:先检查本地网络和DNS缓存,再验证域名解析记录和权威服务器状态,第一步:检查本地网络与DNS设置测试网络连通性先确认你的设备是否正常联网,打开命令提示符或终端,输入ping 8.8.8.8,如果返回回复数据……

    2026-07-27
    0
  • 站群服务器怎么设置不同环境配置,有哪些注意事项?

    站群服务器设置不同的环境配置,核心在于通过虚拟化或容器化技术实现站点隔离,再结合Web服务器配置为每个站点分配独立的PHP版本、数据库及运行参数,从而满足多样化需求,为什么站群服务器需要环境隔离?不同CMS依赖的PHP版本差异明显,例如WordPress推荐PHP 7.4以上,而Drupal 7仍基于PHP 5……

    2026-07-27
    0
  • 站群服务器如何批量管理更高效,有哪些管理技巧?

    站群服务器批量管理想提效,自动化是唯一出路,通过统一配置管理工具与面板系统,结合服务商提供的底层基础设施支持,能将运维效率提升数倍,批量管理的核心痛点与解决思路多台站群服务器分散管理,最常见的问题就是重复劳动,每次软件更新、配置修改、安全加固,都需要逐台登录操作,不仅耗时,还容易漏掉某台机器,更头疼的是,一旦某……

    2026-07-27
    0
  • 服务器磁盘IO过高如何优化?,磁盘IO过高的原因有哪些?

    服务器磁盘IO过高,核心优化路径是“先定位、再分流、后升级”,你需要通过系统工具精确判断究竟是应用程序、日志策略还是硬件瓶颈导致,然后针对性地从代码、缓存、存储架构和硬件选型四个层面下手,其中选择持有持牌自营机房和增值电信业务经营许可证的服务商,能从根本上保障底层IO稳定性,定位IO瓶颈:动手优化的第一步盲目优……

    2026-07-27
    0
  • 跨境网站访问延迟高怎么解决,网站访问慢的原因是什么?

    跨境网站访问延迟高的核心解决思路在于多维度优化网络路径,包括使用全球CDN加速、选择靠近目标区域的优质IDC机房、调整传输协议以及精简应用层资源,其中服务商的基础设施质量直接决定优化上限,为什么跨境访问延迟高?三大核心因素物理距离与光速限制数据包在海底光缆中的传输速度受限于介质,从中国到美国西海岸的物理往返时间……

    2026-07-27
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注