应用mysql读系统文件_通过数据库实现文件系统与直接使用操作系统的文件系统各有哪些优势和劣势？...

这是个很好的问题。

如果要抠字眼的话，首先要定义问题里面的第一个文件系统是一个什么概念。

一般的理解，这个文件系统是指实现了类似操作系统文件管理功能的文件访问接口。

那么操作系统对于文件系统来说，具体有那些接口呢？除了文件的创建，读取，修改，删除之外，文件系统实际上很重头，很核心的部分是对文件权限的访问控制，这一点在unix系统上非常明显，按照所有者控制，按照群组控制，文件是否可以修改，是否可以执行。等等这些，都在操作系统的控制之下。

可想而知，如果要在数据库上直接全部实现这些，其工作量是相当惊人的。

那么，问题里面所说的文件系统，更容易理解的实际上是一个弱化版本，即抛弃了权限控制部分，而只关注存储，检索，读取，删除这几个核心功能的实现。

这种情况下，在数据量比较小的时候，是没有什么问题的，数据库本身提供blob clob，实际上就是在操作系统上包装一下，变成一个流传递给客户端。把文件内容放到数据库里面，最大的优点是可以保证数据文件的安全性，可以直接使用数据库的安全机制来保护这些数据。而劣势则是速度和效率的损失，这个没办法，世界上的事情，总是有利有弊的。

作为数据库厂商来说，最推崇这种方案，毕竟对他们是最有利的。但如果是使用的开源软件，那么架构师必须考虑数据全部放到数据库里面的数据安全问题，一旦数据库文件损坏丢失，有没有合适的机制来进行恢复？如果没有开源产品支持，就只能自己开发了，这就是选择抛弃文件系统全部自己玩，必然带来的后期数据恢复的工作量和风险。

一般来说，作为风险厌恶型的技术选型，是不提倡把所有鸡蛋放到一个篮子里面的，一旦数据库崩溃，恢复的时间应当尽量短暂，而如果连文件也存到数据库里面，恢复的时间就会变得很漫长，而且很容易出错。

经历过数据库数据丢失损坏以后，对数据库这东西是要有风险机制的，因此一般不建议把数据文件存放到数据库里面去。

但有一种特殊情况，就是对数据的敏感性和安全性要求很高，要从逻辑上避免运维人员访问到数据文件，而强制要求只能通过数据库来访问，甚至数据文件在数据库内部也是经过加密的，这种刚性的需求就决定了只能使用数据库来进行存储，而由此带来的风险和困难则通过其他技术手段来规避掉。

总而言之，文件放数据库里面，可以大幅度提高数据文件的安全性，因为运维人员是不可见的，但需要利用数据库的安全机制，缺点是性能降低，复杂度增加。文件放文件系统里面由操作系统管理，逻辑简单，但运维存在泄密风险，管控要困难一些。

另外再说一下个人对使用mongodb来存储文件的看法。

使用mongodb来存储文件当然是可行的，gridfs，但这个方案也是存在风险的。第一，mongo存入文件以后，如何保证这个文件一定是有效的，可用的，这个需要额外写程序去确认。第二，在mongo失败崩溃以后，如何从备份中恢复，这个也会是一个难点。第三，使用mongo以后，由于mongo本身的安全机制很弱，如何细化用户管理，避免误操作带来数据损失，是需要额外进行考虑的问题。