MySQL优化之分区表_MySQL
当数据库数据量涨到一定数量时,性能就成为我们不能不关注的问题,如何优化呢? 常用的方式不外乎那么几种:
1、分表,即把一个很大的表达数据分到几个表中,这样每个表数据都不多。
优点:提高并发量,减小锁的粒度
缺点:代码维护成本高,相关sql都需要改动
2、分区,所有的数据还在一个表中,但物理存储数据根据一定的规则存放在不同的文件中,文件也可以放到另外磁盘上
优点:代码维护量小,基本不用改动,提高IO吞吐量
缺点:表的并发程度没有增加
3、拆分业务,这个本质还是分表。
优点:长期支持更好
缺点:代码逻辑重构,工作量很大
当然,每种情况都有合适的应用场景,需要根据具体业务具体选择。由于分表和拆分业务和mysql本身关系不大属于业务层面,我们只说和数据库关系最紧密的方式:表分区。不过使用表分区有个前提就是你的数据库必须支持。那么,怎么知道我的数据库是否支持表分区呢 ? 请执行下面命令
代码如下:
show plugins; ---在mysql控制台中执行
据说5.4一下的版本是另外一个命令,不过我没有测试
代码如下:
show variables like '%part%';
数据库的表分区一般有两种方式:纵向和横向。纵向就是把表中不同字段分到不同数据文件中。横向是把表中前一部分数据放到一个文件中,另一部分数据放到一个文件中。mysql只支持后后一种方式,横向拆分。
1、创建分区表
如果要使用表的分区优势,不但要数据库版本支持分区,关键要建分区表,这个表和普通表不一样,并且必须建表的时候就要指定分区,否则无法把普通表改成分区表。那么,如果创建一个分区表呢? 其他很简单,请看下面建表语句
CREATE TABLE `T_part` ( `f_id` INT DEFAULT NULL, `f_name` VARCHAR (20) DEFAULT NULL, PRIMARY KEY (`f_id`) ) ENGINE = myisam DEFAULT CHARSET = utf8 PARTITION BY RANGE (f_id)( -----指定分区方式 PARTITION p0 VALUES less THAN (10),-- 分了两个区 PARTITION p1 VALUES less THAN (20) )
上面语句建了一个“T_part”表,有两个字段f_id和f_name,并且根据RANGE方式把表分成两个区p0、p1,当f_id小于10放入p0分区,当f_id大于0小于20放入分区p1. 那么当f_id大于20的数据放入哪个分区呢? 你猜对了,insert语句会报错。
看到了吧,创建分区表就这么简单!当然,你随时可以添加删除分区,不过要注意,删除分区的时候会把当前分区下所有数据都删除。
代码如下:
alter table T_part add partition(partition p2 values less than (MAXVALUE)); ---新增分区
alter table T_part DROP partition p2; ----删除分区
2、表分区的几种方式
mysql支持5种分区方式:RANGE分区、LIST分区、HASH分区、LINEAR HASH分区和KEY分区。每种分区都有自己的使用场景。
1)RANGE分区:
RANGE分区的表是通过如下一种方式进行分区的,每个分区包含那些分区表达式的值位于一个给定的连续区间内的行。这些区间要连续且不能相互重叠,使用VALUES LESS THAN操作符来进行定义。
上面的例子就是RANGE分区.
2)LIST分区:
MySQL中的LIST分区在很多方面类似于RANGE分区。和按照RANGE分区一样,每个分区必须明确定义。它们的主要区别在于,LIST分区中每个分区的定义和选择是基于某列的值从属于一个值列表集中的一个值,而RANGE分区是从属于一个连续区间值的集合。LIST分区通过使用“PARTITION BY LIST(expr)”来实现,其中“expr” 是某列值或一个基于某个列值、并返回一个整数值的表达式,然后通过“VALUES IN (value_list)”的方式来定义每个分区,其中“value_list”是一个通过逗号分隔的整数列表。
CREATE TABLE `T_list` ( `f_id` INT DEFAULT NULL, `f_name` VARCHAR (20) DEFAULT NULL, PRIMARY KEY (`f_id`) ) ENGINE = myisam DEFAULT CHARSET = utf8 PARTITION by list(f_id) ( PARTITION p0 VALUES in(1,2,3), ----区间值不能重复 PARTITION p1 VALUES in(4,5,6) );
3)HASH分区:
HASH分区主要用来确保数据在预先确定数目的分区中平均分布。在RANGE和LIST分区中,必须明确指定一个给定的列值或列值集合应该保存在哪个分区中;而在HASH分区中,MySQL 自动完成这些工作,你所要做的只是基于将要被哈希的列值指定一个列值或表达式,以及指定被分区的表将要被分割成的分区数量。要使用HASH分区来分割一个表,要在CREATE TABLE 语句上添加一个“PARTITION BY HASH (expr)”子句,其中“expr”是一个返回一个整数的表达式。它可以仅仅是字段类型为MySQL 整型的一列的名字。此外,你很可能需要在后面再添加一个“PARTITIONS num”子句,其中num 是一个非负的整数,它表示表将要被分割成分区的数量。
CREATE TABLE `T_hash` ( `f_id` INT DEFAULT NULL, `f_name` VARCHAR (20) DEFAULT NULL, PRIMARY KEY (`f_id`) ) ENGINE = myisam DEFAULT CHARSET = utf8 PARTITION BY HASH(f_id) ---可以指定多列 PARTITIONS 4;---分区个数
“expr”还可以是MySQL 中有效的任何函数或其他表达式,只要它们返回一个既非常数、也非随机数的整数。(换句话说,它既是变化的但又是确定的)。但是应当记住,每当插入或更新(或者可能删除)一行,这个表达式都要计算一次;这意味着非常复杂的表达式可能会引起性能问题,尤其是在执行同时影响大量行的运算(例如批量插入)的时候。最有效率的哈希函数是只对单个表列进行计算,并且它的值随列值进行一致地增大或减小,因为这考虑了在分区范围上的“修剪”。也就是说,表达式值和它所基于的列的值变化越接近,MySQL就可以越有效地使用该表达式来进行HASH分区。
4)LINEAR HASH分区:
MySQL还支持线性哈希功能,它与常规哈希的区别在于,线性哈希功能使用的一个线性的2的幂(powers-oftwo)运算法则,而常规 哈希使用的是求哈希函数值的模数。线性哈希分区和常规哈希分区在语法上的唯一区别在于,在“PARTITION BY” 子句中添加“LINEAR”关键字.
5)KEY分区:
按照KEY进行分区类似于按照HASH分区,除了HASH分区使用的用户定义的表达式,而KEY分区的 哈希函数是由MySQL 服务器提供。MySQL 簇(Cluster)使用函数MD5()来实现KEY分区;对于使用其他存储引擎的表,服务器使用其自己内部的 哈希函数,这些函数是基于与PASSWORD()一样的运算法则。
KEY分区的语法和HASH语法类似,只是把关键字改成KEY。
CREATE TABLE `T_key` ( `f_id` INT DEFAULT NULL, `f_name` VARCHAR (20) DEFAULT NULL, PRIMARY KEY (`f_id`) ) ENGINE = myisam DEFAULT CHARSET = utf8 PARTITION BY LINEAR key(f_id) PARTITIONS 3;
6)子分区:
子分区的意思就是在分区的基础上再次分区。且每个分区必须有相同个数的子分区。
CREATE TABLE `T_part` ( `f_id` INT DEFAULT NULL, `f_name` VARCHAR (20) DEFAULT NULL, PRIMARY KEY (`f_id`) ) PARTITION BY RANGE (f_id) SUBPARTITION BY HASH(F_ID) SUBPARTITIONS 2 ( PARTITION p0 VALUES less THAN (10), PARTITION p1 VALUES less THAN (20) )
上面语句的意思是,建立两个range分区,每个分区根据hash有分别有两个子分区,实际上整个表分成2×2=4个分区。当然,要详细定义每个分区属性也是可以的
CREATE TABLE `T_part` ( `f_id` INT DEFAULT NULL, `f_name` VARCHAR (20) DEFAULT NULL, PRIMARY KEY (`f_id`) ) PARTITION BY RANGE (f_id) SUBPARTITION BY HASH(F_ID) ( PARTITION p0 VALUES less THAN (10) ( SUBPARTITION s0 DATA DIRECTORY = '/disk0/data' INDEX DIRECTORY = '/disk0/idx', SUBPARTITION s1 DATA DIRECTORY = '/disk1/data' INDEX DIRECTORY = '/disk1/idx' ), PARTITION p1 VALUES less THAN (20) ( SUBPARTITION s2 DATA DIRECTORY = '/disk0/data' INDEX DIRECTORY = '/disk0/idx', SUBPARTITION s3 DATA DIRECTORY = '/disk1/data' INDEX DIRECTORY = '/disk1/idx' ) )
这样可以对每个分区指定具体存储磁盘。前提磁盘是存在的。
MySQL 中的分区在禁止空值(NULL)上没有进行处理,无论它是一个列值还是一个用户定义表达式的值。一般而言,在这种情况下MySQL 把NULL视为0。如果你希望回避这种做法,你应该在设计表时不允许空值;最可能的方法是,通过声明列“NOT NULL”来实现这一点。

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











MySQL에서 AVG 기능을 최적화하여 성능을 향상시키는 방법 MySQL은 많은 강력한 기능을 포함하는 널리 사용되는 관계형 데이터베이스 관리 시스템입니다. AVG 함수는 평균을 계산하는 데 널리 사용되지만 이 함수는 전체 데이터 세트를 순회해야 하기 때문에 대규모 데이터의 경우 성능 문제가 발생합니다. 이 글에서는 MySQL을 통해 AVG 기능을 최적화하여 성능을 향상시키는 방법을 자세히 소개합니다. 1. 인덱스 사용 인덱스는 MySQL 최적화에서 가장 중요한 부분입니다.

TokuDB 엔진 기반 MySQL 최적화: 쓰기 및 압축 성능 향상 소개: 일반적으로 사용되는 관계형 데이터베이스 관리 시스템인 MySQL은 빅 데이터 시대의 맥락에서 증가하는 쓰기 압력과 스토리지 요구 사항에 직면해 있습니다. 이러한 과제를 해결하기 위해 TokuDB 엔진이 탄생했습니다. 이 기사에서는 TokuDB 엔진을 사용하여 MySQL의 쓰기 성능 및 압축 성능을 향상시키는 방법을 소개합니다. 1. TokuDB 엔진이란 무엇입니까? TokuDB 엔진은 높은 쓰기를 처리하도록 설계된 빅데이터 중심 엔진입니다.

MySQL은 웹 애플리케이션 개발 및 데이터 저장에 일반적으로 사용되는 널리 사용되는 관계형 데이터베이스 관리 시스템입니다. 실제 애플리케이션에서는 MySQL의 기본 최적화가 특히 중요하며, 그 중 SQL 문의 고급 최적화는 데이터베이스 성능을 향상시키는 핵심입니다. 이 기사에서는 MySQL의 기본 최적화 구현을 위한 몇 가지 팁과 모범 사례는 물론 특정 코드 예제를 소개합니다. 쿼리 조건 결정 SQL 문을 작성할 때 먼저 쿼리 조건을 명확하게 정의하고 무제한 와일드카드 쿼리 사용을 피해야 합니다. 즉, 쿼리를 열 때 "%"를 사용하지 마십시오.

MySQL은 전자상거래 분야에서 널리 사용되는 관계형 데이터베이스 관리 시스템입니다. 전자상거래 애플리케이션에서는 MySQL을 최적화하고 보호하는 것이 중요합니다. 이 기사에서는 전자 상거래 애플리케이션에서 MySQL의 최적화 및 보안 프로젝트 경험을 분석합니다. 1. 성능 최적화 데이터베이스 아키텍처 설계: 전자상거래 애플리케이션에서는 데이터베이스 설계가 핵심입니다. 합리적인 테이블 구조 설계와 인덱스 설계로 데이터베이스의 쿼리 성능을 향상시킬 수 있습니다. 동시에 테이블 분할 및 파티셔닝 기술을 사용하면 단일 테이블의 데이터 양을 줄이고 쿼리 효율성을 높일 수 있습니다.

MySQL의 파티션 테이블을 사용하여 대용량 데이터에 대한 쿼리 작업을 최적화하는 방법 대용량 데이터를 처리할 때 데이터베이스 성능에 병목 현상이 발생하는 경우가 많습니다. 널리 사용되는 관계형 데이터베이스 관리 시스템인 MySQL은 대량의 데이터 쿼리 작업을 처리할 때 종종 성능 문제에 직면합니다. 데이터베이스 쿼리의 성능을 최적화하기 위해 MySQL은 테이블의 데이터를 여러 부분으로 나누어 서로 다른 물리적 파일에 저장할 수 있는 테이블 파티셔닝 기능을 제공합니다. 이 기사에서는 MySQL의 파티션 테이블을 사용하여 대용량 데이터 쿼리를 최적화하는 방법을 소개합니다.

MySQL 연결 번호 관리를 최적화하는 방법 MySQL은 다양한 웹사이트와 애플리케이션에서 널리 사용되는 인기 있는 관계형 데이터베이스 관리 시스템입니다. 실제 애플리케이션 프로세스에서 MySQL 연결 수 관리는 매우 중요한 문제이며, 특히 동시성이 높은 상황에서는 연결 수를 합리적으로 관리하면 시스템의 성능과 안정성을 향상시킬 수 있습니다. 이 기사에서는 자세한 코드 예제를 포함하여 MySQL 연결 번호 관리를 최적화하는 방법을 소개합니다. 1. 연결 수 관리 이해 MySQL에서 연결 수는 시스템이 동시에 연결할 수 있는 연결 수를 의미합니다.

MySQL의 이중 쓰기 버퍼링 기술을 올바르게 구성하고 최적화하는 방법 소개: MySQL의 이중 쓰기 버퍼링 기술은 데이터 보안과 성능을 향상시키는 중요한 기술입니다. 이 기사에서는 데이터를 더 잘 보호하고 데이터베이스 성능을 향상시키기 위해 MySQL의 이중 쓰기 버퍼링 기술을 올바르게 구성하고 최적화하는 방법을 소개합니다. 1. 이중 쓰기 버퍼링 기술이란 무엇입니까? 이중 쓰기 버퍼링 기술은 MySQL의 I/O 최적화 기술로, 디스크 I/O 작업 수를 크게 줄이고 데이터베이스의 쓰기 성능을 향상시킬 수 있습니다. MySQL이 쓰기 작업을 수행할 때 먼저

MySQL 데이터베이스는 일반적인 관계형 데이터베이스입니다. 데이터베이스의 데이터 양이 증가하고 쿼리 요구 사항이 변경됨에 따라 기본 최적화가 특히 중요해졌습니다. MySQL의 기본 최적화 과정에서 SQL 문 최적화는 중요한 작업입니다. 이 기사에서는 SQL 문 최적화를 위한 일반적인 기술과 원칙을 논의하고 특정 코드 예제를 제공합니다. 우선, SQL 문 최적화에서는 인덱스 최적화, 쿼리 문 최적화, 저장 프로시저 및 트리거 최적화 등의 측면을 고려해야 합니다. 이러한 측면에서 우리는
