I tested with the same PXC operator version 1.18 (8.0.42) and can confirm i am also seeing the similar behaviour.
mysql> select * from performance_schema.mutex_instances where name like '%LOCK_ticket_store_ops%';
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281468668736648 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281468668736648 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281469943693784 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281468872300936 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281468668736648 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281469943693784 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281469943693784 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281469943693784 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281468872300936 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281468668736648 | NULL |
+--------------------------------------------------------------+-----------------------+---------------------+
1224 rows in set (0.00 sec)
…
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281468872300936 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281468668736648 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281469943693784 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281469943693784 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281469943693784 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281468872300936 | NULL |
| wait/synch/mutex/sql/MDL_ticket_store::LOCK_ticket_store_ops | 281468668736648 | NULL |
+--------------------------------------------------------------+-----------------------+---------------------+
1237 rows in set (0.00 sec)
This seems to part of a health check where the session connects and monitor the cluster node. Are you facing any issues/challenges due to this ?
mysql> show processlist;
+------+----------------------+--------------------------------------------------------------------------+------+---------+------+--------------------------+------------------+---------+-----------+---------------+
| Id | User | Host | db | Command | Time | State | Info | Time_ms | Rows_sent | Rows_examined |
+------+----------------------+--------------------------------------------------------------------------+------+---------+------+--------------------------+------------------+---------+-----------+---------------+
| 1 | system user | | NULL | Sleep | 1094 | wsrep: aborter idle | NULL | 1093398 | 0 | 0 |
| 2 | system user | | NULL | Sleep | 1094 | innobase_commit_low (-1) | NULL | 1093398 | 0 | 0 |
| 8 | event_scheduler | localhost | NULL | Daemon | 1094 | Waiting on empty queue | NULL | 1093148 | 0 | 0 |
| 11 | system user | | NULL | Sleep | 1094 | wsrep: applier idle | NULL | 1093142 | 0 | 0 |
| 480 | root | cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local:52740 | NULL | Query | 0 | init | show processlist | 0 | 0 | 0 |
**| 2223 | unauthenticated user | cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local:46356 | NULL | Connect | 0 | login | NULL | 42 | 0 | 0 |**
+------+----------------------+--------------------------------------------------------------------------+------+---------+------+--------------------------+------------------+---------+-----------+---------------+
6 rows in set, 1 warning (0.00 sec)
If you enable the general/audit logs you can see the exact connection details which keeps increasing as well. So this is part of internal process inside pxc operator.
|2025-11-14T12:52:31.003087Z| 4163 Connect|monitor@cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local on using SSL/TLS|
|---|---|---|
|2025-11-14T12:52:32.042272Z| 4164 Connect|monitor@cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local on using SSL/TLS|
|2025-11-14T12:52:33.591304Z| 4167 Query|SELECT User_attributes FROM mysql.user WHERE user='monitor'|
|2025-11-14T12:52:34.467195Z| 4170 Connect|monitor@cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local on using SSL/TLS|
|2025-11-14T12:52:34.612264Z| 4171 Connect|monitor@cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local on mysql using SSL/TLS|
|2025-11-14T12:52:35.004880Z| 4174 Connect|monitor@cluster1-pxc-0.cluster1-pxc.pxc-operator.svc.cluster.local on using SSL/TLS|
|2025-11-14T12:52:35.012697Z| 4175 Connect|monitor@cluster1-pxc-0.cluster1-pxc.pxc-operator.svc.cluster.local on using SSL/TLS|
|2025-11-14T12:52:35.994163Z| 4176 Connect|monitor@cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local on using SSL/TLS|
|2025-11-14T12:52:35.995179Z| 4177 Connect|monitor@cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local on using SSL/TLS|
|2025-11-14T12:52:37.228619Z| 4178 Connect|monitor@cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local on using SSL/TLS|
|2025-11-14T12:52:39.663399Z| 4181 Query|SELECT User_attributes FROM mysql.user WHERE user='monitor'|
|2025-11-14T12:52:39.756715Z| 4184 Connect|monitor@cluster1-haproxy-0.cluster1-haproxy.pxc-operator.svc.cluster.local on using SSL/TLS|