Optimize MySQL performance for developers
3 likes688 views
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.
Optimize MySQL performance for developers
- 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
- 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
- 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
- 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