Optimize MySQL For Developers

YangHaichao Senior MySQL DBA@SINA http://weibo.com/jackbillow

QCon Beijing 2011

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
Nothings 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

Oracle RAC NO GO

Availability (Total Redundancy)

NoSQL DB

Partition Tolerance: Infinite scaleout

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

 20111020~22
www.qconhangzhou.com6

QCon
www.qconbeijing.com