欢迎访问个人博客站点: 配置啦

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

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

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

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

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

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