SQL优化——information_schema系统表查询优化和绕行方案

1. 某移动集团环境边缘节点环境出现业务执行慢性能下降的情况，排查发现11节点昨天下发了 select * from information_schema.PARTITIONS 的统计操作
13947081        116124  labledatum      10.209.139.99:51324     jsbq    datumgb Query   83267   checking permissions    /* ApplicationName=GBase Data Studio 9.5.1.0 - SQL编辑器 <脚本-105.sql> */ select * from information_schema.PARTITIONS limit 1
该操作引起11节点开表cached_tables量大，定义值16384，实际值245229，超出15倍。导致11节点DDL任务积压严重，DDL操作等锁延时。引起应用整体业务执行性能下降。

经过开会讨论，重启11节点gclusterd服务之后，业务执行性能恢复正常。

2.监控计划：
1）管理节点定时监控脚本，当任务SQL中有关于information_schema 库的select 操作超过 3600秒的情况，将SQL杀掉。
information_schema库是内存库，select * from information_schema操作会打开所有查询表的元数据信息，开表量大。
2）向研发人员宣贯避免 select * from  information_schema的操作，需要查询整库的明细信息可以直接找我们。

3. 针对查询information_schema库信息引起的业务性能下降问题，整理绕行方法如下：
1）统计应用下的临时表查询
避免 select  t.table_name from information_schema.tables t where table_schema = 'indidb'  and table_name like 'tmp_d%' 
可以改写为通配符的查询方法 use information_schema;  show tables like 'tmp_d%'  
2) 统计应用下的分区信息
避免使用 select * from information_schema.PARTITIONS。 
information_schema库的查询加上 库名、表名查询效率最高。
通过导出table列表，在循环按表名统计分区信息
select TABLE_SCHEMA ||'.'|| TABLE_NAME ||','|| PARTITION_NAME ||','|| PARTITION_ORDINAL_POSITION ||','|| PARTITION_EXPRESSION from  information_schema.PARTITIONS where TABLE_SCHEMA='datumgb' and  TABLE_NAME='${table_name}'