只会写SQL，不懂得这五个影响数据库性能的要素，那就等着背锅吧

01，导读

很多时候，专职写SQL的工程师往往要背数据库性能差劲的锅。无论你的SQL写得多漂亮，业务实现的多么天衣无缝，多么复杂的ERP BOM 逻辑，多么灵活的排班结构，只要用户反映系统慢了，多少人都会把球踢给写SQL的，冤不冤？碰上不懂行的技术经理，恐怕你的年终奖都没有了。

那么，有没有办法说服你那蹩脚的技术经理呢？有，平时多给他强调五点，千万不要出了事再说，一定要在平时多敲敲他的脑袋，给他洗洗脑子。性能这种事情，对于外行，只能一直说，临时说就容易被扣上嘴犟的口舌。

就像你要搞垮一个人的信誉一样，一直说，天天说，大家自然就认为那人真不行。实际，可能只是人性的恶使然，我鄙视一切这样的行为，但你们也要防止被别人算计，毕竟人在江湖漂，谁是君子，谁是小人，真说不定的。

同理，你天天跟别人说，性能问题可能有1,2,3,4,5，真到出系统性能问题的时候，大家就不会一直怀疑是SQL的问题了，而是沿着你给出的框架在分析，直到最后，虽然有可能还真是SQL出了问题，但至少严谨得多，矛头不会立即指向你。

02，五大数据库性能杀手

workload(业务量）指的是对数据库的总体访问请求数量。可以是在线事务，跑批任务，即席查询，数仓分析和维护期任务。业务量的增加不是一日之功，不可能系统刚上线就来个12306的流量，日益增长的访问量在悄然无息中就来了。刚上线面对1000用户，系统支撑没有问题，一旦业务扩展的很快，等到50万用户的时候，之初只考虑10万用户的设计就顶不住了。此时，就断不能说SQL写得有问题了。

怎么办，平时做好流量监测！

Throughput(吞吐量) 指的是软硬件作为整体可以处理的数据大小。影响 throughput 的要素就多了，有 I/O 速度，CPU, 内存，网络等硬件，有 DBMS, 操作系统等软件要素。这些统称为系统的 resource(资源)

多大的锅养多少张嘴，多好的软硬体养多少体量的数据！

第四道坎才是SQL人的，那就是 optimization(优化). 这里的优化就是纯软件了，操作系统的参数配置，数据库参数配置，SQL 写的优劣，索引建的是否得当，等等。 责无旁贷，如果前面两项都没有异常，这一步就显得很重要了。

练好SQL是第一步，了解数据库优化原理是进阶！

Contention(竞争)，当业务量增大时，必然导致竞争激烈，毫无疑问。比如刚开始我们的英语微信群人少，少数人说话，大家看的来；当这两天徒增至230人时，一会儿一个话题，我想要再抓细节，很多都跳过了。数据库系统也一样，写的人越来越多，读的人越来越多，对 I/O 的考验就激烈了。窗口就那么大，说话人那么多，我再想找感兴趣的话题，就要往上翻好久。这样效率就慢了！

竞争多了，就要扩大池子，比如读操作多了，就要扩展缓存；写操作多了，就要横向增加机器，引入分布式系统。

03， 优雅的甩锅

技术人往往都是蒙头干活的思维，被人一说有bug,性能慢，从不反驳，自己默默找原因去了，从来不视图改正下别人错误的观点。有可能别人是盲目的，并不知道如何排除性能问题，更有可能是江湖人，专门给你捣糨糊，巴不得老要你背锅，好让领导产生XXX就是不行，其司马昭之心，不可不防滴！

以上为你列好了 5 条，记得平时工作中遇事不方，有条不紊的告诉你的队友们，可能哪些步骤出了问题。不要一个劲儿的瞎背锅！