Is performance_schema worth the overhead?
3 April 4:30PM - 5:20PM @ Ballroom G
50 minutes conference
Now that performance_schema is enabled by default in MySQL 5.6 a lot more people will be using it. Although performance_schema has a lot of potential value, it's also very complex and has performance overhead. If you're already squeezing every possible ounce of performance out of MySQL you may just disable it to avoid the overhead of instrumentation. But what about the rest of us? Should we leave it enabled? If so, what level of instrumentation should we use? Must it be enabled in production, or is it good enough just to use it in a test environment? In this session I will move beyond the hype and the criticism to help you decide if the overhead of performance_schema is worth it for you. I will start by defining the core terminology of performance_schema such as instruments, consumers, timers, and event filtering. I'll show you how to use a scaled down level of instrumentation to minimize the overhead, and then work my way up with specific examples of how and why to enable more instrumentation. I will use sample queries to illustrate the data being captured and how it can be used to help improve MySQL database performance.
Database Architect, Flite
Ike Walker is the Database Architect at Flite where he is responsible for multiple data stores including MySQL, Redis, and Hive. He has 16 years of experience with relational databases, and has been working with MySQL since 2006. Ike is an active blogger at mechanics.flite.com, runs the Boston MySQL meetup, and holds a gold badge for mysql on stackoverflow.com.