【概述】场景+问题概述
生产环境在 2021/06/22 10点左右出现负载达到200多
机器配置：40vcore, 256g，ssd
进过top查看发现，tidb-server 进程占用200多GB 内存，占总内存83%导致服务器内存被打满。服务器CPU利用14%。
通过重启tidb-server得以恢复。
希望能够帮忙分析一下tidb server 的log， 找出原因。
【背景】做过哪些操作
无特殊操作，正常查询和写入
【现象】业务和数据库现象
无法建立数据库连接
【TiDB 版本】
v4.0.8
tidb-server 日志：
【附件】tidb.log (2.7 MB)
pd面板
tidb面板
tikv面板
慢查询一直都偶尔会有几条的，但业务上并没有发生变更，平时tidb-server的内存占用一直都只有1gb左右；并且经过重启就稳定了一直都稳定在1gb左右的内存占用，如果是慢查询导致的，在同等的业务情况下，很容易复现该情况才对吧
慢查询触发原因可能是统计信息不准，可以做一下排查。
慢查询我们分析过了，都属于正常的业务查询，并且qps不高。
今天线上又出现了一次内存吃满的现象，tidb-server日志里面出现大量的[“parse attrs failed”] [conn=1543] [error=EOF]，我们并没有采用代理，能否帮我们做一次日志分析，帮忙定位一下问题。
insert 大量数据。insert into … select这种也比较吃内存，我这也有一套环境内存经常爆满，另一套只有tp的环境就没什么大问题，内存回收这块是个痛点
有些特定的查询语句能够秒出，但是show processlist 一直都存在这条sql查询记录，而且一直都在query状态，并且执行这条语句后，无法执行任何的语句，会卡死。并且同样的sql语句查询条件dt换成不同的日期范围，就不会出现该现状。
特定sql语句：
select * from (select dt,sum(consume) as consume,sum(cost) as cost,sum(new_mobile) as new_mobile,sum(new_mobile_day) as new_mobile_day,sum(new_income_money) as new_income_money,sum(new_income_user) as new_income_user,sum(new_account) as new_account,sum(real_income_money) as real_income_money,sum(income_user) as income_user,sum(dau) as dau,sum(roi_1) as roi_1,SUM(IF(DATEDIFF(DATE_SUB(CURDATE(),interval 0 day),dt)<0,0,cost)) as roi_1_d,sum(click) as click,sum(show) as show from game_tf_report_v4.report_base_day b join (select id,owner,sso_owner,media_dept_id,media_master_id,media_id,agent_id,dept_id,dept_group_id,vest_id from game_tf_report_v4.game_cate_monitor k ) g on b.monitor_sn=g.id where dt >= ‘2021-06-01’ and dt <= ‘2021-06-22’ group by dt) t order by dt desc limit 0,10;
日志每次会抛出多条这个警告
[client_batch.go:632] [“wait response is cancelled”] [to=10.0.2.21:20163] [cause=“context canceled”]
搞个explain 和 explain analyze 分析看看
肯定是量级太大了，然后必须在tidb 这一层做聚合后，在做条件筛选，导致内存暴增
内存回收又没有那么及时，然后其他的请求一来，就没办法响应了
如果还有硬件资源的话，建议追加一台 tidb，专门定向的执行这些比较吃内存的。
这样可以隔离一些问题，但是并没有解决…
要解决必须从优化的角度下手了
