MySQL Partitioning

Partitioning in MySQL 5.
1
and onwards
Dr. Mikael Ronström, Senior Software Architect

MySQL AB
mikael@mysql.com
Copyright 2005 MySQL AB The World’s Most Popular Open Source Database 1
Why Partitioning?
• For Large Tables:

• ”Divide and Conquer”
• Easier maintenance
• Performance improvement for queries
• Control data placement on disk devices
• Control data placement on Cluster nodes
• Preparatory step for Parallel Queries
Partitioned Tables
• Partitioned Tables are standard MySQL tables

– Can be part of all constructs where tables are
used
– Complex select queries, Stored Procedures,
Triggers, Views
• Easy to ALTER TABLE into partitioned table
– Syntax from CREATE TABLE can also be used
in ALTER TABLE
• Easy to drop partitioning on a table
– ALTER TABLE t1 REMOVE PARTITIONING;
Partition Management
• Fast Deletion of entire parts of a table

• Fast reorganisation of one part of a table
• Fast reorganisation of partition boundaries
• Fast adding of new partitions
• Fast split/merge of partitions
MySQL Partitioning Types
• Range Partitioning
• List Partitioning
• Hash Partitioning
• Composite Partitioning
Storage Engines
• Partition applies to all storage engines
– MyISAM
– InnoDB
– Archive
– NDB Cluster
– Falcon
• Exceptions
– Merge
• Don’t mix storage engines in one table for now (5.1 limitation)
– Example:
– Archive Engine for really old data (> 10 years)
– MyISAM for medium old data (> 1 year)
– InnoDB for current data
Key Partitioning
• Definition
– Same as Hash partitioning except that MySQL
decides the hash function using the given fields
• Benefits
– Very good hash function
– Tight integration with MySQL Cluster partitioning
• Drawbacks
– Same as for Hash partitioning
LINEAR HASH/KEY partitioning
• The normal HASH/KEY uses a modulo function to

spread records => Even distribution of data among
partitions
• Also leads to full rebuild of table for ADD/COALESCE
Partition
• LINEAR HASH/KEY partitions use an algorithm based
on linear hashing which means that some partitions will
have twice as much data as others if the number of
partitions is not on the form 2 ^ n
• LINEAR HASH/KEY only requires rebuild of a number
of the partitions, thus faster partition management at
the cost of a slight imbalance
Partition Function
• PARTITION BY RANGE(f(f1,f2,f3))
• Partition function must always deliver integer result
(5.1 limitation)
• Partition function can contain any number of fields, but
must contain at least one field
• If primary key is defined, no fields outside of primary
key is allowed in partition function
• Partition function can contain a large variety of
character functions, date functions and mathematical
functions
• If unique key is defined on a table, no fields outside of
unique key is allowed in partition function (this
limitation does not exist for tables in MySQL Cluster)
Partition Options
MAX_ROWS
MIN_ROWS
NODEGROUP (only MySQL Cluster)
DATA DIRECTORY (only MyISAM)
INDEX DIRECTORY (only MyISAM)
COMMENT
INFORMATION SCHEMA for
Partitioning
• Provides information of:
– Partition names
– Where partitions are stored
– Information about partition types
– Information about partition functions
– Number of rows per partition
– Average row length in partitions
– Other attributes of partitions (timestamps, …)
• Support SHOW CREATE TABLE
• Support SHOW TABLE STATUS
– Will be displayed as Create option PARTITIONED
EXPLAIN for queries using
Partitioned Tables
• Explains which partitions will be actually scanned in a

query
– Gives you everything that EXPLAIN provides
– Plus a list of partition names used in the query
• Use EXPLAIN PARTITIONS to understand:
– How partition pruning affects the query
– Which indexes are used
• might be affected by partitioning
– If there is a better partitioning strategy
Partition Management
• ALTER TABLE t1 DROP PARTITION p0;

• ALTER TABLE t1 ADD PARTITION (PARTITION p1);
• ALTER TABLE t1 REORGANIZE PARTITION ….;
• ALTER TABLE t1 COALESCE PARTITION 1;
• ALTER TABLE t1 REBUILD PARTITION p0;
• ALTER TABLE t1 OPTIMIZE PARTITION p0;
• ALTER TABLE t1 CHECK PARTITION p0;
• ALTER TABLE t1 ANALYZE PARTITION p0;
• ALTER TABLE t1 REPAIR PARTITION p0;
• ALTER TABLE t1 TRUNCATE PARTITION p0;
Drop RANGE/LIST Partition
ALTER TABLE t1 DROP PARTITION 2002
2002 2003 2004 2005
Add RANGE/LIST Partition
ALTER TABLE t1 ADD PARTITION (PARTITION 2006 VALUES IN (2006));
2003 2004 2005 20062006
ADD HASH/KEY partition(s)
ALTER TABLE t1 ADD PARTITION (PARTITION p4);
Old Partitions
p1 p2 p3
p1 p2 p3 p4
New Partitions
ADD LINEAR HASH/KEY
partition(s)
ALTER TABLE t1 ADD PARTITION (PARTITION p4);
Old Partitions
p1 p2 p3
p2 p4 New Partitions
COALESCE HASH/KEY partition(s)
ALTER TABLE t1 COALESCE PARTITION 1;
Old Partitions
p1 p2 p3 p4
p1 p2 p3 New Partitions
COALESCE LINEAR HASH/KEY
partition(s)
ALTER TABLE t1 COALESCE PARTITION 1;
Old Partitions
p1 p2 p3 p4
p2 New Partitions
Using REORGANIZE partition to
SPLIT a partition
ALTER TABLE t1 REORGANIZE PARTITION 2006_2007 INTO
(PARTITION 2006 VALUES LESS THAN (2007),
PARTITION 2007 VALUES LESS THAN (2008));
Before_2002 2002_2003 2004_2005 2006_2007
2006 2007
MERGE partitions
ALTER TABLE t1 REORGANIZE PARTITION 2006,2007 INTO
(PARTITION 2006_2007 VALUES LESS THAN (2008));
Before_2004 2004_2005 2006 2007
2006_2007
balance partitions
ALTER TABLE t1 REORGANIZE PARTITION 2006_Q1,2006_Q2 INTO
(PARTITION 2006_M1_4 VALUES LESS THAN (DATE(’2006-05-01’),
PARTITION 2006_M_5_8 VALUES LESS THAN (DATE(’2006-09-01’));
Before_2004 2005 2006_Q1 2006-Q2
2006_M_1_4 2006_M_5_8
Using REORGANIZE partition to move
partitions to new disk device
ALTER TABLE t1 REORGANIZE PARTITION 2006 INTO
(PARTITION 2006 DATA DIRECTORY ’/home/user/2006/data_file’
INDEX DIRECTORY ’/home/user/2006/index_file’ VALUES LESS THAN (2007));
Before_2004 2005 2006 2007
2006
Using REBUILD partition to recreate
partition
ALTER TABLE t1 REBUILD PARTITION 2006;
Before_2004 2005 2006 2007
2006
Partition Pruning
• Only scan needed partitions

– Range optimisations for single-field function, YEAR(date) and
DATE_TO_DAYS(date) functions (RANGE partitioning)
– Range optimisations for all LIST/HASH/KEY partitions
• Best use case:
– Full table scans on non-indexed fields
• Example:
– CREATE TABLE t1 (a int, index(a)) PARTITION BY HASH (a)
partitions 4;
– CREATE TABLE t2 (a int, index(a));
Partition Pruning
SELECT * FROM Cars Where PRICE > 9000
8000-TSU564-1988 7000-SAG293-2004 12000-FBI007-2004

1000-YUK333-1981
11000-YRG213-2005 21100-GRO293-1956
34000-SIE568-2004
13000-KAR365-2001 8500-KHO297-2004
Results
Price
>9000
Partition Pruning
Select *FROM Cars Where PRICE >9000
and COLOR= Red
8000-TSU564-1988 7000-SAG293-2004 12000-FBI007-2004
1000-YUK333-1981
11000-YRG213-2005 21100-GRO293-1956
34000-SIE568-2004
13000-KAR365-2001 8500-KHO297-2004
Results
Price
>9000
Dynamic Partitioning Pruning
SELECT * FROM t1, t2 WHERE t2.a = t1.a;
If t1 is inner loop it is possible to select only one partition in

each of its scan (one scan per record in outer table t2).
If t1 is outer loop it has to scan all partitions.
Explanation: This works since there is an index on ‘a’

that contains all partitioning fields and this is bound
for each scan in inner loop
Partitioning and NULL values
• NULL values are allowed in partitioning fields

• If a partitioning function is evaluated where one field is
NULL the result of the partitioning will be the smallest
integer
• This also holds for VALUES IN (NULL) in List partitioned
tables
• VALUES LESS THAN (NULL) is not allowed
• VALUES LESS THAN MAXVALUE will include all
integers upto the biggest integer
Partititioning Implementation
TABLE t1 (Abstract table,

frm-file for t1 exists,
Implemented by
Partition handler)
Partition p1
Handler Table
(no frm for partitions)
MyISAM/
InnoDB/
Federated/
…..
index_read Algorithm
Handler output
Merge Sort
Part
Sorted Sorted Sorted Sorted

Output stream Output stream Output stream Output stream
From Partition 1 From Partition 2 From Partition 3 From Partition 4
Insert in Partitioning Table
YELLOW GREEN RED BLUE
Insert
GOX 123 $ 3000 2001 YELLOW
Updating Partition
Yellow Blue Red Green
Delete Insert
GOX 123 $ 3000 2001 Yellow
GOX 123 $ 3000 2001 Green
Partitioning for MySQL Cluster
• Default for MySQL Cluster:
– All tables in MySQL Cluster are partitioned
– Default for an ENGINE=NDB is PARTITION BY KEY()
• User Defined Partitioning for MySQL Cluster
– Supports same partitioning types as rest of MySQL (Beta using –new)
– PARTITION BY KEY is fully integrated with NDB kernel
– Partitions defined in MySQL mapped to partitions in NDB storage
engine, thus no extra overhead for many partitions
– Partitioning makes manual placement of partitions possible
• NOTE:
– No support for DROP PARTITION
– Full table copy is always employed for Partition Management
• Locks entire table (=> not on-line)
• More memory resources used
• More processing resources
Cluster: Partitioning Controls
Physical Distribution
• Accessing relevant partitions only (partition pruning) for a query
optimizes communication costs
• A table no longer has to be distributed on all nodes
• Altering the table partitioning can change the physical
distribution
– Altering table partitioning is currently done as a copying
ALTER TABLE
• Node groups can be populated on-line
– ALTER TABLE account
ADD PARTITION (PARTITION P2 NODEGROUP 2)
– With future support for adding nodes (node groups) on-
line, tables can be re-partitioned to populate the added
nodes
Cluster: Partition by Key
CREATE TABLE service(user int unsigned,
service varchar,
parameter
int)
PRIMARY KEY (user, service)
PARTITION BY KEY (user)
ENGINE=NDBCLUSTER;
• PARTITION BY KEY enables us to place all user records

from all tables in the same node group
– Better locality of access for transactions towards a particular user
• Default number of partitions in MySQL Cluster == Number
of nodes in cluster
Cluster: Default Tables
• ENGINE=NDB is translated to PARTITION BY KEY()

ENGINE=NDB
– PARTITION BY KEY() means by fields in primary key
• if no primary key exists it means by Hidden Key
– a unique identifier generated by MySQL for tables
without primary keys in MySQL Cluster
– PARTITION BY KEY() can be used also for non-clustered tables
• Only partition by primary key (no hidden key stuff)
• Default number of partitions for non-clustered partitioned
tables is 1
Backup and Restore for partitioned
tables in MySQL Cluster
SCENARIO DESCRIPTION:
• Backup taken in cluster with 4 node groups
• Restore performed in cluster with 2 node groups
• Assume table manually partitioned to be in node group 0
and 3
• What can be done for the partition in node group 3?
• For mysqldump and Cluster Replication the table must
be created by the user before applying the user
records/binlog
Nodegroup maps for ndb_restore
• Using ndb_restore it is possible to specify a mapping

between node groups as specified in backup and the
node groups set up by the restore program.
• Use parameter --ndb-nodegroup-map ’(3,1)(2,0)’
• It needs a list of mappings from old nodegroup to new
nodegroup
• An old nodegroup map can be mapped to more than one
nodegroup, in that case mappings are done on a round
robin basis for those partitions
• Tables that haven’t explicitly set a nodegroup is not
affected by this mapping
Future Roadmap
• Global Indexes
– Unique indexes fully supported
• Foreign Key support
• Import/Export Partitions to/from other tables
• Even more on-line changes
• Optimised locking/opening of tables
– Better performance
• Mix storage engines in one table
– Example:
– Archive Engine for really old data (> 10 years)
– MyISAM for medium old data (> 1 year)
– InnoDB for current data
• Enable queries on ”broken” tables
– Query even when a partition is not available
Partitioning Limitations (5.1)
• Partitioning Function must return integer result

• All partitions must use the same Storage Engine (with
same options)
• Use of a partitioned table => open all partitions
⇒Increases response time for partitioned tables with many
partitions (execution overhead very little)
• Foreign Keys support is not available for partitioned tables
(on the roadmap for future release)
More information on Partitioning
• Documentation
– http://dev.mysql.com/doc/refman/5.1/en/partitioni
ng.html
• Blog
– http://mikaelronstrom.blogspot.com
• Forums
– http://forums.mysql.com/list.php?106
Thank You!
Senior Software Architect

Dr. Mikael Ronström
MySQL AB
mikael@mysql.com

MySQL Partitioning

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MySQL Partitioning

Uploaded by

Copyright:

Available Formats

Partitioning in MySQL 5.

Dr. Mikael Ronström, Senior Software Architect

• For Large Tables:

• Partitioned Tables are standard MySQL tables

• Fast Deletion of entire parts of a table

• The normal HASH/KEY uses a modulo function to

• Explains which partitions will be actually scanned in a

• ALTER TABLE t1 DROP PARTITION p0;

ALTER TABLE t1 DROP PARTITION 2002

2002 2003 2004 2005

ALTER TABLE t1 ADD PARTITION (PARTITION 2006 VALUES IN (2006));

2003 2004 2005 20062006

ALTER TABLE t1 COALESCE PARTITION 1;

Before_2002 2002_2003 2004_2005 2006_2007

Before_2004 2004_2005 2006 2007

Before_2004 2005 2006_Q1 2006-Q2

Before_2004 2005 2006 2007

Before_2004 2005 2006 2007

• Only scan needed partitions

8000-TSU564-1988 7000-SAG293-2004 12000-FBI007-2004

If t1 is inner loop it is possible to select only one partition in

If t1 is outer loop it has to scan all partitions.

Explanation: This works since there is an index on ‘a’

• NULL values are allowed in partitioning fields

TABLE t1 (Abstract table,

Sorted Sorted Sorted Sorted

YELLOW GREEN RED BLUE

GOX 123 $ 3000 2001 YELLOW

Yellow Blue Red Green

GOX 123 $ 3000 2001 Yellow

GOX 123 $ 3000 2001 Green

• PARTITION BY KEY enables us to place all user records

• ENGINE=NDB is translated to PARTITION BY KEY()

• Using ndb_restore it is possible to specify a mapping

• Partitioning Function must return integer result

Senior Software Architect

You might also like