在WEB开拓中常常会碰着写文件的环境，最常见的莫过于生存图片文件。假如是文件数量不多，那我们完全没有须要担忧其效率问题。可是当你有大量的用户，大量的图片的时候，我们怎么存储图片文件，就会直接影响整个图片存储系统的效率。
凡是，有一种说法是：如1个目次下有10000个子文件，那么读取某个文件的速度将会明明下降。那这种说法到底正确不正确呢？下面我们来看一下：
问：为什么单目次下子文件过多会影响机能?如1个目次下有10000个子文件，那么读取某个文件的速度将会明明慢下来?这和文件索引有关吗?索引中如何组织这些节点?
答：是的，与索引有关。1w个不算多。上百万个就看出来了。可是发起不要高出10000个。
问：上百万个慢是文件系统整体吧，那么和当前目次怎么干系上呢?一个差不多的文件系统支持几百万个文件不算什么
答：我是说一个目次下，不分子目次，直接放他几十万上百万的文件，此时检索这个目次索引很费资源。
支持数量有限是因为目次这个工具自己容纳的巨细有被限制，目次就是一个容纳文件名和文件对应inode号的容器，被限制了，那么容纳的条目也就被限制了。
读取某个文件速度没影响。可是查找就费劲了。某些文件系统的索引机制不完善，甚至没有什么优化算法，致使每次查找淹灭更多的时间。
从上面的问答我们可以知道，“如1个目次下有10000个子文件，那么读取某个文件的速度将会明明下降。”的说法是对的。那如何分目次呢？
其实也较量简朴，可以按月份分，hash分，时间加hash组合分，至于用哪种要领，那就要看你的项目需求了。。。
