很久没有写博客了，疫情期间大部分时间都是在家办公，能看出来公司线上活动业务迭代越来越快，快速的迭代一些新的线上活动产品也是适应疫情的环境。就在前两天基本没有接一些新的产品就继续了原来业务的开发，过程中就遇到一个问题java.sql.SQLException: Error writing file '/tmp/MYxcgCfo' (Errcode: 28 - No space left on device)，这个异常会报很多错，往上找就能找到这段报错信息，这个异常没有必要把所有的报错信息都贴出来，这样看不到重点，简单的翻译一下这句话的大概意思就是不能往这个目录'/tmp/MYxcgCfo写文件，原因是没有足够的空间。tmp这个名字看起来就感觉是临时表，mysql在执行一些查询等操作的时候有时候会生成临时表，这些临时表就会写入磁盘，当磁盘空间不足时就会抛出如上的异常，当然写入的大小一定是跟表中的数据大小成正比的。怎么看自己的查询语句是否创建了临时表，我们可以通过执行计划来看，我们是否使用来了临时表，详细介绍可以看我的文章sql优化，里面介绍了EXPLAIN结果的个个列的结果，看最后一一列extra就能看出来我们的sql是否使用了临时表。当我们知道了问题的原因，我们就可以去验证一下，由于我们测试服务器已经将磁盘里没有的东西删除了，这里就不截图展示了，当时msql的安装目录的磁盘占用率是100%。我们可以通过dh -f命令查看。所以这个问题很容易解决，可以修改mysql的配置文件，把目录改到磁盘空间充足的目录，然后重启mysql服务，我们当时这台服务器的两个几百G的目录使用率都是100%，所以就删除了一些文件，项目不用重启，直接就可以用了，问题就解决了。
随便说一个其它的小问题，我们开发连接数据库工具有很多SqlYog，navicat等一些软件，修改表字段，该字段大小等都喜欢通过工具修改，而不是通过语句修改，这就容易导致锁表，正常的查询操作都无法进行，昨天刚好有同事这样操作，导致我无法读取表的数据。
关于sql这个问题最早不是我发现的，前一天我还在家里办公的时候就已经有了，同事把自己的代码传上去，然后整个项目就报错了，同事还以为是他代码哪里有问题，直到我第二天去了公司使用了这台服务器的数据库才知道的，其实这个问题遇到了慢慢找就能找到原因，不要因为很多报错信息就看不下去，在解决问题的过程，也是你在积累经验的过程，就像前几天帮助前端同事找她js里的bug一样，慢慢看，顺着逻辑总会找到问题。
