客户端工具：Navicat for Mysql
连接TiDB3.0.5可以，但TiDB4.0-rc就不可以了。
在命令行查看会导致重启吗？
在命令行执行show create table不会重启，但通过information_schema库中的表，进行查看表结构的语句没找到是哪个表，通过tidb中的慢查询发现执行了下面的语句，但里面没有数据。
SELECT TABLE_NAME, PARTITION_NAME, SUBPARTITION_NAME, PARTITION_METHOD, SUBPARTITION_METHOD, PARTITION_EXPRESSION, SUBPARTITION_EXPRESSION, PARTITION_DESCRIPTION, PARTITION_COMMENT, NODEGROUP, TABLESPACE_NAME FROM information_schema.PARTITIONS WHERE TABLE_SCHEMA LIKE ‘k2_m4_data’ AND NOT ISNULL(PARTITION_NAME) AND TABLE_NAME LIKE ‘index_info_rela’ ORDER BY TABLE_NAME, PARTITION_NAME, PARTITION_ORDINAL_POSITION, SUBPARTITION_ORDINAL_POSITION;
你好，
三方工具这边测试连接 4.0 的所有版本目前没发现类似的问题。
请反馈下 slow.log 和 tidb.log 日志看下。、
刚才操作了一次，只要通过第三方工具，查看表结构，就会重启。
@Whm412 是这样的，虽然只是查看表结构，但是表结构里面有些信息需要进行扫表操作，所以会占用较大的内存。 从监控看上，10.7.110.113 的可用内存一直很低，请问该机器的内存是多大，能否把时间拉长再看看监控？
有可能有些操作用了 select * from partition limit 1 之类的
然后并发很高，表很大，没有 limit 住，就 oom 了
当然只是说可能，要抓一下 goroutine 栈，或者是 show processlist，或者开 general log ，看一看 OOM 的当时发生了什么
- 开启 general log 参考 ，反馈日志 tidb 和tikv 咋打开 general log呀
执行 sql
在内存上涨时，抓取火焰图，反馈profile 文件 2. curl -G http://{TiDBIP}:10080/debug/zip?seconds=30" > /tmp/profile.zip
正在分析，或尽快回复，多谢
谢谢，给你们添麻烦了
@Whm412 看上去这个 profile.zip 没抓到现场(那个命令会等 30s 才抓内存, 另外会强制 gc 一次可能影响抓取结果)，请帮忙再用这个命令
curl -G http://{TiDBIP}:10080/debug/pprof/heap > heapN
在执行语句后 oom 之前快速再抓取下。
另外看下 这个 sql
select count(1) from mysql.stats_histograms where is_index = 0
的结果数量级
先回复一个，其他的要操作几次，有时间限制，不太好操作。
抓取了一次，看看这次抓取到了么？不太好判断是否成功抓取到了
2020-05-19-11_39_Sprofile.zip (124.7 KB) 2020-05-19-11_38_Sprofile.zip (220.1 KB)
好的 感谢， 看下哈
有个 dump 坏了，但从另一个可以看得的 dump 看出问题的 sql 应该是 select * from information_schema.columns 大概消耗了 12G 内存。。
@Whm412 对了确认下，其实现在的问题是， 手工执行 select * from information_schema.tables 或 手工 information_schema.schemata 是不会 oom？ 只有用 Navicat 连 tidb 才会 oom？