关于 btree 和数据库索引的问题答案

【问题标题】：questions about btree and index to database关于 btree 和数据库索引的问题
【发布时间】：2011-05-05 04:03:21
【问题描述】：

我阅读了大量关于数据库的 btree 定理的文章。总有一些令人困惑的东西。
假设我有一个如下所述的表：
表用户信息：
（user_id为主键，用户名为字符串，密码为字符串）
如一些文章中所述，user_id 被创建为 userinfo 表的 index，如果我按索引 select 记录，我将获得有效的性能user_id 的.. 但是如果我按用户名 选择，据说它会一一排列行...... 我在 MYSQL 中尝试了这个，它没有预期的那么慢....
为什么？
mysql 如何处理这个选择？谢谢

【问题讨论】：

它没有使用索引，并且确实扫描了每一行。但是任何体面的数据库也会尝试优化扫描。 “没有预期的那么慢” 与 “与索引一样快” 不同，但是在非索引列上进行选择可能是有效的 &快足够。
@Wrikken:thanx for you Instant reply..oracle如何解决这个用户名选择问题，你知道任何表都不一定只有一列。
列的宽度通常是已知的，因此在特定字节偏移处扫描特定列通常非常有效（如果第一个字节不匹配，则丢弃该行等）。不同的数据库可能采用不同的策略。如果你真的想知道，mysql的来源是免费的，所以你有空浏览一下吧。甲骨文可能采用了很多相同的策略。我自己很满意知道如何作为最终用户使用它，这里不需要了解实现的细节:)
@Wrikken 所说的，另外：对于小表，表扫描可以比索引访问更快。对于足够大的表（当表中有数百万行时），索引访问通常更有效，但这取决于查询。按用户名进行索引查找会更快 - 扫描用户名列表可能能够使用仅索引扫描（如果索引存在）。
我会建议使用更丰富的问题标题

标签： mysql database indexing b-tree

【解决方案1】：

如果您的 WHERE 子句按用户名（未编入索引）进行比较，它可能会进行全表扫描。但是，如果表中的行数很少，这可能仍然很快。如今，计算机的速度非常快，数据库在组织数据以进行高效的表扫描方面非常聪明。

【讨论】：

thanx...如您所说，它会扫描所有行以匹配 where 非索引条件，但如果我有数十亿条记录，并且用户名字段未按字母顺序插入。连续扫描可能很耗时，有没有办法获得高性能......？谢谢
如果您要对列进行比较并且有很多行，请考虑添加索引。