Learn how to avoid common mistakes, drill down to understand the true performance impact, and measure performance gains from corrections. Practical examples on configuration, schema, application code changes. Real-life case studies show disk space reduction, increases in throughput, and reduced query execution times.

1. The Ideal Performance Architecture
The Ideal Performance Architecture
For MySQL System Architects
Ronald Bradford
Principal - 42SQL
Percona Performance Conference
April 2009
http://ronaldbradford.com
Version 0.1 2.Apr.2009

2. The Ideal Performance Architecture
Overview
http://ronaldbradford.com

3. The Ideal Performance Architecture
Overview
❖ Technology
❖ Disk
❖ Memory
❖ Indexes
❖ SQL
❖ Data
http://ronaldbradford.com

4. The Ideal Performance Architecture
Technology
http://ronaldbradford.com

5. The Ideal Performance Architecture
Know Your Technology Tools
❖ Generics are inefficient
❖ Product expertise in a different RDBMS is not
enough
❖ You have chosen MySQL
❖ Maximize it's strengths
❖ Minimize it's weaknesses
http://ronaldbradford.com

6. The Ideal Performance Architecture
Disk
http://ronaldbradford.com

7. The Ideal Performance Architecture
Know Your Disk Footprint
Disk = Memory = Performance
❖ Every single byte does count
http://ronaldbradford.com

8. The Ideal Performance Architecture
Poor Design is
❖ INT(1)‫‏‬
❖ BIGINT AUTO_INCREMENT
❖ no UNSIGNED used
❖ DECIMAL(31,0)‫‏‬
❖ VACHAR(255)
❖ All Nullable Columns
http://ronaldbradford.com

9. The Ideal Performance Architecture
30% saving
CREATE TABLE `searchtools_raw_term_domain_referrals_temp` (
`id` bigint(20) unsigned NOT NULL auto_increment,
`term_id` bigint(20) unsigned NOT NULL,
`domain_id` bigint(20) unsigned NOT NULL,
`referrals` int(10) unsigned NOT NULL,
`time` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `term_domain` (`term_id`,`domain_id`),
KEY `term_values` (`term_id`,`referrals`,`time`),
KEY `domain_values` (`domain_id`,`referrals`,`time`)
) ENGINE=MyISAM AUTO_INCREMENT=38890778 DEFAULT CHARSET=latin1;
❖ Converted BIGINT to INT
❖ Before: 1.2GB Data + 3.2GB Indexes
❖ After: 0.7GB Data + 2.2GB Indexes
❖ 33% Reduction
http://ronaldbradford.com

10. The Ideal Performance Architecture
60% saving
CREATE TABLE `dev_stats_0` (
`object` mediumint(3) unsigned NOT NULL default '0',
`date` date NOT NULL default '0000-00-00',
`time` time NOT NULL default '00:00:00',
`data` char(128) default NULL,
`ind` tinyint(5) unsigned NOT NULL default '0',
`normalized` tinyint(5) unsigned NOT NULL default '0',
PRIMARY KEY (`date`,`time`,`object`,`ind`),
KEY `normalized` (`normalized`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
❖ Converted CHAR(128) to CHAR(20)
❖ Before: 45GB After 18GB 60% Saving
❖ Schema had multiple occurrences
❖ 600+ GB significantly reduced
http://ronaldbradford.com

11. The Ideal Performance Architecture
84% saving
CREATE TABLE `client_table` (
`mid` decimal(31,0) NOT NULL default '0',
`sid` decimal(31,0) NOT NULL default '0',
`oid` decimal(31,0) NOT NULL default '0',
`nid` decimal(31,0) NOT NULL default '0',
`bid_status` varchar(30) default NULL,
UNIQUE KEY `pk_client_table` (`sid`,`nid`,`mid`,`oid`)
) TYPE=InnoDB;
❖ Converted DECIMAL(31,0) to INT UNSIGNED
❖ Before: 5.2GB After 850MB - 84%
❖ Schema had 77 occurrences
❖ Converted 1 of 12 shards
❖ Total: 7.8GB to 1.7GB (78% saving)
http://ronaldbradford.com

12. The Ideal Performance Architecture
Data Types
❖ INT(1) - 1 does not mean 1 digit
❖ (1) represents client output display format only
❖ INT is 4 Bytes, TINYINT is 1 Byte
❖ TINYINT UNSIGNED can store from 0 – 255
http://ronaldbradford.com

13. The Ideal Performance Architecture
Data Types
❖ BIGINT is not needed for AUTO_INCREMENT
❖ INT UNSIGNED stores 4.3 billion values
❖ You should be partitioning when at billions of rows
❖ BIGINT is applicable for some columns
❖ e.g. summation of values
http://ronaldbradford.com

14. The Ideal Performance Architecture
Memory
http://ronaldbradford.com

15. The Ideal Performance Architecture
Don't waste memory
❖ SELECT *
❖ utf8 for everything
❖ TEXT/BLOB
❖ large per session buffers
http://ronaldbradford.com

16. The Ideal Performance Architecture
Character Sets
❖ Default in MySQL 5 is utf8 (3 bytes)
❖ Only define columns that need utf8
❖ e.g. Not Codes, MD5 Value, web address
❖ MySQL internal buffers are fixed width
❖ e.g. VARCHAR(255) utf8 is 765 bytes to store just
1 byte
http://ronaldbradford.com

17. The Ideal Performance Architecture
Data Types
❖ VARCHAR(255) Is not a design practice
CREATE TABLE `XXX` (
`orderHandle` varchar(255) NOT NULL default '',
`personName` varchar(255) default NULL,
`addressLines` varchar(255) default NULL,
`city` varchar(255) default NULL,
`state` varchar(255) default NULL,
`postalCode` varchar(255) default NULL,
`countryCode` varchar(255) default NULL,
`phone` varchar(255) default NULL,
`email` varchar(255) default NULL,
`shipMethod` varchar(255) default NULL,
`shipTo` varchar(255) default NULL,
`receiveByDate` date default NULL,
`currency` varchar(3) default NULL,
`price` varchar(255) default NULL,
`flags` int(11) default '0',
`lastUpdateTime` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`creationTime` timestamp NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (`orderHandle`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8
http://ronaldbradford.com

18. The Ideal Performance Architecture
Be Wary of TEXT/BLOB
❖ Using SELECT *
❖ MySQL Internal Temporary table will force Temp
Disk Table
❖ Internal storage (e.g. Innodb)‫‏‬
❖ Stores first 768 bytes, then a separate 16k data
page per row per TEXT/BLOB field
http://ronaldbradford.com

19. The Ideal Performance Architecture
Indexes
http://ronaldbradford.com

20. The Ideal Performance Architecture
The Impact Of Indexes
❖ Good
❖ Dramatic performance improvements
❖ Improves memory usage
❖ Data Integrity
❖ Bad
❖ Slows performance for writes
❖ Wastes disk space for unused, duplicate or
ineffective indexes
❖ In-effective usage of memory
http://ronaldbradford.com

21. The Ideal Performance Architecture
Minimizing internal MySQL processing
❖ Correctly designed tables, indexes and SQL
can eliminate
❖ Using temporary table
❖ Using filesort
http://ronaldbradford.com

22. The Ideal Performance Architecture
Covering Indexes
❖ Understand how to use covering indexes
❖ Write efficient SQL
http://ronaldbradford.com

23. The Ideal Performance Architecture
SQL
http://ronaldbradford.com

24. The Ideal Performance Architecture
Know Every SQL Statement
❖ Developers don't write proper SQL statements
❖ SQL statements will directly affect your performance
❖ For Example
❖ Repeating SQL statements for no benefit
❖ 1000 very quick small unnecessary queries is worse
then 1 slow query
http://ronaldbradford.com

25. The Ideal Performance Architecture
Monitor Every SQL Statement
❖ Review Query Execution Plan (QEP)‫‏‬
❖ EXPLAIN
❖ Time queries
❖ Row Count / Affected rows
❖ Result Set Size
Review over time, things change
http://ronaldbradford.com

26. The Ideal Performance Architecture
Data
http://ronaldbradford.com

27. The Ideal Performance Architecture
Sharding
❖ Plan and implement from Day 1
❖ Find a good partition key
❖ Business Related
❖ Programmatically e.g. MOD (id,1000)
❖ Design for rebalancing support
❖ Virtual Host / Physical Host
http://ronaldbradford.com

28. The Ideal Performance Architecture
Data Availability
❖ Messaging system for data availability
❖ Read/Write availability
❖ Read Availability
❖ Support at table level
❖ Support at table partitions
❖ e.g. by PK id range
http://ronaldbradford.com

29. The Ideal Performance Architecture
Write Once Data
❖ Separate your online and archival data
❖ Reduces backup/recovery time
❖ Enables data synchronization
❖ including MySQL to non-MySQL
http://ronaldbradford.com

30. The Ideal Performance Architecture
Professional Help is Available
❖ Two decades IT expertise
❖ 10 years in MySQL
❖ System/Data Architecture
❖ Database Performance and Tuning
❖ High Availability and Scalability
❖ Education and Training
http://ronaldbradford.com
http://ronaldbradford.com