Optimize MySQL For Developers

QCon Beijing 2011

YangHaichao

Senior MySQL DBA@SINA

http://weibo.com/jackbillow

Agenda

• Architecture of Database-related

• Scaling your Database

• Schema Design

• Optimize Access

Performance vs Architecture

Datastore

• Relational Databases• MySQL

• Non Relational Databases• Memcached

• Redis

• MongoDB

• RD and NRD is Friends or Foes?

• MySQL + Memcached

• MySQL + Redis

Caching

• Put a cache in front of your database• Distribute

• Write-through for scaling reads

• Write-back for scaling reads and writes

• Cache tier

Principles

• Nothing’s perfect but some solutions are

good enough for a while

• Scalability involve partitioning, indexing and

replication

• All data for real-time queries MUST be in

memory. Disk is for writes only

Scaling your database

Replication

• Master - Slave• Only scaling reads

• Master - Master• Scaling reads and writes but many limits

Functional Segmentation

Segment databases into functional areas

• User

• Feed

• Comment

• Attention

• Fans

• …

Horizontal Split

• Hash

• Range

• Lookup table

• Middle layer

Minimize Database

• No business logic

• No distributed transactions

• No joins and sorting

Schema Design

CAP & BASE

Consistency：ACID

Transactions

Availability

(Total

Redundancy)

Partition

Tolerance:

Infinite scaleout

Oracle

RAC

NO

GO

NoSQL

DB

The Schema

• Best stage for optimize performance

• Improve performance is bigest

• Divide and conquer

• Normalize & de-normalize

Data type

• Small is usually better

• Use INT UNSIGNED for IPv4 addresses

• Use TEXT or BLOB sparingly• Consider separate tables

Index

• Over indexing can be an overhead

• On multiple column indexes the order fields

within the index definition is important

• Poor indexes are same as not having any

indexes

• Good selectivity on index fields

Storage Engine

• Understanding benefits and drawbacks of

each storage engine

• Different storage engine has different index

capability

Optimization Access

Thinking in Access

• Any interaction with the database are the

high cost

• Decrease data access is better than SQL

tuning

SQL is not C or C++

Reduce Access to data

• Must specity column in select

• Only use index in query

• Assumsing success

Reduce the Number of Interactions

• Pushing control structures into SQL

• Combining statements

• Fetching all you need at once

Reduce the Number of Interactions

• INSERT ... ON DUPLICATE KEY UPDATE

• REPLACE

• INSERT IGNORE

Reduce CPU computing

• Extensive use of prepared statements and

bind variables

• Column not calculate as far as possible

• Move cpu-intensive work to application

Parallelism

• Reorganizing processing

• Isolating hot spots

• Shortening critical sections

• Dealing with multiple queues

Last, but not least…

• Architecture and design is in the best stages

of improving performance

• Develop huge application you mush keep

scaling data in mind at first

• Perform SQL in very few data accesses is

increasingly important

• Performance tuning is an trade-off and

iterative process

Thank you for coming

Q & A

@jackbillow