sina web yanghaichao qcon

7/30/2019 Sina Web Yanghaichao Qcon

1/28

Optimize MySQL For Developers

QCon Beijing 2011

YangHaichao

Senior MySQL DBA@SINAhttp://weibo.com/jackbillow


2/28

Agenda

Architecture of Database-related

Scaling your Database

Schema Design Optimize Access


3/28

Performance vs Architecture


4/28

Datastore

Relational Databases MySQL

Non Relational Databases Memcached Redis

MongoDB

RD and NRD is Friends or Foes? MySQL + Memcached

MySQL + Redis


5/28

Caching

Put a cache in front of your database Distribute

Write-through for scaling reads

Write-back for scaling reads and writes Cache tier


6/28

Principles

Nothings perfect but some solutions are

good enough for a while

Scalability involve partitioning, indexing andreplication

All data for real-time queries MUST be inmemory. Disk is for writes only


7/28

Scaling your database


8/28

Replication

Master - Slave Only scaling reads

Master - Master Scaling reads and writes but many limits


9/28

Functional Segmentation

Segment databases into functional areas

User

Feed Comment

Attention

Fans


10/28

Horizontal Split

Hash

Range

Lookup table Middle layer


11/28

Minimize Database

No business logic

No distributed transactions

No joins and sorting


12/28

Schema Design


13/28

CAP & BASE

Consistency

ACID

Transactions

Availability

(Total

Redundancy)

Partition

Tolerance:

Infinite scaleout

Oracle

RAC

NO

GO

NoSQL

DB


14/28

The Schema

Best stage for optimize performance

Improve performance is bigest

Divide and conquer Normalize & de-normalize


15/28

Data type

Small is usually better

Use INT UNSIGNED for IPv4 addresses

Use TEXT or BLOB sparingly Consider separate tables


16/28

Index

Over indexing can be an overhead

On multiple column indexes the order fieldswithin the index definition is important

Poor indexes are same as not having anyindexes

Good selectivity on index fields


17/28

Storage Engine

Understanding benefits and drawbacks ofeach storage engine

Different storage engine has different indexcapability


18/28

Optimization Access


19/28

Thinking in Access

Any interaction with the database are thehigh cost

Decrease data access is better than SQL

tuning


20/28

SQL is not C or C++


21/28

Reduce Access to data

Must specity column in select

Only use index in query

Assumsing success


22/28

Reduce the Number of Interactions

Pushing control structures into SQL

Combining statements

Fetching all you need at once


23/28

Reduce the Number of Interactions

INSERT ... ON DUPLICATE KEY UPDATE

REPLACE

INSERT IGNORE


24/28

Reduce CPU computing

Extensive use of prepared statements andbind variables

Column not calculate as far as possible

Move cpu-intensive work to application


25/28

Parallelism

Reorganizing processing

Isolating hot spots

Shortening critical sections Dealing with multiple queues


26/28

Last, but not least

Architecture and design is in the best stagesof improving performance

Develop huge application you mush keep

scaling data in mind at first

Perform SQL in very few data accesses isincreasingly important

Performance tuning is an trade-off anditerative process


27/28

Thank you for coming

Q & A

@jackbillow


28/28

20111020~22www.qconhangzhou.com6

QConwww.qconbeijing.com
http://www.qconbeijing.com/http://www.qconbeijing.com/

sina web yanghaichao qcon

Documents