【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5.2
目前库中很多表是varchar类型，但是开发不注意传进了int类型的值，导致隐式转换，索引失效。 ，特别是大表的单行更新，走了全表扫描。导致表死锁。堆积 tikv oom。 目前针对此类型的问题，有啥比较好的解决或者监控预警方式
程序端处理吧
类和表的字段映射好，比如java遇到这种就会报错
没什么好办法，看到慢查询执行计划有问题就让开发改
- 结合研发流程规范处理：JAVA、Golang 等编译时对变量类型不一致应该能前置发现
- 看你的版本的 7.5 ，也可考虑引入 TiDB 的资源管控，对这类 runaway Query 进行监控和自动识别：管理资源消耗超出预期的查询-runaway-queries，建议先做好调研和功能测试，看可否符合你的需求。
开发人员写代码时注意及DBA对慢SQL处理及时点，最好不要隐式转换，会降低性能的或不确定性
关注慢sql的告警，及时干预吧。
我理解这就是应该开发解决的问题，不然我数据库所有列都设计成 text 类型多好，能存字符串又很长，多好啊
这是开发规范的问题，不应该在数据库端做对应的处理。
在应用程序层添加类型检查逻辑，确保插入或更新的数据类型与数据库表中的列类型相匹配。
我目前版本是4.0.2，和你这种不一样，开发有些在字段上面做函数，又不能加函数索引。幸好这个查询的数量不大，十几秒也就不怎么处理了。
你这个，直接找开发改代码处理就行了吧，直接吧表死锁、tikv oom 截图。发到开发群里面。直接让对应开发整改。
多看看dashboard，肯定能看到的。。。
这个要开发修改代码，在传进来的varchar类型字段中加入’'单引号，避免出现隐式转换。
严格把控开发规范，数据库不可能什么都实现，最多就是提示SQL存在性能问题。
这肯定是改代码啊，严格把控一下
把控一下开发规范，SQL规范
这点和 mysql 兼容 
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。