为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】
v4.0.12
【问题描述】
内存持续上升，寻求解决方案。
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
是的 我看没回复 我单开了个贴
- 目前看parser.yyParse占用较多，内存很多耗费在了解析上。
- 是否有dashboard，sql 语句分析中，勾选平均内存，排序看下有没有哪个sql占用内存很多（时间可以选择取profiel文件时）
- 这个tidb-server的日志也麻烦取一下吧。deploy_dir目录log里的tidb.log文件。
-
从日志中看，PD 获取 TS 错误
[2021/04/13 00:04:16.832 +08:00] [ERROR] [client.go:319] ["[pd] getTS error"] [error="[PD:client:ErrClientGetTSO]rpc error: code = Unknown desc = [PD:tso:ErrGenerateTimestamp]generate timestamp failed, timestamp in memory isn’t initialized"] -
当前启动后，decode plan in slow log failed
[2021/04/14 09:40:47.320 +08:00] [ERROR] [slow_query.go:777] [“decode plan in slow log failed”] [plan=ixfoMAkzXzUJMAkyNzk4NTkJeWxfdGVzdC5wcm9fZXRtc19pbnN0aXR1dGlvbi7ljLvpmaLnvJbnoIEsIHmGKwAY5ZCN56ewLI4rAAjnroCGKwAU55yB5Lu9llYAEJ+O5biClisAEIy65Y6/misAJLvpmaLmgKfotKiW1wAQsbvlnot6KwAs5Lul5bKt57qn5YireisALOWbveWutuetiee6p3orACznibnoibLkuJPnp5F6KwAU5Zyw5Z2AeiUAFOmCrue8lnolACzogZTns7vnlLXor516KwAQ5a6Y571+mgAQ54q25oCCbQIoubTmgLvmlLblhaV+dQBMubTluqboja/lk4Hph4fotK3ph496NAAg5Lit5oiQ6I2vnjEALmUAqpYAFOmXqOivigmcqjcAFOS9j+mZosI3AAluFdzCcQDOOgAs6K+K55aX5Lq65qyhenUBKUQJpcI3ABTlhoXnp5HGNwAEhL/ONwAU5Lit5Yy7zjoAFOWHuumZoiEQAJV+JgUI5pelKQ2GsAIs5omn5Lia5Yy75biIilkAHIC75bqK5L2NhisALOWMu+S/neaDheWGtXq/ASjms5Xkurrku6PooX4pBSzmiJDnq4vml6XmnJ96VgAhLQy5puiufi0BFOmZoumVv3pNABDlpIfms4KdABCcuuaehJabBSi8gOWPkei/m+W6pnp7ACzmmK/lkKbov5voja+SKwAo5YCN5aKe57uI56t+MQAI57uPhoEACOe6rIYlAAGgILSn5rig6YGT5+X1NOS4gAoo57uP6ZSA5ZWGCRQAKXrBAEpGAAS6jMY0AAS4iXo0ABxuZXdfY29kZXonAChwcm92aW5jZV9pZHoqAAxjaXR5iiYACG91bgUoHkIJ8Ex0aW1lOjEuMjc2MTU0MTdzLCBsb29wczoyNzUsIENvbmN1cnJlbmN5OjQJMy44Mjc3NzAyMzMxNTQyOTcgTUIJTi9BCjEJMzFfMTEJMBFVTGRhdGE6VGFibGVGdWxsU2Nhbl8xIrQJDXIgMTYwNDQxMDUyNnMA8E9jb3BfdGFzazoge251bTogMywgbWF4OiAxLjIwMTY0MzQ0OXMsIG1pbjogNDUwLjUxMjQzNm1zLCBhdmc6IDkzMi4wOTMxODZtcywgcDk1Oj45AExheF9wcm9jX2tleXM6IDEyMzg1OQUqThcACHRvdAUXAX8EMzkBqgxycGNfEZgBDAXNNCAyLjc5NjE0NTY3NHMsAcPYcl9jYWNoZV9oaXRfcmF0aW86IDAuMDB9CTE3My4zNTI3NTI2ODU1NDY4OCBNQglOL0EKMgkxMCEmBDFfOSohQgA6TtwKQCwga2VlcCBvcmRlcjp0cnVlMXoFkAQwbjVUGDAsIHRpa3YpUwB7AfolTwgzNzQhNBhtaW46MjAyAQsIcDgwERYIcDk1EQsoaXRlcnM6Mjg2LCAhlTBzOjN9CU4vQQlOL0EK] [error=“decode plan: (经销商编码), yl_test.pro_etms_institution.进货渠道编码二, yl_test.pro_etms_institution.进货渠道编码三, yl_test.pro_etms_institution.new_code, yl_test.pro_etms_institution.province_id, yl_test.pro_etms_institution.city_id, yl_test.pro_etms_institution.county_id\t279859\ttime:1.27615417s, loops:275, Concurrency:4\t3.827770233154297 MB\tN/A, depth: (经销商编码), yl_test.pro_etms_institution.进货渠道编码二, yl_test.pro_etms_institution.进货渠道编码三, yl_test.pro_etms_institution.new_code, yl_test.pro_etms_institution.province_id, yl_test.pro_etms_institution.city_id, yl_test.pro_etms_institution.county_id, error: strconv.Atoi: parsing “(经销商编码), yl_test.pro_etms_institution.进货渠道编码二, yl_test.pro_etms_institution.进货渠道编码三, yl_test.pro_etms_institution.new_code, yl_test.pro_etms_institution.province_id, yl_test.pro_etms_institution.city_id, yl_test.pro_etms_institution.county_id”: invalid syntax”]
[2021/04/14 09:41:04.489 +08:00] [ERROR] [distsql.go:1005] [“table reader fetch next chunk failed”] [conn=120] [error=“context canceled”]
[2021/04/14 09:42:24.814 +08:00] [ERROR] [distsql.go:1005] [“table reader fetch next chunk failed”] [conn=58] [error=“context canceled”] -
请问下使用什么方式部署的？ 麻烦介绍下集群拓扑，如果是 TiUP ，可以 tiup cluster display 展示。主要想看下实例是如何分配的，以及资源情况。
总结一下。业务上使用了 mybatis 并且是长连接，有很多的 prepare 语句。有很多相似 sql 使用了具体的值，并且混用了绑定变量。从 TiDB 看就是 session 一直在 prepare statment。尝试断开连接后内存逐渐释放。
- 建议业务上统一使用绑定变量，减少 prepare statment。
- 不知道 mybatis 是否可以调用 preparedStatement.close() 关闭不同sql （未尝试，一种猜测）。
是拼接sql导致tidb的sql模板一直增加，从而导致sql模板一直在缓存，然后内存就会持续上涨。
建议写sql时，使用动态参数，如 select * from table where a.id = ?
不能使用参数拼接的形式，如 String sql = "select * from table where a.id = "+“1111”
关闭和框架的意愿相违背，正确做法是规范sql语句。使用动态传参
好的，多谢总结。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。