从前辈们整理的数据库优化经验中得到的一点心得分享

     偶尔，会看到前辈们整理的数据库优化方面的文章，其中有些好理解，而下面这一条就需要咱们联系到B树,散列表结构才会感觉理论上可以讲得通了，当然有时我们最可靠的办法是实践，不过如果理论上也能理解，是不是更好一些..

     首先，我们知道数据库的索引能够带来查找速度的极大提高。这个过程中不仅要看你最后是否正确的运用了该索引，而且还取决于你当初建索引的策略。有些字段就不能建索引或者说建了索引也是徒劳的。什么时候建索引会适得其反呢？

     假设，我们已经对【性别】这种字段建立了索引，而用户数据有成千上万。这个时候，系统在索引时，由于大量的键对应的值大量相同，目前数据库主要采用B树和散列结构来组织数据，在树各个中间结点下面的叶子节点之间实际上组成了一个单向链表。这个单链表中的结点就是每个用户的信息包括性别,通过扫描链表，可以实现查找。类似的在散列表中，通过某种机制(散列函数)关联出存储地址.不过在假设的场景中，性别字段的值一般都只有2个，充其量加一个“未知",这才3个值。而用户却成千上万...散列函数几乎就形同虚设。于是形成了大量的散列返回值（地址）的冲突，散列出来的值也会以一种链表形式链接起来，只是头结点可能还在散列出来的地址上。这样一来，具体到某一个用户的性别，还得在这个超长的连接表上挨个找。

     上面就可以看出，咱们要是盲目建索引，到时不但浪费了空间，增加了工作量，还没能提高丝毫的查询速度..

     在这里，小弟还要请教一下各位：小型的网站中有没有或者有多少采用Sqlite数据库?这个轻型的数据库据论坛上说：性能至少比Access好.而且支持事务等等，对于一些处于费用考虑并且数据量不大的网站，用Sqlite会遇到什么问题呢？