转载自：https://www.jianshu.com/p/b9d2a09d80e2
全局变量概述
ProxySQL的行为可以通过全局变量来调整。有两种配置方式：
在runtime下，使用admin结构(推荐)。
在启动时，在配置文件中使用专门的配置段落。
ProxySQL大多数变量都可以在runtime环境下修改并立即生效，无需重启ProxySQL，这样能保证它最大的运行时长。只有两个变量不能再runtime下修改：mysql-threads和mysql-stacksize。
有两类全局变量，它们分别管理控制ProxySQL的不同部分：
admin variables，控制admin接口的行为。这些变量以admin-作为前缀。
mysql variables，控制ProxySQL的MySQL功能，这些变量以mysql-作为前缀。
这些全局变量存储在ProxySQL的每个线程中，以便加速对它们的访问，因为需要非常频繁地使用它们。它们根据内存占用或所接受的连接数量以及其他基本方面来控制代理的行为。只要执行LOAD MYSQL VARIABLES TO RUNTIME或LOAD ADMIN VARIABLES TO RUNTIME命令，所有的线程都会收到更新admin variables或mysql variables的通知。
要修改全局变量的值，使用UPDATE语句：
UPDATE global_variables SET variable_value=1900 WHERE variable_name='admin-refresh_interval';
或者使用类似于MySQL的更短的SET语句(常用此种方式)：
SET admin-refresh_interval = 1700;
SET admin-version = '1.1.1beta8';
(译者注：要查看变量的值，可以show variables [like xxx];或者show global variables;)
Admin变量
admin-admin_credentials
这是一个分号分隔的账户密码对user:password列表，这些是认证到admin接口具有读、写权限的用户凭据。对于只读权限的用户凭据，它们只能连接到admin接口并查询数据，见变量admin-stats_credentials。注意，admin接口通过ProxySQL的main线程监听在独立的端口上(译注：关于ProxySQL的线程类型，参见https://github.com/malongshuai/proxysql/wiki/ProxySQL-Threads)。这个端口是通过变量admin-mysql_ifaces控制的。
需要引起重视的是：
默认的admin用户只允许本地连接，如果想要远程连接，需要通过admin-admin_credentials变量创建另一个用户。例如：admin-admin_credentials="admin:admin;radminuser:radminpass"。
admin-admin_credentials中的用户不能出现在mysql_users表中。
admin-admin_credentials
admin-mysql_ifaces
指定admin接口的监听地址，格式为分号分隔的hostname:port列表。注意，允许使用UNIX的domain socket进行监听，这样本主机内的应用程序就可以直接被处理。例如：SET admin-mysql_ifaces='127.0.0.1:6032;/tmp/proxysql_admin.sock'。
admin-mysql_ifaces
admin-read_only
当该变量设置为true并已加载到runtime生效后，Admin模块就不会再接受任意具有写权限的连接。不想让ProxySQL进行任何重新配置时，这很有用。当admin-read-only=true，唯一将其设置为false并在runtime(需要先让Admin模块再次可写)生效的方法是运行命令PROXYSQL READWRITE
admin-read_only
admin-refresh_interval
更新查询规则的统计数据、命令计数器的统计数据的刷新时间间隔(单位毫秒)。请注意，不要将这个变量的值调整的太小，因为这会影响ProxySQL的性能。也不要调整的太大，因为这会影响结果的正确性。
admin-refresh_interval
admin-stats_credentials
分号分隔的用户密码对user:password，该变量定义的用户凭据连接到admin接口时只有只读权限。它们不允许修改内部的数据接口，例如后端MySQL服务器节点列表(或主机组)、查询规则等。它们只允许从统计表(statistics tables)和监控表(monitoring table)中读取数据，其它表对它们不可见。
注意：admin-stats_credentials中的用户不能出现在mysql_users表中。
admin-stats_credentials
admin-telnet_admin_ifaces
当前未使用(计划在将来的版本中使用)。
admin-telnet_stats_ifaces
当前未使用(计划在将来的版本中使用)。
admin-version
ProxySQL的版本号，该变量是只读变量。
admin-version
历史统计数据管理
从ProxySQL 1.4.4开始，Admin模块将历史数据指标存储到datadir下的新数据库proxysql_stats.db中。表结构可能受未来变化的影响。
admin-stats_mysql_connection_pool
更新"连接池的历史统计数据"的时间间隔(单位秒)。
admin-stats_mysql_connection_pool
admin-stats_mysql_connections
更新"MySQL连接的历史统计数据"的时间间隔(单位秒)，这里的连接同时包括和前端的、和后端的。
admin-stats_mysql_connections
admin-stats_mysql_query_cache
更新"MySQL查询缓存的历史统计数据"的时间间隔(单位秒)。
admin-stats_mysql_query_cache
admin-stats_system_cpu
更新"CPU使用率的历史统计信息"的时间间隔(单位秒)。
admin-stats_system_cpu
admin-stats_system_memory
更新"内存使用率的历史统计信息"的时间间隔(单位秒)。
注意：如果没有将jemalloc编译到ProxySQL，则无法获取这些内存统计数据。官方给出的包中都会将jemalloc编译到ProxySQL。
admin-stats_system_memory
Admin模块的web接口
ProxySQL 1.4.4嵌入了一个HTTP web server，可以用来收集一些特定的指标。
访问web接口的用户由admin-stats_credentials决定。
admin-web_enabled
如果admin-web_enabled设置为true，则自动启用内嵌的web server。
admin-web_enabled
admin-web_port
定义web server的监听接口。
admin-web_port
MySQL变量
mysql-client_found_rows
设置为true时，为了让ProxySQL连接到后端MySQL，会设置一个CLIENT_FOUND_ROWS的客户端标识。
没明白具体含义，不过一般不改此变量。
mysql-client_found_rows
mysql-commands_stats
启用每个命令的MySQL查询统计信息。所谓的命令，是正在执行的SQL查询的一种类型。例如:SELECT、INSERT或ALTER TABLE。
mysql-commands_stats
mysql-connect_retries_delay
连接到后端MySQL服务器时失败后，需要等待多长时间才尝试重连(单位毫秒)。有多种可能会导致和后端MySQL的连接失败：太繁忙、当前尝试超时等。重连次数由mysql-connect_retries_on_failure决定。
mysql-connect_retries_delay
mysql-connect_retries_on_failure
当和后端MySQL服务器的连接失败时(可能是发生错误、超时或其它事件导致的)，允许的重连次数。当耗尽了重连次数且仍然没有成功建立连接，将报错。例如，返回一个通用的错误("Max connect failure while reaching hostgroup" with error code 28000)。
调整该变量时需要小心，太大的值会显著增加主机组(因为无法建立连接，它们已经无响应)给MySQL客户端回应的延迟时长。
mysql-connect_retries_on_failure
mysql-connect_timeout_server
ProxySQL连接到后端MySQL服务器的超时时间，这个是单次连接的超时时间。如果这次连接超时，根据其它参数的设置，ProxySQL将会重新尝试建立连接，直到达到了最大重连次数而每秒生成报错信息(此时ProxySQL会自动避开后端MySQL，即不再连接，但会不断报错)，或者达到了连接的最终截止时间(见mysql-connect_timeout_server_max)而报另一种错误。
mysql-connect_timeout_server
mysql-connect_timeout_server_max
ProxySQL和后端MySQL服务器建立连接的超时时间。当达到了这个超时时长后，将返回给客户端 #28000的错误代码("Max connect failure while reaching hostgroup" with error code 28000)。
(译注：这个是所有重连的总超时时长。例如单次超时时间为1秒，允许重连次数为20次，但这里的超时时间为10秒，那么大概第10次重连时就会直接报错，因为到了连接的截止时间)
See also mysql-shun_recovery_time_sec。
mysql-connect_timeout_server_max
mysql-connection_delay_multiplex_ms
短期内禁用连接上的多路复用功能，这使得前端的连接会重用后端的连接以便成功完成查询(例如执行批处理查询)。这个延迟时间(毫秒)是在连接出于空闲状态(当前没有任何会话使用)时评估计算的。
mysql-connection_delay_multiplex_ms
mysql-connection_max_age_ms
当该变量设置的值大于0时(单位毫秒)，如果某个空闲连接(当前没有任何会话使用)的空闲时长超过了这里设置的值，则这个连接会关闭。默认情况下，连接不会基于它们的存活时长而关闭。
(译注：换句话说，即长连接的空闲状态保持时长。默认无上限)
mysql-connection_max_age_ms
mysql-default_charset
返回给MySQL客户端时，ProxySQL默认使用的字符集。注意，这是和客户端的默认通信字符集，不是和后端MySQL服务器通信的字符集。
mysql-default_charset
mysql-default_max_latency_ms
ProxySQL使用一种自动忽略的机制来忽略那些延迟过大的后端主机。注意，只是忽略该后端服务器，而不是禁用：换句话说，ProxySQL更喜欢低延迟的后端主机。可以在每个后端主机的mysql_servers表的max_latency_ms列来配置它的最大延迟时长。如果该后端主机的mysql_servers.max_latency_ms的值为0，则采用此处变量的值作为默认值。
mysql-default_max_latency_ms
注意：考虑到ProxySQL对SSL实现的局限性，建议在使用SSL时增大此处的值。
mysql-default_query_delay
一个简单的对后端MySQL节点的限流机制。如果此变量设置为N(非0值，单位毫秒)，将延迟N毫秒再执行所有的查询，这是全局性的延迟。在admin表mysql_query_rules中有更细粒度限流机制，它可以为每个能匹配规则的查询设置独立的延迟时长。这个额外的细粒度延迟是在此处默认的全局延迟之上添加的(译注：也就是说会覆盖全局的延迟)。
mysql-default_query_delay
mysql-default_query_timeout
指定路由到后端MySQL的查询最长持续时间，如果超过了这个时间，表示查询执行太慢，ProxySQL会探测到这个超时，然后派生出一个独立的线程发送KILL查询语句到后端MySQL上，以便杀掉后端执行该查询的线程来停止查询。由于后端的查询线程被杀，所以ProxySQL会向客户端返回一个错误。
mysql-default_query_timeout
mysql-default_reconnect
当前未使用。
mysql-default_schema
指定一个默认的schema，当客户端发起的查询语句中没有指定schema名称时，ProxySQL将重写语句并加上该默认schema。
(译注：如果不理解schema，将其看作是数据库即可。其实在MySQL中，schema就是数据库的同义词。例如，这里使用了默认的schema，就无需先use databaseA，再select ...)
mysql-default_schema
mysql-default_sql_mode
当客户端想要修改sql_mode时，ProxySQL需要跟踪这次修改以确保该客户端涉及到的所有后端的sql_mode都完全一致。
当ProxySQL和后端建立一个新的连接，ProxySQL不会知道后端节点上的sql_mode值。尽管它可以查询后端的sql_mode得到结果，但每次查询会有延迟开销。基于此，ProxySQL不会去查询后端的sql_mode值，而是假设所有后端都使用此处变量mysql-default_sql_mode指定的值。
如果客户端要修改的sql_mode值和此变量的值不同，则ProxySQL需要确保和该客户端有关的每个后端的sql_mode值都完全一致。换句话说，，如果客户端设置sql_mode的值和此变量的值相同，那么ProxySQL不会修改后端MySQL上的sql_mode，因为它认为这个sql_mode是正确的。
该变量如果配置错误，将会导致一些预料之外的结果。例如，如果mysql-default_sql_mode=''(ProxySQL的默认值，也是MySQL <=5.6.5的默认值)，而后端的sql_mode值不是''，当客户端执行set session sql_mode=''时，ProxySQL将不会在任何后端上做任何修改。
应该让此变量的值和所有后端的sql_mode的值相同。如果后端的sql_mode和此处值不同，或者你想让ProxySQL总是强制客户端指定的sql_mode值，那么该变量可以随意配一个值。但这样会让ProxySQL每次都去修改后端的sql_mode为客户端指定的值。
mysql-default_sql_mode
mysql-enforce_autocommit_on_reads
ProxySQL跟踪客户端指定的autocommit，并确保所连接的后端上已经正确设置autocommit。如果客户端使用autocommit启动事务，并通过查询规则实现读/写分离，则此将出现问题。实际上，如果读取请求被发送给一个slave，且ProxySQL为slave设置了autocommit=0，将会导致两个事务(一个在master上，一个在slave上)。为了防止这种情况发生，如果mysql-enforce_autocommit_on_reads=false(默认值)，ProxySQL将不会更改SELECT语句所连接的后端的autocommit的值。
mysql-eventslog_filename
如果设置了该变量，ProxySQL将会记录所有的事件到指定的文件中。注意，这个日志文件是二进制编码格式的，不是文本文件。文件名可以是绝对路径(例如"/data/events_log/events_log")，也可以是一个单独的文件名(例如"events_log")，此时会记录到数据目录下。ProxySQL总会为文件名加上一个序列号后缀(例如"events_log.00000001")。
mysql-eventslog_filename
mysql-eventslog_filesize
该变量指定mysql-eventslog_filename文件(由ProxySQL logger创建)的最大容量值。当达到了该最大值时，将rotated到新的日志文件。
mysql-eventslog_filesize
mysql-free_connections_pct
ProxySQL有一个连接池，用于连接后端MySQL服务器。
在不需要连接到后端时，不会预先分配连接，因此在ProxySQL刚启动的时候，没有任何到后端的连接。
当应用程序发送了一个MySQL请求(译注：即需要和后端通信)给ProxySQL时，ProxySQL首先解析要路由到哪个后端，如果连接池中已经有和该后端的连接，将重用该连接，否则将创建一个新的和后端的连接。
当处理完客户端的请求后，连接会还回主机组管理器(HostGroup Manager)。如果主机组管理器判断了该连接是可以被安全共享的，且连接池未满，则该连接会放进连接池。
(译注：连接池中的连接全都是空闲连接，正在使用的连接不会进入连接池)
但是，不是所有的未使用的连接都会放进连接池。该变量用来控制某后端的空闲连接和最大总连接数的百分比。对于每个hostgroup/backend，主机组管理器只会保持连接池中的最大连接数为mysql-free_connections_pct * mysql_servers.max_connections / 100。池中的每个空闲连接都通过间断性的ping来维持它的打开状态。
如果某连接从上一次ping之后，如果还没有被使用，则该连接被定义为空闲连接。对于空闲连接ping的时间间隔由变量mysql-ping_interval_server_msec控制。
mysql-free_connections_pct
mysql-have_compress
已不再使用该变量。
mysql-interfaces
指定MySQL请求的监听地址和端口hostname:port(译注：是客户端向ProxySQL发起的关于MySQL操作的请求，可将其理解为MySQL的3306端口的作用)，多个监听地址可使用分号分隔。注意，也可以使用UNIX domain socket来处理本机应用程序发出的MySQL请求。
mysql-interfaces
mysql-max_allowed_packet
mysql-max_allowed_packet定义客户端接收的单个最大数据包大小。它模仿自mysqld的max_allowed_packet。
(译注：换句话说，是ProxySQL发送给客户端的单个最大数据包大小。请查看上述MySQL的官方手册，以下是简要说明：
对于要返回的大对象，如大blob对象、长文本，必须将该变量设置为比该对象更大或者相等，否则将会报错。如果允许的话，还要修改客户端程序接收的最大包大小。只能按照1024的倍数进行修改。 )
mysql-max_allowed_packet
mysql-max_connections
ProxySQL能处理的和前端客户端的最大连接数。如果还有新的连接请求，这些请求将会被拒绝，并返回错误代码#HY000和错误信息Too many connections。
mysql-max_connections
mysql-max_stmts_per_connection
当一个连接放回连接池(译注：表示进入空闲状态了)时，会计算这个连接之后还能处理多少个语句，当处理的语句数量达到该阈值后，将关闭该连接(v1.4.3之前)或者重置该连接(从v1.4.4开始)。
mysql-max_stmts_per_connection
mysql-max_transaction_time
当正在执行事务的会话达到了该超时时长后，ProxySQL就会将这个会话杀掉。
(译注：因为这表示事务执行太慢，可能是因为这是个长事务，也可能是因为后端处理速度太慢。所以杀掉后会返回错误信息给客户端)
mysql-max_transaction_time
mysql-monitor_connect_interval
ProxySQL的Monitor模块会尝试连接到后端MySQL以便检查它们是否健康，该变量定义建立连接的时间间隔。(译注：换句话说，即对后端做健康检查的时间间隔)
mysql-monitor_connect_interval
mysql-monitor_connect_timeout
Monitor模块和后端建立连接时的超时时间(单位毫秒)。目前，这个时间会向下舍入为小于或等于此处给定值转换为秒的整数(译注：给定2200毫秒，会转换为2秒)。允许的最小值为1秒。这种懒惰的"四舍五入"行为是因为SSL连接是阻塞模型的调用。
mysql-monitor_connect_timeout
mysql-monitor_enabled
启用/禁用Monitor模块，该模块用于监控后端MySQL服务器的健康。
mysql-monitor_enabled
mysql-monitor_history
Monitor模块生成因为做检查而生成的事件的持续时长。这些事件包括：连接到后端(检查和后端是否能通信)，发起一个简单的ping查询(检查后端MySQL服务是否正常运行)，以及检查后端MySQL复制是否有拖后腿的节点(replication lag)。这些事件都会记录日志，日志表分别为：
mysql_server_connect_log
mysql_server_ping_log
mysql_server_replication_lag_log
mysql-monitor_history
mysql-monitor_username
指定Monitor模块连接到后端时使用的用户名。这些用户只需要有USAGE权限能进行连接、ping以及只读检查(译注：read_only check，指的是slave必须只允许read_only，不允许写)即可。如果需要监控replication lag，则还需要具有REPLICATION CLIENT权限。
mysql-monitor_username
mysql-monitor_password
指定Monitor模块连接到后端时使用的密码。
mysql-monitor_password
mysql-monitor_ping_interval
Monitor模块使用[mysql_ping]API向后端发起ping的时间间隔。
(参考https://dev.mysql.com/doc/refman/5.0/en/mysql-ping.html)
mysql-monitor_ping_interval
mysql-monitor_ping_timeout
Monitor模块等待ping回复的超时时间。超过这段时间还未收到后端对ping的回复，就认为和该后端的无法建立正常的连接。
mysql-monitor_ping_timeout
mysql-monitor_read_only_max_timeout_count
当monitor线程执行read_only检查，且该检查的时间超出了mysql-monitor_read_only_timeout(译注：在官方wiki中没有给出这个变量的解释。它的作用是单次read_only检查的超时时间)后，将重试read_only检查直到该变量指定的最大次数。如果达到了最大次数，read_only检查还是未通过，则将该slave标记为OFFLINE HARD。
mysql-monitor_read_only_max_timeout_count
mysql-monitor_query_interval
目前未使用该变量。
以后Monitor模块将会收集后端服务器的全局状态数据，该变量指定收集的时间间隔。
mysql-monitor_query_interval
mysql-monitor_query_status
目前未使用该变量。
以后Monitor模块将会收集后端服务器的全局状态数据。
mysql-monitor_query_status
mysql-monitor_query_timeout
目前未使用该变量。
以后Monitor模块将会收集后端服务器的全局状态数据，该变量指定收集状态数据时的超时时间。
mysql-monitor_query_timeout
mysql-monitor_query_variables
目前未使用该变量。
以后Monitor模块将会收集后端服务器的全局状态数据。
mysql-monitor_query_variables
mysql-monitor_replication_lag_interval
ProxySQL需要每隔一段时间去检查后端的复制是否有哪个slave比master上的数据延迟很大(译注：俗称拖后腿，例如某slave的复制速度较慢)，该变量指定做replication lag检查的时间间隔。如果ProxySQL发现某slave拖后腿了，会临时将其标记为"自动避开节点"。由admin接口的mysql_servers.max_replication_lag字段的值决定每隔主机组中的slave节点是否拖后腿(译注：即slave比Master延迟了多少数据)。
mysql-monitor_replication_lag_interval
mysql-monitor_replication_lag_timeout
Monitor模块等待后端MySQL返回SHOW SLAVE STATUS结果，该变量指定等待的超时时长。
mysql-monitor_replication_lag_timeout
mysql-monitor_slave_lag_when_null
当replication检查返回Seconds_Behind_Master=NULL时，mysql-monitor_slave_lag_when_null的值(单位秒)就作为当前replication lag的延迟长度。这使得ProxySQL对于不正常的后端节点，即可以避开它也可以保持它在线。
(译注：
在MySQL 5.7，second_behind_master=null表示两种可能：(1)SQL线程未运行;(2)或者SQL线程已将relay log重放完成，但IO线程未运行。
在MySQL 5.7之前，返回null表示SQL线程未运行，或IO线程未运行，或未连接到master。 总之，返回null时，表示该slave暂时处于不可用状态。ProxySQL根据mysql-monitor_slave_lag_when_null来决定最多允许多长时间不可用，超过了这段时间，就认为它真的不可用，需要避开它。
)
mysql-monitor_slave_lag_when_null
mysql-monitor_timer_cached
此变量控制ProxySQL是否使用wall clock time的缓存值(精度较低)。(API详见http://stuff.onse.fi/man?program=event_base_gettimeofday_cached§ion=3).
此项目前还没弄明白，待后续研究。
mysql-monitor_timer_cached
mysql-ping_interval_server_msec
ProxySQL为了维持和后端的空闲连接，每隔一段时间发送一次ping，该变量指定发起ping的时间间隔。
mysql-ping_interval_server_msec
mysql-ping_timeout_server
ProxySQL为了维持和后端的空闲连接，每隔一段时间发送一次ping。保持空闲连接，可以避免和该后端新建连接，从而降低开销、减少ProxySQL的内存占用以及其它一些流量。该变量指定ping得到回复的超时时间。
mysql-ping_timeout_server
mysql-poll_timeout
ProxySQL使用系统调用poll()探测流入/流出流量的最小超时时间。如果ProxySQL确定了它应该使用一个更大的超时时间(比如需要内部计算时)，它将会自动增加超时时间，但绝不会使用低于这个变量的超时时长。
mysql-poll_timeout
mysql-poll_timeout_on_failure
在连接失败后，用来探测流入/流出流量的超时时间。在某些情况下(译注：如再次发起连接)，代理会自动将其超时调整为一个较低的值，以便能够快速响应有效的连接。
mysql-poll_timeout_on_failure
mysql-query_digests
当该变量设置为true，ProxySQL将分析接收到的查询语句，并且并将它们划分到参数相同但值不同的查询类别中。它会为这些查询类别计算一些指标，这些全都可以从status_mysql_query_digest表中查看到。更详细的内容，请参见https://github.com/malongshuai/proxysql/wiki/Main-(runtime)#mysql_query_rules。
需要引起注意的是，当需要禁用多路复用时，需要使用查询的数字摘要(digest)来决定何时禁用多路复用，例如TEMPORARY表，SQL_CALC_FOUND_ROWS，GET_LOCK等。(原文：It is also very important to note that query digest is required to determine when multiplexing needs to be disabled, for example in case of TEMPORARY tables, SQL_CALC_FOUND_ROWS , GET_LOCK, etc. )
除非你明确知道禁用mysql-query_digests不会中断你的应用程序，否则任何时候都不要禁用该变量。
mysql-query_digests
mysql-query_digests_lowercase
当设置为true时，查询摘要会自动转换为小写，如果为false，则查询摘要区分大小写。
mysql-query_digests_lowercase
mysql-query_digests_max_digest_length
定义digest_text的最大长度，并报告到stats_mysql_query_digest中。
mysql-query_digests_max_digest_length
mysql-query_digests_max_query_length
当计算查询摘要(query's digest)以及摘要文本(digest_text)时能处理的最大查询长度。
mysql-query_digests_max_query_length
mysql-query_processor_iterations
如果设置了mysql_query_rules.flagOUT且mysql-query_processor_iterations值大于0，则正在匹配的规则将设置flagIN，并从开头开始处理规则直到mysql-query_processor_iterations。因此，mysql-query_processor_iterations允许跳回到之前的mysql_query_rules处。
(原文: If mysql_query_rules.flagOUT is set and mysql-query_processor_iterations is greater than 0, a matching rule will set flagIN and starts processing rules from the beginning up to mysql-query_processor_iterations iterations.
Therefore, mysql-query_processor_iterations allows to jump back to previous mysql_query_rules.)
mysql-query_processor_iterations
mysql-query_processor_regex
该变量定义使用何种正则表达式引擎：
1 : PCRE
2 : RE2
版本v1.4.0之前，只能使用RE2引擎，该正则引擎总是会启用caseless(译注：即忽略大小写)且禁用GLOBAL。
从版本v1.4.0开始，可随意选一种。现在，无论是PCRE还是RE2，都能通过re_modifiers来决定CASELESS 和 GLOBAL是否开启。
但是，RE2不支持同时启用CASELESS 和 GLOBAL，即使它们都通过配置re_modifiers为开启状态。基于此原因，默认的正则引擎改为了PCRE。
mysql-query_processor_regex
mysql-query_retries_on_failure
当某查询失败后，将重试查询的次数。
mysql-query_retries_on_failure
mysql-server_capabilities
MySQL功能的位掩码(编码为位)，ProxySQL将用它来响应连接到它的客户端。这能有效防止使用某些特定功能，尽管计划在将来弃用它。
默认的功能有:
server_capabilities = CLIENT_FOUND_ROWS | CLIENT_PROTOCOL_41 | CLIENT_IGNORE_SIGPIPE | CLIENT_TRANSACTIONS | CLIENT_SECURE_CONNECTION | CLIENT_CONNECT_WITH_DB | CLIENT_SSL;
详细的MySQL功能见官方手册.
mysql-server_capabilities
mysql-server_version
ProxySQL响应给客户端的MySQL版本号。
注意，即使后端MySQL的版本号和此处定义的不一样，ProxySQL也会无视后端实际的版本号，而是返回此处定义的版本号。
mysql-server_version
mysql-servers_stats
当前已不再使用，将来版本中会移除此变量。
mysql-servers_stats
mysql-session_debug
当前已不再使用，将来版本中会移除此变量。
mysql-session_debug
mysql-session_idle_ms
从v1.3.0开始，每个MySQL线程都有一个伴随的空闲线程(auxiliary thread)，负责处理空闲会话。该变量定义了session何时进入空闲状态，进入空闲状态后，该会话(译注：此处也表示和客户端的连接)会被MySQL线程交给伴随它的空闲线程来维持，当该连接发生了某些事件(例如，新的连接、超时等)后，空闲线程会将会话还给MySQL线程。
mysql-session_idle_ms
mysql-session_idle_show_processlist
该变量定义了空闲session(由mysql-session_idle_ms定义)是否应当被show processlist列出(更通用的，是否应该记录到stats_mysql_processlist表中)。出于性能的考虑，默认不会列出空闲会话。
mysql-session_idle_show_processlist
mysql-sessions_sort
所谓会话(session)是ProxySQL中维持的MySQL客户端和后端MySQL服务器之间的对话。session通常按照持续平衡的顺序进行处理，但在某些场景中(比如使用事务时，这会使session绑定到池中的某些MySQL连接)，以相同的顺序处理它们会导致线程饥饿(译注：某些线程已经处理完了请求，却还在等在它之前的线程)。
此变量用来控制session是否应该按照等待时间的顺序进行处理，以便在会话之间实现更均衡的流量分配。
mysql-sessions_sort
mysql-shun_on_failures
以1秒的间隔允许和后端MySQL的错误连接数量，直到该后端被临时标记为自动避开的节点。目前不能通过将它设置为一个特殊值来禁用它，可以将它设置为一个非常大的值来变相禁用它。
(译注：第一次连接失败后，每秒重连1次，并输出错误信息，如果一直连接失败，在一定次数(即此变量指定的值)后，ProxySQL将标记该后端为自动避开的节点，在被标记为自动避开的时间段内，ProxySQL就当这个后端是不存在的。在一定时间后会取消该标记，避开的时间长短由变量mysql-shun_recovery_time_sec控制。)
mysql-shun_on_failures
mysql-shun_recovery_time_sec
当某后端服务器被ProxySQL自动避开(译注：ProxySQL将某节点标记为自动避开后，ProxySQL将忽略这些后端节点)后，需要等待这里定义的时间才会恢复，恢复之后ProxySQL才不会忽略它。
注意，如果ProxySQL并未正在处理MySQL流量，则无法保证精确的恢复时间，但在实践过程中，不会超过这个值太长时间(只差几秒种)。
会进行的自我调整：
mysql-shun_recovery_time_sec应当总是小于mysql-connect_timeout_server_max/1000，以便避免ProxySQL太长时间才向客户端返回错误信息。如果mysql-shun_recovery_time_sec > mysql-connect_timeout_server_max/1000，则使用两者较小值。(see #530)
如果主机组中只有一个MySQL节点，且mysql-shun_recovery_time_sec > 1，则ProxySQL将在1秒之后自动恢复这个唯一的节点。
mysql-shun_recovery_time_sec
mysql-stacksize
ProxySQL用于处理MySQL流量和连接到后端的后台线程所使用的栈空间大小。无法在runtime下使该变量的修改生效，如果需要生效，必须通过重启ProxySQL的方式实现。
mysql-stacksize
mysql-stats_time_backend_query
启用/禁用"后端查询使用的CPU时间统计信息"的收集。
Enables / disables collection of backend query CPU time statistics.
mysql-stats_time_backend_query
mysql-stats_time_query_processor
启用/禁用"查询处理器使用的CPU时间统计信息"的收集。
mysql-stats_time_query_processor
mysql-threads
ProxySQL用于处理MySQL流量的后台线程数。注意，还有其它类型的线程，它们不是处理和MySQL流量有关的线程，例如：
Admin接口的线程
和后端服务器交互的监控模块的线程(一个线程负责监控连接是否正常，一个线程负责ping后端，一个线程负责监控复制是否有拖后腿的节点(replication lag))
偶尔派生的临时线程，这些临时线程是为了向后端发送KILL语句，以便杀掉后端服务器上对查询长时间无响应的查询线程。
ilbmariadbclient库使用的一些后台线程，这些线程是为了和后端MySQL server进行一些特定的异步交互任务。
注意，在runtime下修改该变量是无效的，只能通过重启ProxySQL的方式修改该变量。
mysql-threads
mysql-threshold_query_length
如果发送给ProxySQL的SQL查询语句太长，将会标记和后端已建立的MySQL连接为"不可重用(non-reusable)"。这会强制让ProxySQL打开一个新的和后端服务器的连接，以便限制服务器的内存使用率在合理范围内。
详细内容见MySQL官方手册：https://dev.mysql.com/doc/refman/5.6/en/memory-use.html 。以下是和此处配额相关的说明："连接buffer(connection buffer)和结果集buffer(result buffer)的初始大小都等于net_buffer_length，但在有需求时会动态地扩容到max_allowed_packet大小。在查询语句结束后，结果集buffer的大小会收缩回net_buffer_length。"
mysql-threshold_query_length
mysql-threshold_resultset_size
如果后端服务器返回的结果集长度大于这个阈值，ProxySQL将立即开始将结果发送给发起请求的客户端，以便限制其内存占用。
默认值：4194304(字节，即4MB)
mysql-threshold_resultset_size
mysql-wait_timeout
如果一个会话(MySQL客户端和ProxySQL之间的对话)的空闲时长超过此阈值，ProxySQL将杀掉该会话。
mysql-wait_timeout
