| use_slave | 
         The semantics of this statistic has changed between 1.0.1 - 1.1.0.
        
         The meaning for version 1.0.1 is as follows.
         Number of statements considered as read-only by the built-in query analyzer.
         Neither statements which begin with a SQL hint to force
         use of slave nor statements directed to a slave by an user-defined
         callback are included. The total number of statements sent to the slaves is
         use_slave + use_slave_sql_hint +
         use_slave_callback.
         
         PECL/mysqlnd_ms 1.1.0 introduces a new concept of chained filters. The
         statistics is now set by the internal load balancing filter. With
         version 1.1.0 the load balancing filter is always the last in the
         filter chain, if used. In future versions a load balancing filter may be
         followed by other filters causing another change in the meaning of
         the statistic. If, in the future, a load balancing filter is followed
         by another filter it is no longer guaranteed that the statement, which
         increments use_slave, will be executed on the slaves.
         
         The meaning for version 1.1.0 is as follows. Number of statements
         sent to the slaves. Statements directed to a slave by the user filter
         (an user-defined callback) are not included. The latter are counted by
         use_slave_callback.
         | Since 1.0.0. | 
     
      | use_master | 
         The semantics of this statistic has changed between 1.0.1 - 1.1.0.
        
        The meaning for version 1.0.1 is as follows.
        Number of statements not considered as read-only by the built-in query analyzer.
        Neither statements which begin with a SQL hint to force
        use of master nor statements directed to a master by an user-defined
        callback are included. The total number of statements sent to the master is
        use_master + use_master_sql_hint +
        use_master_callback.
        
         PECL/mysqlnd_ms 1.1.0 introduces a new concept of chained filters. The
         statictics is now set by the internal load balancing filter. With
         version 1.1.0 the load balancing filter is always the last in the
         filter chain, if used. In future versions a load balancing filter may be
         followed by other filters causing another change in the meaning of
         the statistic. If, in the future, a load balancing filter is followed
         by another filter it is no longer guaranteed that the statement, which
         increments use_master, will be executed on the slaves.
         
         The meaning for version 1.1.0 is as follows. Number of statements
         sent to the masters. Statements directed to a master by the user filter
         (an user-defined callback) are not included. The latter are counted by
         use_master_callback.
         | Since 1.0.0. | 
     
      | use_slave_guess | Number of statements the built-in query analyzer recommends sending to
       a slave because they contain no SQL hint to force use of a
       certain server. The recommendation may be overruled in the following.
       It is not guaranteed whether the statement will be executed on a slave
       or not. This is how often the internal is_select
       function has guessed that a slave shall be used. Please, see also the
       user space function mysqlnd_ms_query_is_select. | Since 1.1.0. | 
     
      | use_master_guess | Number of statements the built-in query analyzer recommends sending to
       a master because they contain no SQL hint to force use of a
       certain server. The recommendation may be overruled in the following.
       It is not guaranteed whether the statement will be executed on a slave
       or not. This is how often the internal is_select
       function has guessed that a master shall be used. Please, see also the
       user space function mysqlnd_ms_query_is_select. | Since 1.1.0. | 
     
      | use_slave_sql_hint | Number of statements sent to a slave because statement begins with
       the SQL hint to force use of slave. | Since 1.0.0. | 
     
      | use_master_sql_hint | Number of statements sent to a master because statement begins with
       the SQL hint to force use of master. | Since 1.0.0. | 
     
      | use_last_used_sql_hint | Number of statements sent to server which has run the previous statement,
       because statement begins with the SQL hint to force use of previously
       used server. | Since 1.0.0. | 
     
      | use_slave_callback | Number of statements sent to a slave because an user-defined callback
       has chosen a slave server for statement execution. | Since 1.0.0. | 
     
      | use_master_callback | Number of statements sent to a master because an user-defined callback
       has chosen a master server for statement execution. | Since 1.0.0. | 
     
      | non_lazy_connections_slave_success | Number of successfully opened slave connections from
       configurations not using
       lazy connections.
       The total number of successfully opened slave connections
       is non_lazy_connections_slave_success +
       lazy_connections_slave_success | Since 1.0.0. | 
     
      | non_lazy_connections_slave_failure | Number of failed slave connection attempts from
       configurations not using
       lazy connections.
       The total number of failed slave connection attempts
       is non_lazy_connections_slave_failure +
       lazy_connections_slave_failure | Since 1.0.0. | 
     
      | non_lazy_connections_master_success | Number of successfully opened master connections from
       configurations not using
       lazy connections.
       The total number of successfully opened master connections
       is non_lazy_connections_master_success +
       lazy_connections_master_success | Since 1.0.0. | 
     
      | non_lazy_connections_master_failure | Number of failed master connection attempts from
       configurations not using
       lazy connections.
       The total number of failed master connection attempts
       is non_lazy_connections_master_failure +
       lazy_connections_master_failure | Since 1.0.0. | 
     
      | lazy_connections_slave_success | Number of successfully opened slave connections from
       configurations using
       lazy connections. | Since 1.0.0. | 
     
      | lazy_connections_slave_failure | Number of failed slave connection attempts from
       configurations using
       lazy connections. | Since 1.0.0. | 
     
      | lazy_connections_master_success | Number of successfully opened master connections from
       configurations using
       lazy connections. | Since 1.0.0. | 
     
      | lazy_connections_master_failure | Number of failed master connection attempts from
       configurations using
       lazy connections. | Since 1.0.0. | 
     
      | trx_autocommit_on | Number of autocommit mode activations via API calls.
       This figure may be used to monitor activity related to the plugin configuration
       setting
       trx_stickiness.
       If, for example, you want to know if a certain API call invokes the
       mysqlnd library function trx_autocommit(),
       which is a requirement for
       trx_stickiness,
       you may call the user API function in question and check if the
       statistic has changed. The statistic is modified only by the
       plugins internal subclassed trx_autocommit()
       method. | Since 1.0.0. | 
     
      | trx_autocommit_off | Number of autocommit mode deactivations via API calls. | Since 1.0.0. | 
     
      | trx_master_forced | Number of statements redirected to the master while
       trx_stickiness=master
       and autocommit mode is disabled. | Since 1.0.0. | 
     
      | gtid_autocommit_injections_success | Number of successful SQL injections in autocommit mode as part
       of the plugins client-side
       global transaction id emulation. | Since 1.2.0. | 
     
      | gtid_autocommit_injections_failure | Number of failed SQL injections in autocommit mode as part
       of the plugins client-side
       global transaction id emulation. | Since 1.2.0. | 
     
      | gtid_commit_injections_success | Number of successful SQL injections in commit mode as part
       of the plugins client-side
       global transaction id emulation. | Since 1.2.0. | 
     
      | gtid_commit_injections_failure | Number of failed SQL injections in commit mode as part
       of the plugins client-side
       global transaction id emulation. | Since 1.2.0. | 
     
      | gtid_implicit_commit_injections_success | Number of successful SQL injections when implicit commit is detected as part
       of the plugins client-side
       global transaction id emulation.
       Implicit commit happens, for example, when autocommit has been turned
       off, a query is executed and autocommit is enabled again. In that case,
       the statement will be committed by the server and SQL to maintain is
       injected before the autocommit is re-enabled. Another sequence
       causing an an implicit commit is begin(),
       query(), begin(). The second call
       to begin() will implicitly commit the transaction
       started by the first call to begin().
       begin() refers to internal library calls not actual
       PHP user API calls. | Since 1.2.0. | 
     
      | gtid_implicit_commit_injections_failure | Number of failed SQL injections when implicit commit is detected as part
       of the plugins client-side
       global transaction id emulation.
       Implicit commit happens, for example, when autocommit has been turned
       off, a query is executed and autocommit is enabled again. In that case,
       the statement will be committed by the server and SQL to maintain is
       injected before the autocommit is re-enabled. | Since 1.2.0. | 
     
      | transient_error_retries | How often an operation has been retried when a transient error was
       detected. See also,
       transient_error
       plugin configuration file setting. | Since 1.6.0. |