对索引存储与散列存储的一些形而上的思考

场景

对于数据库大表，为了加速期查询速度，往往在外键上加索引、Java集合类中HashMap使用的很频繁等等，而对于索引存储与散列存储的理解鄙人一直不清晰。

问题

索引存储与散列存储怎么理解

分析

房间比作存储单元，房间号比作存储单元地址。问题来了，如何快速在一家酒店找到自己的灵魂伴侣呢？这里先假设她（或者他）肯定在某一房间内，身份证作为关键字，你只知道她的身份证号码，长啥样你不知道。首先，数据的存储方式决定其查找方式：

你就只能拿着身份证号码一层一层一间房一间房去找了：费劲啊，时间复杂度n/2；这里应该还涉及到数据安全问题:你不一定又钥匙，她也不一定相信你，让你比对身份证号码。

相对顺序存储，链式存储对存储空间的物理位置没有要求:假设酒店有10间房子，顺序存储要求10间房子物理位置相邻，而后者10间房可以分散在不同层且不相邻。查找时间复杂度:n/2―还是得拿着身份证挨房去查找。

存的时候比较费劲，除了存储节点本身信息外还得花费额外空间建立，存储并维护索引表（个人理解，索引存储应该属于顺序存储与链式存储的一种：节点位置要么相邻要么不相邻）。这时只要根据灵魂伴侣的身份证号码，查表（怎么查呢，得看怎么存储，递归），就可以知道她在那间房了，狠开心。时间复杂度：常量级。空间复杂度：比顺序链式要高。

根据身份证通过散列函数直接算（而不是查表）出她的房间号。时间复杂读：常量级。其他（待了解）：由于用到散列函数，需要额外计算单元支持。

总结

散列或者索引存储是为了提高查询效率，而在存储数据的时候，除了节点实际数据，还存储了其他提高查询数据效率的因子（表，计算单元，或者其他）

 注：以上只是鄙人看书时的一些猜想，停留在理论，有待后续做实验进一步分析论证。

参考文献

2014版数据结构《高分笔记》率辉-著