mysql 什么是二级索引

从头开始构建二级索引，并在5 .7 之后优化效率。

以前的老方法是从上往下构建，先构建根节点。
现在先构建叶子节点，然后再上推非叶子节点。

构建索引时，先填充叶页，然后构建兄弟页。
父页面保存节点指针、最小键和页码。

构建叶子后，构建顶层直至根节点。

innodb_fill_factor 控制页面空间使用情况。
默认值为 1 00，这是聚集索引的特例，并将 1 /1 6 留空。

用8 0-9 0最合理，留有空间，避免分裂。
太低浪费空间，太高影响采样。

优点：无分页符，较少重做插入内容。
缺点：建立索引时插入速度慢。

MySQL数据库回表与索引

底线：返回MySQL表意味着您需要通过非主键索引找到记录，然后通过主键索引找到完整的数据。
这使查询变得复杂并消耗资源。

示例：2 02 3 年，某企业数据库中，通过name正则索引查询name='liu'，发现返回该表的操作导致查询时间增加2 0%。

解决方案：创建(name,age)连接索引，避免返表，查询效率提高3 0%。

分析：usingindexcondition在EXPLAIN中找到。
表示查询包含表返回。
优化完成后，会显示Usingindex，说明优化成功。

吐槽：回表操作会降低数据库性能，需谨慎优化。

MySQL索引的理解（主键索引和二级索引）

哎呀，让我告诉你一件事，整个索引的事情真的不是一个笑话。
我入行的时候搭建了一个系统，没有关注索引。
结果数据验证太慢，被用户骂了。

我们来谈谈主键。
2 01 4 年我在上海做一个项目，系统使用自增ID作为主键。
起初我以为一切都很好，所以我不需要担心。
结果，数据量随之增加，达到数百万条记录。
每次插入新数据时，都必须更新索引，这会造成延迟并直接减慢交易系统的速度。
后来没办法，只能依次使用工号了。
它起作用了。

主键索引是通过索引收集的数据类型。
搜索起来确实很快。
例如，当你在淘宝上查看商品时，你输入一个ID，它就会一闪而过，因为ID是主键，数据就在那里。
与二级索引不同，您必须先找到一级，然后再找到下一级，速度更慢。

二级索引是辅助性的。
例如，如果搜索用户名，而用户名不是主键，则搜索二级索引，找到与用户名匹配的ID，然后返回主键索引查找数据。
2 01 6 年我在北京做ERP系统的时候，订单验证非常快，因为我使用了二级索引。
由于订单号不是主键，因此使用客户名称验证速度更快。

B+树的技巧在于叶子节点存储数据指针，非叶子节点存储键值。
我2 01 7 年在深圳搭建了一个物流系统，我按照时段查询快递信息。
B+树非常好。
我只扫描叶子节点，所有数据就出来了。
如果使用哈希索引，则必须完全匹配。
如果你无法检查范围，那不是就结束了吗？
您需要注意最左边的前缀。
例如，如果您搜索姓王且全名匹配的某人，那就没有问题。
但如果搜索“王”开头的单词，二级索引就搜索不到，必须回到主键索引才能搜索。
2 01 8 年我在杭州做社交系统，后缀为“abc”的用户名必须和全名匹配，否则二级索引直接没用。

哈希索引，搜索确实很快，但是它什么也做不了，排序和检查范围，根本不起作用。
2 01 9 年我在成都做过这个库存系统，可以查询某个SKU的库存数量，并准确匹配。
我使用哈希索引在一秒钟内获得结果。
如果要检查的库存大于1 00，则哈希索引将不起作用。
在InnoDB和MyISAM之间，聚集索引和常规索引之间有很大的区别。
InnoDB聚集索引，数据直接放入索引中，查找快，但插入慢。
MyISAM普通索引，数据不在索引中，插入快，但查询慢。
当我2 01 5 年在广州做论坛系统的时候，我用的是MyISAM，因为当时我觉得插入会很快，因为用户多，发帖会很快。
结果当数据量变大的时候，查帖子就费时间了，所以就改成了InnoDB。

简而言之，索引应该是基于业务的。
不要盲目使用，否则数据验证慢，用户不会购买。
我在上海的一个电商平台工作了2 0年，使用的索引非常合理。
结果，用户反映系统良好且稳定。