背景
1、产品的问题点
2、问题点背后涉及的技术原理
- 用户发起SQL, SQL按执行计划execute过程中消耗CPU、IOPS、存储带宽、网络带宽等.
3、这个问题将影响哪些行业以及业务场景
4、会导致什么问题?
- SQL执行计划异常(使得SQL更加耗费资源)、请求数暴增等发生时:
- 当资源够用时, 不会对业务有什么影响.
- 当资源不够用时, 将影响业务, 严重时雪崩.
5、业务上应该如何避免这个坑
- 可以设置用户、db、全局的 statement timeout.
- 不友好, 因为不能针对sql设置, 而不同的sql有的本身执行就很快(例如KV类查询), 有的本身就慢(例如复杂JOIN), 如果设置统一的语句超时值, 不能适应所有的sql.
- 效果较差, 甚至不可行. 除非在事务中针对每条SQL执行前设置statement timeout, 这样可以控制每条SQL的超时.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 在事务中针对每条SQL执行前设置statement timeout, 控制每条SQL的超时.
- 使得开发复杂度增加, 同时需要预估SQL的执行耗时,
- 一旦系统或业务变更导致SQL无法按原有预期执行完就会导致超时报错, 带入了人为故障的大概率.
7、数据库未来产品迭代如何修复这个坑
- 目的: 防止雪崩、防止某些业务或个人提交某些sql把资源耗尽.
- 期望: 内核支持:
- 比较理想的状态是和SQL执行计划评估出的代价挂钩, 可以用系数来进行设置, 如增加statement_timeout_cost参数, 例如代价和耗时为1000:1ms的关系, 那么代价是2500的SQL, 超时设置为2.5毫秒.
- 还有一种设置方法是白名单、黑名单方式: 在白名单中的SQL, 一对一的设置SQL的超时时间. 不在白名单中的SQL设置统一的超时、或者使用以上系数法.
- 除了超时, 实际上还可以通过资源消耗阈值来进行控制, 对于同样的query id的SQL, 在一个周期内, 限定其CPU timing 、IOPS 、存储带宽、网络, 这种方法与cgroup挂钩或者内部有rsq的功能来进行支持.
- 最后, 还可以按query id来限定QPS(例如sql1: qps上限10000, sql2: qps上线1000). 超出qps的请求进入队列, 队列超过一定长度后报错丢弃.