You are investigating the performance of the server and see this information: events_waits_summary_global_by_event_name in the Performance Schema shows that the…

Question

Options

• AIncrease the value of table_open_cache_instances.
• BDecrease the value of table_definition_cache.
• CDecrease the value of table_open_cache.
• DIncrease the value of table_definition_cache.
• EIncrease the value of table_open_cache.
• FDecrease the value of table_open_cache_instances.

• A
  75% (18)
• B
  13% (3)
• C
  8% (2)
• D
  4% (1)

Explanation

Option A is correct because the bottleneck is mutex contention on the single table open cache lock - many threads are queuing to acquire LOCK_table_cache_event. Increasing table_open_cache_instances partitions the cache into multiple segments, each with its own mutex, distributing contention across them and eliminating the bottleneck.

Why the distractors are wrong:

• E (increase table_open_cache): The cache size isn't the problem - table_open_cache_overflows = 0 proves the cache is not too small, so adding capacity won't reduce lock contention.
• C (decrease table_open_cache): Making the cache smaller would increase evictions and potentially worsen performance.
• D/B (table_definition_cache): This variable controls caching of table definitions (metadata), which uses a completely different lock - it has no effect on LOCK_table_cache_event.
• F (decrease table_open_cache_instances): Fewer partitions means more threads compete for fewer mutexes - the exact opposite of what's needed.

Memory tip: Think of table_open_cache_instances like checkout lanes at a store - more lanes (instances) means shorter lines (less mutex wait). The zero-overflow clue is your signal to rule out cache size solutions and focus on cache concurrency instead.

No community discussion yet for this question.