This document provides an overview of optimizing MySQL for developers. It discusses database architecture options like relational and non-relational databases. It also covers caching, scaling through replication and functional segmentation, and optimizing schemas through normalization. The document emphasizes minimizing data access in applications by reducing the number of interactions with the database through techniques like prepared statements. It concludes that architectural design and minimizing data access are key to improving database performance.

1. Optimize MySQL For Developers
YangHaichao
Senior MySQL DBA@SINA
http://weibo.com/jackbillow
QCon Beijing 2011

2. Agenda
• Architecture of Database-related
• Scaling your Database
• Schema Design
• Optimize Access

3. Performance vs Architecture

4. Datastore
• Relational Databases
• MySQL
• Non Relational Databases
• Memcached
• Redis
• MongoDB
• RD and NRD is Friends or Foes?
• MySQL + Memcached
• MySQL + Redis

5. 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. 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

7. Scaling your database

8. Replication
• Master - Slave
• Only scaling reads
• Master - Master
• Scaling reads and writes but many limits

9. Functional Segmentation
Segment databases into functional areas
• User
• Feed
• Comment
• Attention
• Fans
• …

10. Horizontal Split
• Hash
• Range
• Lookup table
• Middle layer

11. Minimize Database
• No business logic
• No distributed transactions
• No joins and sorting

12. Schema Design

13. CAP & BASE
Consistency： Oracle Availability
ACID RAC (Total
Transactions Redundancy)
NO
GO
NoSQL
DB
Partition
Tolerance:
Infinite scaleout

14. The Schema
• Best stage for optimize performance
• Improve performance is bigest
• Divide and conquer
• Normalize & de-normalize

15. Data type
• Small is usually better
• Use INT UNSIGNED for IPv4 addresses
• Use TEXT or BLOB sparingly
• Consider separate tables

16. 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

17. Storage Engine
• Understanding benefits and drawbacks of
each storage engine
• Different storage engine has different index
capability

18. Optimization Access

19. Thinking in Access
• Any interaction with the database are the
high cost
• Decrease data access is better than SQL
tuning

20. SQL is not C or C++

21. Reduce Access to data
• Must specity column in select
• Only use index in query
• Assumsing success

22. Reduce the Number of Interactions
• Pushing control structures into SQL
• Combining statements
• Fetching all you need at once

23. Reduce the Number of Interactions
• INSERT ... ON DUPLICATE KEY UPDATE
• REPLACE
• INSERT IGNORE

24. Reduce CPU computing
• Extensive use of prepared statements and
bind variables
• Column not calculate as far as possible
• Move cpu-intensive work to application

25. Parallelism
• Reorganizing processing
• Isolating hot spots
• Shortening critical sections
• Dealing with multiple queues

26. 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

27. Thank you for coming
Q&A
@jackbillow