以下内容整理自: 地址: https://juejin.im/post/5b55b842f265da0f9e589e79
作者 :Java3y
MySQL的基本存储结构是页(记录都存在页里边):
所以说,如果我们写select * from user where indexname = 'xxx'这样没有进行任何优化的sql语句,默认会这样做:
很明显,在数据量很大的情况下这样查找会很慢!这样的时间复杂度为O(n)。
索引做了些什么可以让我们查询加快速度呢?其实就是将无序的数据变成有序(相对):
要找到id为8的记录简要步骤:
很明显的是:没有用索引我们是需要遍历双向链表来定位对应的页,现在通过 “目录” 就可以很快地定位到对应的页上了!(二分查找,时间复杂度近似为O(logn))
其实底层结构就是B+树,B+树作为树的一种实现,能够让我们很快地查找出对应的记录。
以下内容整理自:《Java工程师修炼之道》
MySQL中的索引可以以一定顺序引用多列,这种索引叫作联合索引。如User表的name和city加联合索引就是(name,city),而最左前缀原则指的是,如果查询的时候查询条件精确匹配索引的左边连续一列或几列,则此列就可以被用到。如下:
select * from user where name=xx and city=xx ; //可以命中索引 select * from user where name=xx ; // 可以命中索引 select * from user where city=xx ; // 无法命中索引
这里需要注意的是,查询的时候如果两个条件都用上了,但是顺序不同,如 city= xx and name =xx
,那么现在的查询引擎会自动优化为匹配联合索引的顺序,这样是能够命中索引的。
由于最左前缀原则,在创建联合索引时,索引字段的顺序需要考虑字段值去重之后的个数,较多的放前面。ORDER BY子句也遵循此规则。
冗余索引指的是索引的功能相同,能够命中 就肯定能命中 ,那么 就是冗余索引如(name,city )和(name )这两个索引就是冗余索引,能够命中后者的查询肯定是能够命中前者的 在大多数情况下,都应该尽量扩展已有的索引而不是创建新索引。
MySQL 5.7 版本后,可以通过查询 sys 库的 schema_redundant_indexes
表来查看冗余索引
1.添加PRIMARY KEY(主键索引)
ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )
2.添加UNIQUE(唯一索引)
ALTER TABLE `table_name` ADD UNIQUE ( `column` )
3.添加INDEX(普通索引)
ALTER TABLE `table_name` ADD INDEX index_name ( `column` )
4.添加FULLTEXT(全文索引)
ALTER TABLE `table_name` ADD FULLTEXT ( `column`)
5.添加多列索引
ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )
问题内容: 我需要知道abt在mongo中的索引如何提高查询性能。并且当前我的数据库没有索引。如何索引现有数据库?我是否还需要创建一个仅用于索引的新字段? 问题答案: 从根本上说,MongoDB中的索引类似于其他数据库系统中的索引。MongoDB支持MongoDB集合中文档中包含的任何字段或子字段上的索引。 索引在这里详细介绍,我强烈建议您阅读本文档。 其中包括有关索引操作,策略和创建选项的部分,
问题内容: 我有一个查询,在我认为可能不使用索引的情况下,出于好奇,我将其重现: 创建一个具有1.000.000行(在中有10个不同的值,在中有500个字节的数据)的。 创建一个索引并收集表统计信息: 尝试获取和的不同值: 不使用索引,前提是提示不会更改。 我想在这种情况下不能使用索引,但是为什么呢? 问题答案: 我运行了Peter的原始内容并复制了他的结果。然后我应用了dcp的建议… 之所以如此
我正在数据库中运行以下查询: 它输出500行,其中只有一个结果列,运行大约需要1分钟43秒。输出以下计划: 逻辑是:对于每个选择的(在500个id的列表中)计算整数列,返回该金额与数字2147483647之间的较小值。结果必须包含500行,每个id对应一行,我们已经知道它们将与子查询中的至少一行匹配,因此不会生成空值。 索引仅是上的一个b树,属于整数类型。索引是主键上的b树,也是整数类型。表中的每
问题内容: 我有一个表,其中列上有部分索引。 如果我执行简单查询,则使用索引: 但是如果我使用它进行查询,则不会使用索引: 为什么在第二种情况下不使用索引?有什么办法可以加快这个查询? (请注意,在此示例中,我已截断了数组,并测试了更多元素,但结果却相同,缓慢) 问题答案: 实际上,它 正在 使用索引。只是做不同的事情。 索引扫描一行一行地访问,以随机顺序从一个磁盘页面到下一个磁盘页面来回移动。
问题内容: 我有2张表,如下所示: 当我解释查询时: postgres给我这个: 过了一会儿给我这个完全相同的查询(仍然不使用索引): 我的问题是:如果我仅按构成唯一索引的st值和类型值进行过滤,为什么不使用此唯一索引? 问题答案: 您的表没有足够的行来使用索引。它们适合放在单个磁盘页面中,因此使用cpu时间读取整个内容并筛选出行要比两次执行同一操作(一次用于索引,另一次用于数据)要快。
问题内容: 有人愿意帮助我吗?在具有10000行的MEMORY表上,以下查询大约需要18秒。如果我没有“ where”约束,则只需不到一分钟的时间。我已经打开查询缓存以及将其作为准备好的语句来尝试。有什么我可以做的吗?索引还是什么? 问题答案: 我认为这将为您提供所需的信息,而不管您关注的滚动日期范围…我已经通过创建带有两个标识列的自己的“发票”表进行了测试。使用@mySQL变量实际上非常简单,可