一般来说合格的程序员都会在上线前对自己代码进行检查，避免全表查询或者返回大量数据。虽然简单，同时问题也是最低级的，但是却是常见也是最多的引起故障的原因。

在MySQL、PG的慢日志和Oracle的AWR、甚至Redis的慢日志中都能找到这些问题。但是很多问题就是不改也是常态。为了保护数据库不被无节操的SQL冲击成不可用，把问题降到最低，我们想办法做数据库过载保护。

在MySQL中：通过设置MAX_QUERIES_PER_HOUR 限制每小时多少次查询，我这里简单设置2，仅做展示。

这是会话级别的。

Oracle中如何做？答：概要文件。这里Oracle的内容比MySQL多一些。我这里仅展示每个user一次请求能使用多少CPU。

select PROFILE,RESOURCE_NAME,RESOURCE_TYPE,LIMIT from sys.dba_profiles where PROFILE='DEFAULT';

可以看到我这里仅分配了一个会话2个CPU和20个逻辑读。

把这个限制赋予账户。

效果如上图。直接踢出去。（谁让你不守规矩）

以上都是会话级别，有没有实例级别？有。

我设置了一个叫XXG的限制计划，把这个XXG给到PDB1的这个实例。这个限制是说这个数据库实例只能用到2%的CPU资源。

设置好CPU了，还有一个防线是IO。

我这里设置了每秒最大20个IO数据块和每秒最大5M的读写请求。

出现这些就说明IO被限制住了，只影响PDB1的资源消耗。其他不受影响。

结论：优先、强烈、推荐设定开发规范，并且遵守开发规范（主要是实现逻辑）。在这个基础上数据库是稳稳地很少会出问题。就像有时候有人问，这两个数据库能合并吗？怕（性能）出问题。

通常我就回答：您能遵守开发规范吗？能就可以，不能就不可以。

交通事故死的人不会因为交通工具一次承载的人多而多。飞机也会失事，但是比起5人的小汽车来说，还是安全多了。高铁一次16节车厢可能有2000人。但是很少出事。因为有规矩。

ITPub博客

Oracle的过载保护-数据库资源限制