Optimize MySQL performance for developers

1,545 views

Published on

Optimize MySQL performance for developers

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,545
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
54
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Optimize MySQL performance for developers

  1. 1. Optimize MySQL For Developers YangHaichao Senior MySQL DBA@SINA http://weibo.com/jackbillow QCon Beijing 2011
  2. 2. Agenda• Architecture of Database-related• Scaling your Database• Schema Design• Optimize Access
  3. 3. Performance vs Architecture
  4. 4. Datastore• Relational Databases • MySQL• Non Relational Databases • Memcached • Redis • MongoDB• RD and NRD is Friends or Foes? • MySQL + Memcached • MySQL + Redis
  5. 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. 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. 7. Scaling your database
  8. 8. Replication• Master - Slave • Only scaling reads• Master - Master • Scaling reads and writes but many limits
  9. 9. Functional SegmentationSegment databases into functional areas• User• Feed• Comment• Attention• Fans• …
  10. 10. Horizontal Split• Hash• Range• Lookup table• Middle layer
  11. 11. Minimize Database• No business logic• No distributed transactions• No joins and sorting
  12. 12. Schema Design
  13. 13. CAP & BASEConsistency: Oracle Availability ACID RAC (TotalTransactions Redundancy) NO GO NoSQL DB Partition Tolerance: Infinite scaleout
  14. 14. The Schema• Best stage for optimize performance• Improve performance is bigest• Divide and conquer• Normalize & de-normalize
  15. 15. Data type• Small is usually better• Use INT UNSIGNED for IPv4 addresses• Use TEXT or BLOB sparingly • Consider separate tables
  16. 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. 17. Storage Engine• Understanding benefits and drawbacks of each storage engine• Different storage engine has different index capability
  18. 18. Optimization Access
  19. 19. Thinking in Access• Any interaction with the database are the high cost• Decrease data access is better than SQL tuning
  20. 20. SQL is not C or C++
  21. 21. Reduce Access to data• Must specity column in select• Only use index in query• Assumsing success
  22. 22. Reduce the Number of Interactions• Pushing control structures into SQL• Combining statements• Fetching all you need at once
  23. 23. Reduce the Number of Interactions• INSERT ... ON DUPLICATE KEY UPDATE• REPLACE• INSERT IGNORE
  24. 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. 25. Parallelism• Reorganizing processing• Isolating hot spots• Shortening critical sections• Dealing with multiple queues
  26. 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. 27. Thank you for coming Q&A @jackbillow

×