蚂蚁金服有过一个自嘲的段子：能干翻支付宝的，除了监管就是DBA了。我本人虽然没有专职做多DBA，但是也是靠这个起家的。数字时代，数据是很多企业的核心资产，对于互联网/软件服务类企业更是如此。而负责保管这些数据资产的人，就是DBA（数据库管理员）。如果一个系统的数据库出了问题，压力最大的就是DBA。因为网络再好，应用再可以横向扩展、不管docker还是K8S，微服务也好、中台也罢。全部停摆了。
一般来说每5分钟DBA后面就多一个人，（问怎么还没恢复？还要多久？）每隔半个小时，身后的人官大一级。这个在我以前11年的公安系统工作经验中体会非常大。一堆警察围着我，然后科长来了，过会处长来了，还没好，最后局长来了。这种时候你还不能会诊，因为一人一个意见。所以非常忌讳东出一个主意，西出一个想法。最好的方式就是让处理问题的人静静的处理问题。他如果说要求助，那么就换人处理。指挥棒交给下一个。
当今时代硬件的安全程度和DBA的从业道德约束，很少有恶意删除数据的行为导致系统宕机。我经历的绝大多数的故障都是性能问题。工作快20年就偶发遇到过硬件问题导致核心数据库无法工作。概率5000:1吧。5000天有1次。而且我觉得随着硬件的发展，硬件层面会越来越好。而性能方面却防不胜防。对于一般系统（支付宝、微信不是一般系统）性能问题本来不是问题，但是在管理缺失的场景下会频繁发生。这个概率一天都能发生几次甚至十几次。
场景1：需求不合理。比如在我们14亿的人口库中查询一个身份证是非常合理的。但是如果说要查所有的男人，这就是不合理的。一次返回7亿数据，不是数据库做不到。是JVM等做不到。妥妥的OOM。当然数据库执行的也不会太快。
场景2：计算用户余额。select SUM(金额) from 流水表 where 用户代码=‘123’。每次用户看自己的余额，是把自己的历史交易全部回放一次。只会越来越慢。
场景3：非常多表关联。select a.xx,b.xx,c.xx from a,b,c where a.id=b.id and b.code=c.code 因为要显示的字段a表可以提供99%,只是缺一个字段必须由c表提供，但是a无法直接和c连接，必须引入b表。而这种场景可以不断扩展以至于一次连接需要a b c d 按照英语字面排序下去，最后一个是p。。。。。。
场景4：字段无限多。一个表500个字段，反正有需求就加。没需求也预留他个10-20个字段。万一以后有呢？至于将来需求是什么数据类型多大，也不管。统一字符型，最大值。
场景5：任意字段查询。
，希望安装一个数据库就来实现百度。这本身就不科学。输入 123，自动适配订单号、用户代码、商品编号、仓库号等等。还是前后%%。这个输入框包罗万象，百度和谷歌只返回一页20行，没有总页数，而且可以信息不准确。但是这个框要准确，还要总页数显示等等。这种即使是es也是全表，我试过的。（如果这样都很快，我也见过。数据量小于es任意节点的内存，能不快嘛）
场景6：任意字段索引。有人知道我们不是做百度的，不能前后%。每个字段都要去查询。所以列列是索引，在加上组合索引。索引比表大好多。
场景7：select * from a,b where a.id=b.id。 id无索引，其他无条件。如果a表1万数据，b表1万数据。那么最后返回1万数据，但是计算1亿次。4万万同胞是四亿。如果a表500万，b表500万。你算算。反正我见过执行半个月的
场景8：select * from a,b where a.id！=b.id。这里是不等于。有索引也救不了了。效果也是同上。
未完待续。当然以上场景都有破解之策。
