ProxySQL–基础–04–库和表
1、库
使用ProxySQL的Admin管理接口连上ProxySQL，可查看ProxySQL拥有的库。
mysql -uadmin -padmin -h127.0.0.1 -P6032
mysql> show databases;
+-----+---------------+-------------------------------------+
| seq | name | file |
+-----+---------------+-------------------------------------+
| 0 | main | |
| 2 | disk | /var/lib/proxysql/proxysql.db |
| 3 | stats | |
| 4 | monitor | |
| 5 | stats_history | /var/lib/proxysql/proxysql_stats.db |
+-----+---------------+-------------------------------------+
5 rows in set (0.00 sec)
1.1、main库
- 内存数据库
- ProxySQL最主要的库，修改配置时使用的
- 修改main库中的配置后，必须将其持久化到disk上才能永久保存。
- 修改了main库中的配置后，并不会立即生效，它还需要load到runtime的数据结构中才生效，只有在runtime数据结构中的配置才是对ProxySQL当前有效的配置。
mysql> show tables from main;
+--------------------------------------------+
| tables |
+--------------------------------------------+
| global_variables |
| mysql_collations |
| mysql_group_replication_hostgroups |
| mysql_query_rules |
| mysql_query_rules_fast_routing |
| mysql_replication_hostgroups |
| mysql_servers |
| mysql_users |
| proxysql_servers |
| runtime_checksums_values |
| runtime_global_variables |
| runtime_mysql_group_replication_hostgroups |
| runtime_mysql_query_rules |
| runtime_mysql_query_rules_fast_routing |
| runtime_mysql_replication_hostgroups |
| runtime_mysql_servers |
| runtime_mysql_users |
| runtime_proxysql_servers |
| runtime_scheduler |
| scheduler |
+--------------------------------------------+
1.1.1、runtime_开头的表
- runtime_开头的是运行时的配置，是不能修改的
- 要修改ProxySQL的配置，需要修改了非runtime_表，修改后需要执行一下操作
LOAD ... TO RUNTIME：将配置加载到RUNTIME生效save ... to disk：将配置持久化保存到磁盘
1.2、disk库
- 磁盘数据库
- 该数据库结构和内存数据库完全一致。
- 当持久化内存数据库中的配置时，其实就是写入到disk库中。
- 数据默认路径：$DATADIR/proxysql.db。
mysql> show tables from disk;
+------------------------------------+
| tables |
+------------------------------------+
| global_variables |
| mysql_collations |
| mysql_group_replication_hostgroups |
| mysql_query_rules |
| mysql_query_rules_fast_routing |
| mysql_replication_hostgroups |
| mysql_servers |
| mysql_users |
| proxysql_servers |
| scheduler |
+------------------------------------+
10 rows in set (0.00 sec)
1.3、stats库
- 是统计信息库。
- 这个库中的数据一般是在检索其内数据时临时填充的，它保存在内存中。因为没有相关的配置项，所以无需持久化。
mysql> show tables from stats;
+--------------------------------------+
| tables |
+--------------------------------------+
| global_variables |
| stats_memory_metrics |
| stats_mysql_commands_counters |
| stats_mysql_connection_pool |
| stats_mysql_connection_pool_reset |
| stats_mysql_global |
| stats_mysql_prepared_statements_info |
| stats_mysql_processlist |
| stats_mysql_query_digest |
| stats_mysql_query_digest_reset |
| stats_mysql_query_rules |
| stats_mysql_users |
| stats_proxysql_servers_checksums |
| stats_proxysql_servers_metrics |
| stats_proxysql_servers_status |
+--------------------------------------+
15 rows in set (0.00 sec)
1.3.1、stats_mysql_query_rules
每个查询规则被查询语句匹配的次数。
1.3.2、stats_mysql_commands_counters
每种类型的SQL命令(例如UPDATE, DELETE, TRUNCATE等)已执行的次数，以及它们执行时花费的时间。
1.3.3、stats_mysql_processlist
模仿MySQL命令"SHOW PROCESSLIST"结果的表。该表集合了所有后端的信息。
1.3.4、stats_mysql_connection_pool
包含和每个主机组中每个后端节点的连接池使用情况相关的统计数据。
1.3.5、stats_mysql_query_digest
该表包含通过ProxySQL路由出去的各类查询相关统计数据。查询的类指的是参数相同，值不同的查询，只要参数相同，这部分参数就会计算成十六进制的hash部分，并通过"?"替代这些参数(译注：select * from t where id=?)。这样一来，就能将各个查询语句进行分类。
1.3.6、stats_mysql_query_digest_reset
和stats_mysql_query_digest完全一致，但查询它时会自动将内部统计数据重置为0。某些情况下，这是很有用的技术。例如，做了一个配置修改，需要比较修改前后的统计数据。还可以通过定期查询该表来了解一段时间内的负荷的变化情况。由于ProxySQL有一个内部数据库，所以也可以将该表数据保存到内部表中。
1.3.7、stats_mysql_global
全局统计数据，例如查询的总数量、成功连接的总数量等。计划在将来版本中增加该表中变量的数量，以便统计更多全局数据。
1.4、monitor库
- 监控后端MySQL节点相关的库
- 该库中只有几个log类的表，监控模块收集到的监控信息全都存放到对应的log表中。
mysql> show tables from monitor;
+------------------------------------+
| tables |
+------------------------------------+
| mysql_server_connect_log |
| mysql_server_group_replication_log |
| mysql_server_ping_log |
| mysql_server_read_only_log |
| mysql_server_replication_lag_log |
+------------------------------------+
5 rows in set (0.00 sec)
1.5、stats_history库
- 用于存放历史统计数据。
- 默认路径为：$DATADIR/proxysql_stats.db。
mysql> show tables from stats_history;
+------------------------+
| tables |
+------------------------+
| mysql_connections |
| mysql_connections_day |
| mysql_connections_hour |
| mysql_query_cache |
| mysql_query_cache_day |
| mysql_query_cache_hour |
| system_cpu |
| system_cpu_day |
| system_cpu_hour |
| system_memory |
| system_memory_day |
| system_memory_hour |
+------------------------+
12 rows in set (0.00 sec)
1.6、ProxySQL内部使用的数据库
- 是SQLite3数据库，无论是内存数据库还是磁盘数据库，都是通过SQLite3引擎进行解析、操作的。
- SQLite3和MySQL的语法可能稍有不同，但ProxySQL会对不兼容的语法自动进行调整，最大程度上保证MySQL语句的有效率。
2、mysql_query_rules表
- 是ProxySQL的路由规则表
2.1、表字段
show create table mysql_query_rules\G;
*************************** 1. row ***************************
table: mysql_query_rules
Create Table: CREATE TABLE mysql_query_rules (
rule_id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 0,
username VARCHAR,
schemaname VARCHAR,
flagIN INT NOT NULL DEFAULT 0,
client_addr VARCHAR,
proxy_addr VARCHAR,
proxy_port INT,
digest VARCHAR,
match_digest VARCHAR,
match_pattern VARCHAR,
negate_match_pattern INT CHECK (negate_match_pattern IN (0,1)) NOT NULL DEFAULT 0,
re_modifiers VARCHAR DEFAULT 'CASELESS',
flagOUT INT,
replace_pattern VARCHAR,
destination_hostgroup INT DEFAULT NULL,
cache_ttl INT CHECK(cache_ttl > 0),
reconnect INT CHECK (reconnect IN (0,1)) DEFAULT NULL,
timeout INT UNSIGNED,
retries INT CHECK (retries>=0 AND retries <=1000),
delay INT UNSIGNED,
next_query_flagIN INT UNSIGNED,
mirror_flagOUT INT UNSIGNED,
mirror_hostgroup INT UNSIGNED,
error_msg VARCHAR,
OK_msg VARCHAR,
sticky_conn INT CHECK (sticky_conn IN (0,1)),
multiplex INT CHECK (multiplex IN (0,1,2)),
log INT CHECK (log IN (0,1)),
apply INT CHECK(apply IN (0,1)) NOT NULL DEFAULT 0,
comment VARCHAR)
1 row in set (0.00 sec)
| COLUMN | TYPE | NULL? | DEFAULT |
|-----------------------|---------|----------|------------|
| rule_id (pk) | INTEGER | NOT NULL | |
| active | INT | NOT NULL | 0 |
| username | VARCHAR | | |
| schemaname | VARCHAR | | |
| flagIN | INT | NOT NULL | 0 |
| client_addr | VARCHAR | | |
| proxy_addr | VARCHAR | | |
| proxy_port | INT | | |
| digest | VARCHAR | | |
| match_digest | VARCHAR | | |
| match_pattern | VARCHAR | | |
| negate_match_pattern | INT | NOT NULL | 0 |
| re_modifiers | VARCHAR | | 'CASELESS' |
| flagOUT | INT | | |
| replace_pattern | VARCHAR | | |
| destination_hostgroup | INT | | NULL |
| cache_ttl | INT | | |
| reconnect | INT | | NULL |
| timeout | INT | | |
| retries | INT | | |
| delay | INT | | |
| mirror_flagOU | INT | | |
| mirror_hostgroup | INT | | |
| error_msg | VARCHAR | | |
| sticky_conn | INT | | |
| multiplex | INT | | |
| log | INT | | |
| apply | INT | NOT NULL | 0 |
| comment | VARCHAR | | |
2.2、表字段说明
2.2.1、rule_id
- 规则的id。
- 规则是按照rule_id的顺序进行处理的。
2.2.2、active
active=1的规则才会加载到runtime数据结构，所以只有这些规则设置active=1，才会被查询处理模块处理。
2.2.3、username
- 用户名筛选
- 当设置为非NULL值时，只有匹配的用户建立的连接发出的查询才会被匹配。
2.2.4、schemaname
- schema筛选
- 当设置为非NULL值时，只有当连接使用schemaname作为默认schema时，该连接发出的查询才会被匹配。
- 在MariaDB/MySQL中，schemaname等价于databasename。
2.2.5、flagIN,flagOUT
这些字段允许我们创建"链式规则"(chains of rules)，一个规则接一个规则。
2.2.6、apply
当匹配到该规则时，立即应用该规则。
2.2.7、client_addr
通过源地址进行匹配。
2.2.8、proxy_addr
当流入的查询是在本地某地址上时，将匹配。
2.2.9、proxy_port
当流入的查询是在本地某端口上时，将匹配。
2.2.10、digest
通过digest进行匹配，digest的值在stats_mysql_query_digest.digest中。
2.2.11、match_digest
通过正则表达式匹配digest。
2.2.12、match_pattern
通过正则表达式匹配查询语句的文本内容。
2.2.13、negate_match_pattern
设置为1时，表示未被match_digest或match_pattern匹配的才算被成功匹配。也就是说，相当于在这两个匹配动作前加了NOT操作符进行取反。
2.2.14、re_modifiers
- RE正则引擎的修饰符列表，多个修饰符使用逗号分隔。
- 值
- caseless(默认)：表示正则匹配时忽略大小写，所以select和SELECT都能匹配。
- global：表示匹配全局，而不是第一个被匹配到的内容
- RE2引擎无法同时设置caseless和global，即使它们都设置了也不会生效。所以，将默认的正则引擎改为了PCRE
2.2.15、replace_pattern
- 将匹配到的内容替换为此字段值。它使用的是RE2正则引擎的Replace。
- 注意，这是可选的，当未设置该字段，查询处理器将不会重写语句，只会缓存、路由以及设置其它参数。
2.2.16、destination_hostgroup
- 将匹配到的查询路由到该主机组。
- 注意，如果用户的transaction_persistent=1(见mysql_users表)，且该用户建立的连接开启了一个事务，则这个事务内的所有语句都将路由到同一主机组，无视匹配规则。
2.2.17、cache_ttl
ProxySQL支持查询缓存的功能，可以将后端返回的结果集缓存在自己的内存中，在某查询的缓存条目被清理(例如过期)之前，前端再发起同样的查询语句，将直接从缓存中取数据并返回给前端。如此一来，ProxySQL处理的性能会大幅提升，也会大幅减轻后端MySQL Server的压力。
ProxySQL的查询缓存功能由mysql_query_rules表中的cache_ttl字段控制，该字段设置每个规则对应的缓存时长
- 查询结果缓存的时间长度
- 单位：毫秒
2.2.18、reconnect
目前不使用该功能。
2.2.19、timeout
- 被匹配或被重写的查询执行的最大超时时长(单位毫秒)。
- 如果一个查询执行的时间太久(超过了这个值)，该查询将自动被杀掉。
- 如果未设置该值，将使用全局变量mysql-default_query_timeout的值。
2.2.20、retries
- 当在执行查询时探测到故障后，重新执行查询的最大次数。
- 如果未指定，则使用全局变量mysql-query_retries_on_failure的值。
2.2.21、delay
- 延迟执行该查询的毫秒数。本质上是一个限流机制和QoS，使得可以将优先级让位于其它查询。
- 这个值会写入到mysql-default_query_delay全局变量中，所以它会应用于所有的查询。
2.2.22、mirror_flagOUT和mirror_hostgroup
mirroring相关的设置，目前mirroring正处于实验阶段，所以不解释。
2.2.23、error_msg
查询将被阻塞，然后向客户端返回error_msg指定的信息。
2.2.24、sticky_conn
当前还未实现该功能。
2.2.25、multiplex
- 如果设置为0：则禁用multiplexing。
- 如果设置为1：则启用或重新启用multiplexing，除非有其它条件(如用户变量或事务)阻止启用。
- 如果设置为2：则只对当前查询不禁用multiplexing。
- 默认值为NULL，表示不会修改multiplexing的策略。
2.2.26、log
查询将记录日志。
2.2.27、apply
- 当设置为1后，当匹配到该规则后，将立即应用该规则，不会再评估其它的规则
- 注意：应用之后，将不会评估mysql_query_rules_fast_routing中的规则。
2.2.28、comment
注释说明字段
3、mysql_users表
3.1、表字段
mysql> show create table mysql_users\G;
*************************** 1. row ***************************
table: mysql_users
Create Table: CREATE TABLE mysql_users (
username VARCHAR NOT NULL,
password VARCHAR,
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
use_ssl INT CHECK (use_ssl IN (0,1)) NOT NULL DEFAULT 0,
default_hostgroup INT NOT NULL DEFAULT 0,
default_schema VARCHAR,
schema_locked INT CHECK (schema_locked IN (0,1)) NOT NULL DEFAULT 0,
transaction_persistent INT CHECK (transaction_persistent IN (0,1)) NOT NULL DEFAULT 1,
fast_forward INT CHECK (fast_forward IN (0,1)) NOT NULL DEFAULT 0,
backend INT CHECK (backend IN (0,1)) NOT NULL DEFAULT 1,
frontend INT CHECK (frontend IN (0,1)) NOT NULL DEFAULT 1,
max_connections INT CHECK (max_connections >=0) NOT NULL DEFAULT 10000,
PRIMARY KEY (username, backend),
UNIQUE (username, frontend))
1 row in set (0.00 sec)
| 字段名 | 数据类型 | 可为空? | 默认值 |
|-----------------------|---------|----------|-------|
|username (pk,uk) | VARCHAR | NOT NULL | |
|password | VARCHAR | NULL | |
|active | INT | NOT NULL | 1 |
|use_ssl | INT | NOT NULL | 0 |
|default_hostgroup | INT | NOT NULL | 0 |
|default_schema | VARCHAR | NULL | |
|schema_locked | INT | NOT NULL | 0 |
|transaction_persistent | INT | NOT NULL | 1 |
|fast_forward | INT | NOT NULL | 0 |
|backend (pk) | INT | NOT NULL | 1 |
|frontend (uk) | INT | NOT NULL | 1 |
|max_connections | INT | NOT NULL | 10000 |
3.2、表字段说明
3.2.1、username, password
前端连接到ProxySQL以及ProxySQL连接到后端时使用的用户凭据。
3.2.2、active
- active=0的用户会保留在库中，但不会加载到runtime数据结构中
- active=1用户才是有效用户。
- 默认值：1。
3.2.3、default_hostgroup
如果该用户发送的查询语句无法匹配任何规则，则该查询会路由到该字段指定的默认组中。
3.2.4、default_schema
建立连接时默认将切换到该schema。
3.2.5、schema_locked
目前还不支持该功能。
3.2.6、transaction_persistent
- 值为1时：
- 表示事务持久化
- 如果正在和ProxySQL建立连接的客户端使用的用户设置了该字段，那么当该用户开启了一个事务后，那么在事务提交/回滚之前，所有的语句都路由到同一个组中，避免语句分散到不同组(它会自动禁用multiplexing，让同一个事务的语句从同一个连接路由出去，保证路由到同一个组的同一个节点)。
- 表示事务持久化
- 默认值：1。强烈建议修改为1
- 注意：有些老版本中，这个字段默认值为0，强烈建议修改为1。
我们期望的值为1，如果为0，则执行下面的语句修改为1。
update mysql_users set transaction_persistent=1 where username='root';
update mysql_users set transaction_persistent=1 where username='sqlsender';
# 将配置加载到RUNTIME，并保存到disk。
load mysql users to runtime;
save mysql users to disk;
3.2.7、fast_forward
- 如果设置了该字段，ProxySQL将绕过查询处理层(重写语句、缓存)，直接将原请求语句转发给后端节点。
- 不要求用一个不同的端口：正常的ProxySQL逻辑和"fast forward"的逻辑使用的是完全相同的代码/模块。
- fast forward是基于每用户的：根据连接到ProxySQL用户的设置，决定该用户是否启用、禁用fast forward功能。
- fast forward算法的启用是在用户认证之后：ProxySQL仍然需要先对客户端使用的用户进行认证，尽管客户端的请求会直接原样转发给后端，但ProxySQL仍然会和前端先建立好连接。这意味着，如果前端和ProxySQL的连接发生错误，也会被处理。
- fast forward不支持SSL连接。
- 如果使用压缩功能，必须在两端都启用压缩。
3.2.8、frontend
-
如果设置为1，前端将可以使用该用户(username,password)连接到ProxySQL。
-
当前版本的ProxySQL要求所有的用户均设置frontend和backend为1(即所有用户都可以进行frontend --> ProxySQL以及ProxySQL --> backend的连接认证)。将来版本中，ProxySQL将分离这两部分连接的用户凭据。这样前端将永远不知道后端的用户凭据，它们只能通过中间的ProxySQL发送请求，无法直接和后端节点建立连接，从而提高安全性。
3.2.9、backend
-
如果设置为1，ProxySQL将可以使用该用户(username,password)连接到后端节点。
-
当前版本的ProxySQL要求所有的用户均设置frontend和backend为1(即所有用户都可以进行frontend --> ProxySQL以及ProxySQL --> backend的连接认证)。将来版本中，ProxySQL将分离这两部分连接的用户凭据。这样前端将永远不知道后端的用户凭据，它们只能通过中间的ProxySQL发送请求，无法直接和后端节点建立连接，从而提高安全性。
3.2.10、max_connections
- 使用该用户"建立到ProxySQL的连接"的最大数量。
- 默认值为10000，所以每个用户最多和ProxySQL建立10000个连接。
- 注意，这是前端到ProxySQL的连接限制，ProxySQL和某个后端节点的最大连接数量是通过mysql_servers中的max_connections字段控制的。
4、mysql_servers表
4.1、表字段
mysql> show create table mysql_servers\G;
*************************** 1. row ***************************
table: mysql_servers
Create Table: CREATE TABLE mysql_servers (
hostgroup_id INT CHECK (hostgroup_id>=0) NOT NULL DEFAULT 0,
hostname VARCHAR NOT NULL,
port INT NOT NULL DEFAULT 3306,
status VARCHAR CHECK (UPPER(status) IN ('ONLINE','SHUNNED','OFFLINE_SOFT', 'OFFLINE_HARD')) NOT NULL DEFAULT 'ONLINE',
weight INT CHECK (weight >= 0) NOT NULL DEFAULT 1,
compression INT CHECK (compression >=0 AND compression <= 102400) NOT NULL DEFAULT 0,
max_connections INT CHECK (max_connections >=0) NOT NULL DEFAULT 1000,
max_replication_lag INT CHECK (max_replication_lag >= 0 AND max_replication_lag <= 126144000) NOT NULL DEFAULT 0,
use_ssl INT CHECK (use_ssl IN(0,1)) NOT NULL DEFAULT 0,
max_latency_ms INT UNSIGNED CHECK (max_latency_ms>=0) NOT NULL DEFAULT 0,
comment VARCHAR NOT NULL DEFAULT '',
PRIMARY KEY (hostgroup_id, hostname, port) )
1 row in set (0.00 sec)
| 字段 | 数据类型 | 允许null | 默认值 |
|---|---|---|---|
| hostgroup_id (pk) | int | not null | 0 |
| hostname (pk) | varchar | not null | 无 |
| port (pk) | int | not null | 3306 |
| status | varchar | not null | online |
| weight | int | not null | 1 |
| compression | int | not null | 0 |
| max_connections | int | not null | 1000 |
| max_replication_lag | int | not null | 0 |
| use_ssl | int | not null | 0 |
| max_latency_ms | int | not null | 0 |
| comment | varchar | not null | ‘’ |
4.2、表字段说明
4.2.1、hostgroup_id
- 该后端MySQL实例所在的主机组。
- 注意：同一MySQL节点可属于多个主机组。
4.2.2、hostname,port
后端MySQL监听的地址和端口。
4.2.3、status
- ONLINE：该后端MySQL节点完全正常。
- SHUNNED：该后端MySQL节点将暂时被ProxySQL自动避开(忽略)
- 原因可能是：一个较短时间内发生了大量连接错误
- 原因可能是：该slave与master的数据延迟太大(replication lag)。
- OFFLINE_SOFT：
- 当某后端MySQL被设置为 OFFLINE_SOFT 时，ProxySQL将不会向它发送新的请求，但该节点正在执行的事务会继续执行，直到所有事务执行完毕后会进入非激活状态。也就是说，和该后端的连接会保持到事务执行完毕。这可以实现后端节点的graceful停止、重启。
- OFFLINE_HARD：
- 当某后端MySQL被设置为 OFFLINE_HARD 时，ProxySQL将不会向它发送新的请求，该节点正在执行的事务也会立即中断。也就是直接将该后端杀掉。等价于删除该节点，或临时将其移除出组(例如出于维护的目的)。
4.2.4、weight
节点在组中的权重值越高，ProxySQL会发送越多请求给它们。
4.2.5、compression
如果该字段的值设置为大于0，ProxySQL和该后端新建的连接中，ProxySQL将会先压缩数据再传输。
4.2.5、max_connections
- 和该后端允许建立的最大连接数。当达到最大数量时，即使该后端的权重很大，也不会和它新建连接。
- 默认值：1000，表示每个后端最多能同时接受1000个连接。
- 请确保该后端的max_connections值是合理的，以避免MySQL超负荷时ProxySQL继续向其发送请求。
4.2.6、max_replication_lag
如果值大于0，ProxySQL的Monitor模块将会定期检查该slave的复制是否延后于master，如果延迟的值大于该字段的值，ProxySQL将会暂时避开该节点，直到该slave赶上master。
4.2.7、use_ssl
如果设置为1，则和该后端MySQL建立SSL连接。
4.2.8、max_latency_ms
Monitory模块定期向该后端发起ping检查，如果该节点的ping时间大于该字段的值，则将其排除在连接池之外(尽管该节点仍处于ONLINE状态)。
4.2.9、comment
该表的说明信息，可随便定义。
5、stats_mysql_query_digest表
该表包含通过ProxySQL路由出去的各类查询相关统计数据。查询的类指的是参数相同，值不同的查询，只要参数相同，这部分参数就会计算成十六进制的hash部分，并通过"?"替代这些参数(译注：select * from t where id=?)。这样一来，就能将各个查询语句进行分类。
5.1、表字段
mysql> select * from stats_mysql_query_digest\G;
*************************** 1. row ***************************
hostgroup: 20
schemaname: test
username: reader
digest: 0x9287F64FE7E3E08C
digest_text: SHOW FULL TABLES WHERE Table_type != ?
count_star: 1
first_seen: 1694245832
last_seen: 1694245832
sum_time: 550
min_time: 550
max_time: 550
5.2、表字段说明
5.2.1、hostgroup
查询将要路由到的目标主机组。
如果值为-1，则表示命中了查询缓存，直接从缓存取数据返回给客户端。
5.2.2、schemaname
当前正在执行的查询所在的schema名称。
5.2.3、username
MySQL客户端连接到ProxySQL使用的用户名。
5.2.4、digest
将参数化后的语句进行hash运算得到一个十六进制的hash值，可以对这个hash值进行精确匹配。
5.2.5、digest_text
参数化后的SQL语句的文本。
注意，如果重写了SQL语句，则这个字段是显示的是重写后的字段。换句话说，这个字段是真正路由到后端，被后端节点执行的语句。
5.2.6、count_star：
该查询(参数相同、值不同)总共被执行的次数。
5.2.7、first_seen：
unix格式的timestamp时间戳，表示该查询首次被ProxySQL路由出去的时间点。
5.2.8、last_seen：
unix格式的timestamp时间戳，到目前为止，上一次该查询被ProxySQL路由出去的时间点。
5.2.9sum_time：
执行该类查询所花的总时间(单位微秒)。
在想要找出程序中哪部分语句消耗时间最长的语句时非常有用，此外根据这个结果还能提供一个如何提升性能的良好开端。
5.2.10、min_time, max_time：
- 执行该类查询的时间范围。
- min_time：目前为止，执行该类查询所花的最短时间，
- max_time：目前为止，执行该类查询所花的最长时间
- 单位：都是微秒。
注意：该表中的查询所花时长是指ProxySQL从接收到客户端查询开始，到ProxySQL准备向客户端发送查询结果的时长。因此，这些时间更像是客户端看到的发起、接收的时间间隔(尽管客户端到服务端数据传输也需要时间)。更精确一点，在执行查询之前，ProxySQL可能需要更改字符集或模式，可能当前后端不可用(当前后端执行语句失败)而找一个新的后端，可能因为所有连接都繁忙而需要等待空闲连接，这些都不应该计算到查询执行所花时间内。
其中hostgroup、digest、digest_text、count_start、{sum,min,max}_time这几列最常用。
6、stats_mysql_query_digest_reset表
表结构和stats_mysql_query_digest是完全一样的，只不过每次从这个表中检索数据(随便检索什么，哪怕where 1=0)，都会重置stats_mysql_query_digest表中已统计的数据。
7、stats_mysql_query_rules表
7.1、表字段
mysql> select * from stats_mysql_query_rules\G;
*************************** 1. row ***************************
rule_id: 1
hits: 0
7.2、表字段说明
7.2.1、rule_id
对应的是规则号码。
7.2.2、hits
对应的是每个规则被命中了多少次。
8、常用的SQL语句
-- 清空规则以及规则的统计数据
-- DELETE from mysql_query_rules;
-- select * from stats_mysql_query_digest_reset;
-- 清空用户
-- delete from mysql_users;
-- 查看用户
SELECT * from mysql_users;
-- ProxySQL路由出去的各类查询相关统计数据
select * from stats_mysql_query_digest;
-- 读写分组信息
select * from mysql_replication_hostgroups;
-- 查看路由规则
select * from mysql_query_rules;
-- 查看规则的路由命中情况
select * from stats_mysql_query_rules;
-- 查看当前的正则引擎
-- select @@mysql-query_processor_regex;
-- 查看mysql节点
select * from mysql_servers;
-- 查看监控用户
select * from global_variables WHERE variable_value like '%monitor%';
-- 连接是否正常(对connect指标的监控)
select * from mysql_server_connect_log ORDER BY time_start_us desc ;
-- 心跳信息的监控(对ping指标的监控)
select * from mysql_server_ping_log ORDER BY time_start_us desc ;
-- read_only 的监控日志
select * from mysql_server_read_only_log ORDER BY time_start_us desc ;
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
