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