Optimize MySQL For Developers-Qcon2011

  • 625 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
625
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
15
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 SegmentationSegment 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 & BASEConsistency: Oracle Availability ACID RAC (TotalTransactions 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