点击蓝色“有关SQL”关注我哟
加个“星标”，天天与10000人一起快乐成长
图 | 榖依米 | 三亚
平时运行极快的 SQL，突然某天不灵了。连续执行3,4遍，都巨慢无比。此时，向天磕头，与地求救，都不如责问 session.
究竟是谁在动我的数据库？
很多朋友，尤其那些不关注我的朋友，或是看了我的文章，没有动手加个星标，基本是不会知道了。太替你们可惜！
Y 姐是我们小组的女神，172的个头，修长的身段，尤其妙如天籁的好声音，长期霸占 SQL 开发女神首榜。女神要有点啥问题，全组男生当然是倾巢出动，不论是做 ETL 的，还是做报表的，连前端的鲜肉哥哥都要来刷下存在感。
当然， Y 姐碰到的问题，并不是谁次次都能解决的。简单的问题，资深的前端也能修复；而稍深点的问题，小哥哥们就尴尬了。有的看完问题，说要查查百度，有的看完，如有所思，说道自己曾经也遇到过这样的问题，改改参数，就解决了，但改哪里，记不起来了。
我最喜欢看这些小哥哥红着笑脸，长叹而去的样子。年轻人的羞涩，就像是一部很好的时光穿梭机，有谁真正讨厌看到自己昨天的样子？
“今天的UAT， SQL 执行好慢，小C，你也是这样吗” Y 姐侧向小C，喃喃低语。
“是啊，平时贼快的语句，刚才等了10来秒，就返回 6 条数据哈”小C也挺着急。
“数据库又崩了，是不是测试组又在搞压力测试，上周他们做过一回，搞得我们页面全卡了。” 这位 95 后小 Z，平时最热衷各式技术话题，不管前后，对他来说，一锅端。
“我问过测试组，他们没测，今天” 小C耷拉着脑袋，很迷惑。
“那怎么办呢？我这条SQL语句也很简单啊，两张表 Join, 拿的字段都在索引里，平时秒出。”
“没办法咯，要么等，要么问问 L 吧。” 小C朝我座位方向瞅了一眼，“L今天喝过星巴克了，应该没有太多活。我们一起去问问”
听了 Y 姐的简单描述，我知道我的黄氏三板斧绝对可以派上用场，但又不忍心，这些繁琐的技术细节去骚扰女神的三千青丝，怜香惜玉不仅仅是楚留香才有。
但本着技术人的负责，我最终还是要把原理告诉 Y 姐和小 C，最终她们愿意接收还是放弃，那都是她们的自由了。
“你的 SQL 跑得很慢，但是没出错，说明你的 SQL 写得正确。但数据库此时的响应不够快，你怀疑有大量的 SQL 程序 同时在跑。那么我们只要对数据库做监控，就知道都有谁在上面跑程序了”
“这监控该怎么做呢？要写c代码，还是c++”
"没那么复杂，我们不开发底层。还是用 SQL 就可以了。数据库会给每条 SQL 一张门卡，这张门卡很特殊，上面有唯一标识符，且实时地被监控头检测到。带着门卡的 SQL，它所做的每一次动作，包括执行 insert, delete, update, 甚至是 alter, 都会记录在监控室。假如我们怀疑某条 SQL 做了不合理的操作，到监控室调下录像，就全知晓了。"
“那怎么去调用这些监控录像呢？”
“不急，我再说说，怎么分发这些门卡。有些门卡是由管家自动分配的，而有些门卡有特殊待遇，能开启特别的通道，当然监控的方式就更不一样。所以需要特别的设置。有了这两个分类，我们就知道看什么样的信息，去什么样的监控室了”
“比如进门，出门是简单的普卡；而参观藏品，就需要非标卡。在藏品室内，每个举动都会被录像记录，还有可能需要保存一段时间，所以对于监控成本也很高，不会给一般SQL。”
“L，你说那么多，都被搞晕了。能不能简单粗暴点，直接帮我们解决问题？” 小C虽然有点婴儿肥，但性子还是比较急。
“其实原理讲差不多了，如果不想自己写代码，做精确控制，那我们打开 SQL Profiler 就能看到当前在数据库服务器上的所有人了。如果人多的话，自然你的 SQL 也就慢咯”
“这么好用的工具，又学了一招” 年轻的小C，脾气来的快，也去得快。
--完--
往期精彩：
134
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
