LOCK_thread_count is currently (after improvements in WL#6606) a major bottleneck when connecting/disconnecting clients. This mutex protects several independent structures/variables. It can therefore be split into several mutexes, each protecting a separate structure/variable. This should give clear performance improvements. A draft patch has shown ~50% improvement for clients doing connect + 1 query + disconnect. User Documentation ================== http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-3.html
Changes to the interface specification: I-1: The following status variables will no longer be visible in embedded server where they never had any effect: Aborted_connects, Connection_errors_accept, Connection_errors_internal, Connection_errors_max_connections, Connection_errors_peer_address, Connection_errors_select, Connection_errors_tcpwrap No other changes to behavior (except improved performance) or interfaces.
LOCK_thread_count should be split into: 1: LOCK_thread_count - protecting the list of connections 2: LOCK_thread_cache - protecting the "thread cache" for the per-thread connection handler. 3: LOCK_thread_id - protecting the thread_id global counter. (This could be implemented with atomics rather than mutex) Also consider if LOCK_thread_count usage in replication code could be reduced.