之前元数据探查工具使用的是general_log,但发现这种方式不适用于探查微服务架构的项目。因为general_log区分不开SQL来自哪个子库。查了一些资料找到下面两张表:
events_statements_history_long(
长语句历史事件表),events_statements_history(
历史语句事件表) 性能架构语句事件表
表包含
N
所有线程中全局结束的最新语句事件。语句事件在结束之前不会添加到表中。当表已满时,添加新行时,最旧的行将被丢弃,无论哪个行生成了哪一个线程。
N
服务器启动时会自动调整的值。要显式设置表大小,请performance_schema_events_statements_history_long_size
在服务器启动时设置系统变量。该
events_statements_history_long
表的列与相同events_statements_current
。请参见“ events_statements_current表”。不像events_statements_current
,events_statements_history_long
没有索引。
用以下两个配置打开:
表级的设置
select * from performance_schema.setup_consumers where name like '%events_statements_history_long%';
字段级的设置
SELECT * FROM performance_schema.setup_instruments where name like '%events_statements_history_long%';
字段设置打开不影响表级的设置,表级的设置打开,字段级的一定会打开。
保险起见开定时任务前一定会打开这个配置,定时任务结束时关闭。但实际上,关不关其实是无所谓的,此表内存是一定大小的,超过大小的会自动删掉历史数据。
此外还需要注意,mysql皮秒转换的问题
SELECT uuid_short() as sqlId, DATE_SUB(NOW(), INTERVAL (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME='UPTIME') - eshl.TIMER_START*10e-13 second