一个并发SQL数据库卡主了

首先说明这个问题不能怪数据库。上周遇到一个事情，大家都在讨论一个问题，我看没人@我，我也没管。直到有人说，让我去看看她那里为什么查询的比较慢。在处理过程中才发现这个数据库上活动会话有80多个。难怪慢。背景是这个MySQL内存仅4G。（为什么这么小，我回答不了）

    看到红黄框一共10句，是一模一样的SQL，对一个log表全表排序。其中红框的两句几乎是同一时刻。后面的估计是执行了没反应继续点击。而蓝框中的SQL是对这个log表全表分组，其实性质一样。

     查一下现在事务情况，出乎意料。以上的全表排序都卡主了，那么问题很明显了。

先处理这些，kill这些执行了几个小时的SQL。过来几秒以后，整个数据库立刻恢复正常了。其他问题在这里不方便多说了。只是好奇这个全表排序的为什么有事务？

     单独找一个数据库，用MySQL默认的模式（自动提交），进行了几个大表查询，然后information.innodb_trx。发现没有事务。推断那时候一定是开启事务了。（故障恢复第一要务是先恢复，没有办法追溯是次要的。由于之前设定不完善，很多信息没有）这次就只能粗浅的认为查询开了事务，因为这个表600多M，10并发次查询，而内存就只有4G。加上磁盘的IO性能也不行。诸多因素在一起，然后并发执行数据库处理不了。通过杀掉长会话得以解决。

    这个配置，这样用，换哪个数据库可能或多或少都有点问题。也不排除个别数据库能抗过去的。还是使用方式方法。

    道理千万条，安全第一条。数据库几百种，规范第一条。开发不规范，运维两行泪。