- 综合排序
- 最热优先
- 最新优先
- 来自专栏技术一号位指南(小诚信驿站)
系统设计：索引
如果有人跟你谈索引，是不是你会第一时间想到数据库，那么索引解决了什么问题？比如查询SQL慢了，发生这种情况时，首先要做的事情之一是查看是否慢SQL走了数据库索引。 因此，当我们在表的列上创建索引时，我们将该列和指向索引中整行的指针存储在索引中。 索引是实现这一点的最佳方法。 索引为什么会降低写性能？ 索引可以极大地加快数据检索速度，但由于额外的键，索引本身可能很大，这会减慢数据插入和更新的速度。 题外笔者补充 谷歌系统设计指南指定了我们说的索引的好处和坏处，那么其实深层次去思考，索引是解决的读问题，数据存储是解决的写问题，而在我们设计系统，中间件的过程中，你会发现大量的设计都是读写分开的，比如写磁盘是顺序写 所以是否使用索引的目的在于我们进行权衡，索引是否对我们有帮助，如果只有一条数据记录那么没有索引也可以。如果数据非常庞大，构建了很多冗余索引那么无疑是给我们写入的性能增加了难度。
1.5K61发布于 2021-08-26 - 来自专栏圣杰的专栏
索引设计指南
Sql Server索引设计指南——脑图链接 参考资料： SQL Server 索引设计指南 Clustered and Nonclustered Indexes Described
36820发布于 2019-09-12 - 来自专栏爱可生开源社区
第21期：索引设计（函数索引）
本篇主要介绍 MySQL 的函数索引（也叫表达式索引）。 通常来讲，索引都是基于字段本身或者字段前缀（第 20 篇），而函数索引是基于字段本身加上函数、操作符、表达式等计算而来。 如果将表达式或者操作符也看做函数的话，简单来说，这样的索引就可以统称函数索引。 MySQL 的函数索引内部是基于虚拟列（generated columns）实现，不同于直接定义虚拟列，函数索引自动创建的虚拟列本身实时计算结果，并不存储数据，只把函数索引本身存在磁盘上。 函数索引替代前缀索引？ 之前讲过前缀索引，可能会有这样的疑问。前缀索引能不能被函数索引替代？当然是不行的！ 下面例子用来模拟下是否可以用函数索引替代前缀索引。示例表 t3，一个前缀索引和两个函数索引实现的目的一样，但是实际查询的时候 SQL 语句并不一样。
87210发布于 2021-02-26 - 来自专栏爱可生开源社区
第20期：索引设计（前缀索引）
这里主要介绍 MySQL 的前缀索引。从名字上来看，前缀索引就是指索引的前缀，当然这个索引的存储结构不能是 HASH，HASH 不支持前缀索引。 先看下面这两行示例数据： 你是中国人吗？ 那面对这样的数据，我们该如何建立索引呢？ 大致有以下 3 种方法： 拿整个串的数据来做索引 这种方法来的最简单直观，但是会造成索引空间极大的浪费。 把前面 6 个字符截取出来的子串做一个索引 能否不拆分字段，又能避免太多重复值的冗余？我们今天讨论一下前缀索引。 前缀索引 前缀索引就是基于原始索引字段，截取前面指定的字符个数或者字节数来做的索引。 举个简单例子，表 t1 有两个字段，针对字段 r1 有两个索引，一个是基于字段 r1 的普通二级索引，另外一个是基于字段r1的前缀索引。 select count(*) from t1 where r1 like 'sa%'； # SQL 6 select count(*) from t1 where r1 like 's%'; 那可否设计一个合适的前缀索引来让以上
72920发布于 2021-02-01 - 来自专栏码上遇见你
MySQL索引设计原则
MySQL索引的设计原则： 索引设计原则一： 针对sql语句中的where,order by,group by条件设计索引。 并且注意where,order by,group by后面跟的字段的顺序，是不是某个联合索引的最左侧字段开始的部分字段 索引设计原则二： 需要考虑字段基数的问题,一般建立索引尽量使用那些基数较大的字段， 索引设计原则三 尽量对那些字段类型较小的字段来设计索引。 对于前缀索引，仅仅包含部分字符到索引树中，where查询是可以使用的，但是order by和group by就用不上了 索引设计原则四 设计索引需要考虑到数据插入更新时索引树也会进而更新，以及主键一定要是自增的 避免数据稀疏造成频繁的页分裂，其次就是索引不要设计的太多，毕竟维护成本较高，也占用磁盘，还有就是插入的数据不是按照顺序来的，从而会导致某个索引树里的索引页自动分裂这就会很浪费时间 总结： 简单来说建立索引需要考虑的点主要一下几个方面
31420编辑于 2023-06-28 - 来自专栏IT技术精选文摘
MySQL索引设计概要
在关系型数据库中设计索引其实并不是复杂的事情，很多开发者都觉得设计索引能够提升数据库的性能，相关的知识一定非常复杂。 本文会介绍 数据库索引设计与优化 中设计索引的一些方法，让各位读者能够快速的在现有的工程中设计出合适的索引。 索引的设计 作者相信文章前面的内容已经为索引的设计提供了充足的理论基础和知识，从总体来看如何减少随机读取的次数是设计索引时需要重视的最重要的问题，在这一节中，我们将介绍 数据库索引设计与优化 一书中归纳出的设计最佳索引的方法 总结 在单表上对索引进行设计其实还是非常容易的，只需要遵循固定的套路就能设计出一个理想的三星索引，在这里强烈推荐 《数据库索引设计与优化》 这本书籍，其中包含了大量与索引设计与优化的相关内容；在之后的文章中读者也会分析介绍书中提供的几种估算方法 ，来帮助我们通过预估问题设计出更高效的索引。
1.8K60发布于 2018-01-30 - 来自专栏爱可生开源社区
第26期：索引设计（索引下推）
索引下推（INDEX CONDITION PUSHDOWN，简称 ICP）是 MySQL 5.6 发布后针对扫描二级索引的一项优化改进。 MySQL 索引扫描：根据指定索引过滤条件（比如 where id = 1) ，遍历索引找到索引键对应的主键值后回表过滤剩余过滤条件。 4. MySQL 索引过滤：通过索引扫描并且基于索引进行二次条件过滤后再回表。 ICP 就是把以上索引扫描和索引过滤合并在一起处理，过滤后的记录数据下推到存储引擎后的一种索引优化策略。 ，再在这个区间的记录上使用包含索引键的其他过滤条件进行过滤，之后规避掉不满足的索引记录，只根据满足条件的索引记录回表取回数据上传到 MySQL 服务层。 主键索引本身即是表数据，不存在下推操作。 4. ICP 不支持基于虚拟列上建立的索引，比如函数索引。 5. ICP 不支持引用子查询的条件。
65330发布于 2021-04-23 - 来自专栏爱可生开源社区
第31期：索引设计（索引数量探讨）
一般提到索引，大家都只关注索引的优点，一个优秀的索引的确会让查询请求的效率大幅提升、亦或是大幅提升带有索引键进行过滤的写入请求（update、delete)效率。 为了维护索引数据的准实时性而让优化器基于索引做出更优化的执行计划，数据库会自动更新索引数据分布，比如带来索引页的拆分与合并等。 那索引的存在对写入请求影响到底有多大？ 这里用来测试索引数量的表有 10 个，分别为 t1 到 t10 ，除了每张表索引数量不一样外，字段定义等都一样：t1 有 1 个索引，t2 有个 2 个，依次类推，t10 有 10 个索引，字段类型都是整形 （索引数量不包含主键，只包含二级索引）。 从以上简单测试结果可以得到， 新增一个索引，就会导致额外的写入时间消耗。在写入优先的业务中，索引并不是越多越好，最好是保留必要的索引，删除掉不必要的索引。
30220发布于 2021-07-16 - 来自专栏爱可生开源社区
第17期：索引设计（主键设计）
InnoDB 表是索引组织表，主键既是数据也是索引。 主键的设计原则 1. 举个例子，假设武汉市每个区都有自己的医保数据，并且以前每个区都是自己独立设计的数据库，现在医保要升级为全市统一，以市为单位设计新的数据库模型。 那基于原始表 ID 与原始表名的映射关系建立一个多值索引。 可以新建一个自增主键或者 uuid_short() 函数字段，实际业务字段非主键设计，变为普通唯一索引。 但是如果有与业务不相关的主键，只需要更改业务字段（二级索引）就可以，不需要更改依赖这张表的子表。 关于 MySQL 主键的设计思路大致介绍到此，有问题欢迎留言，欢迎指正本篇任何不足之处。 ----
70110发布于 2020-12-14 - 来自专栏爱可生开源社区
第29期：索引设计（监测全文索引）
接着讲 MySQL 全文索引，这篇主要探讨 MySQL 全文索引的监测。 MySQL 有很完整的元数据表来监测全文索引表的插入，更新，删除；甚至全文索引表以及辅助表的数据追踪。 第一部分， 全文索引监测相关参数： innodb_ft_aux_table ：动态设置被监测的全文索引表名。这个参数必须显式设置，才能对全文索引正常监测。 innodb_optimize_fulltext_only ：默认关闭，不整理全文索引，设置为 ON ，则只整理全文索引。 第二部分，全文索引数据监测元数据表： MySQL 目前提供以下字典表，用来监测全文索引信息 INNODB_FT_CONFIG ：存放全文索引元数据以及相关内部处理数据。 快照表数据停留时间非常短，要想观测这张表数据，得准备一张非常大的全文索引表。 第三部分，全文索引监测演示： 1、建立一张示例表ft1.
59020发布于 2021-06-16 - 来自专栏爱可生开源社区
第28期：索引设计（使用全文索引）
上一篇介绍了全文索引的基本原理，这篇来讲讲如何更好的使用全文索引。 全文索引的检索和普通检索的语法不同，普通检索一般类似下面SQL： select * from tb1 where id in (1,2); select * from tb1 where id < 10 ; 过滤条件在WHERE子句后面，以一定的方式来拼接SQL，全文索引的使用有特定的语法： MATCH (col1,col2,...) DEFAULT NULL, `s3` text, PRIMARY KEY (`id`), KEY `idx_log_time` (`log_time`) ) 现在给表fx字段s1建立全文索引 ，后面会继续讲解如何提高全文索引结果的准确性以及全文索引的优化与中文插件的使用。
71930发布于 2021-06-16 - 来自专栏爱可生开源社区
第16期：索引设计（MySQL 的索引结构）
上一章（第15期：索引设计（索引组织方式 B+ 树））讲了数据库基本上都用 B+ 树来存储索引的原因：适合磁盘存储，能够充分利用多叉平衡树的特性，磁盘预读，并且很好的支持等值，范围，顺序扫描等。 MYISAM，memory 等引擎的表索引都是非聚集索引。简单点说，就是索引与行数据分开存储。一张表可以有多个二级索引。 INNODB 表这样设计的优点有两个： 1. 数据按照主键顺序存储。主键的顺序也就是记录行的物理顺序，相比指向数据行指针的存放方式，避免了再次排序。我们知道，排序消耗最大。 二级索引由于同时保存了主键值，体积会变大。特别是主键设计不合理的时候，比如用 UUID 做主键。下一篇我详细介绍如何设计合理的主键。 2. 对二级索引的检索需要检索两次索引树。 本篇主要介绍 MySQL 常见的两种引擎 MYISAM 和 INNODB 的索引组织方式以及各自的优缺点。有问题欢迎批评指正，下一篇我来介绍 MySQL 如何很好的对主键进行设计。
93720发布于 2020-11-19 - 来自专栏格姗知识圈
MySQL索引原理及设计
引擎的 MySQL 索引的相关概念，以及如何针对 InnoDB 进行索引的设计和使用，以及三星索引的概念，会从我所了解到的知识去解释为什么需要这样，如果有错误的地方还请指出。 主索引和辅助索引 在 InnoDB 存储引擎中，每一个索引都对应一棵 B+ Tree，InnoDB 的索引主要分为主索引和辅助索引： 主索引：包含记录的文件按照某个 key 制定的顺序排序，这个 key 就是主索引，也就是主键，也被称为聚簇索引。 正因为 InnoDB 索引的这种结构，产生了一些限制： 如果不是按照索引的最左列开始查找，则无法使用索引； 不能跳过联合索引中的某些列； 如果查询中有某个列的范围查询，则其右边所有列都无法使用索引优化查找 所以如果想让这个查询命中索引，得单独为 age 添加索引或者添加 age 为前缀的联合索引。
79130发布于 2019-07-19 - 来自专栏飞鸟的专栏
Elasticsearch 性能优化-索引设计
在使用 Elasticsearch 进行搜索时，索引的设计非常关键，它可以对搜索性能和数据质量产生重要影响。 索引设计原则在进行索引设计时，我们需要考虑以下几个方面：索引的存储需求在设计索引时，我们需要考虑到所需的存储空间，尤其是在存储大规模数据集时。 索引的查询需求在设计索引时，我们还需要考虑到所需的查询需求，包括搜索查询、聚合查询、排序查询等。 索引设计实践下面我们将通过一个实际的例子来介绍 Elasticsearch 索引设计的实践。假设我们有一个数据集包含用户信息，包括用户 ID、用户名、性别、年龄、所在城市、注册时间等字段。 索引的字段设计在进行索引设计时，我们需要先考虑索引的字段设计。根据上述查询需求，我们可以设计以下字段：id: 用户 ID，使用 keyword 类型存储。
650101编辑于 2023-05-09 - 来自专栏程序生涯
MySQL设计索引的原则
如仅用列值的第一个字符进行索引是不可能有多大好处的 ，因为这个索引中不会有许多不 同的值。） 4. 利用最左前缀。 在创建 一个 n 列的索引时，实际是创建了 MySQL 可利用的 n 个索引。 多列索引可起几个索引的作用，因为可利用索引中最左边的列集来匹配行。这样的列 集 称为最左前缀。（这与索引一个列的前缀不同，索引一个列的前缀是利用该的前 n 个 字符作为索引值。） 5. 不要过度索引。 不要以为 索引 “ 越多越好 ” ，什么东西都用索引是错的。每个额外的 索引都要占用额外的磁盘空间，并降低写操作的性能，这一点我们前面已经介绍 过。 此外， MySQL 在生成一个执行计划时，要考虑各个索引，这也要费时间。创建多余的 索引给查询优化带来了更多的工作。索引太多，也可能会使 MySQL 选择不到所要使用的最好索引。 只保持所需的索引有利于查询优化。如果想给已索引的表增加索引，应该考虑所要增加的索引是否是现有多列索引的最左 索引。如果是，则就不要费力去增加这个索引了，因为已经有了。 6.
80430发布于 2020-08-14 - 来自专栏大数据成神之路
Phoenix全局索引设计实践
文章详情：大数据技术与架构、暴走大数据 概述 全局索引是Phoenix的重要特性，合理的使用二级索引能降低查询延时，让集群资源得以充分利用。本文将讲述如何高效的设计和使用索引。 全局索引说明 全局索引的根本是通过单独的HBase表来存储数据表的索引数据。我们通过如下示例看索引数据和主表数据的关系。 索引表中的主键将会是索引列和数据表主键的组合值，include的列被存储在索引表的普通列中，其目的是让查询更加高效，只需要查询一次索引表就能够拿到数据，而不用去回查主表。其过程如下图 ? 全局索引设计 我们继续使用DATA_TABLE作为示例表，创建如下组合索引。之前我们已经提到索引表中的Row key是字典序存储的，什么样的查询适合这样的索引结构呢？ 其它 对于order by字段或者group by字段仍然能够使用二级索引字段来加速查询。 尽量通过合理的设计数据表的主键规避建更多的索引表，因为索引表越多写放大越严重。
1.1K20发布于 2019-09-29 - 来自专栏Spark学习技巧
Hbase Rowkey设计及索引
开头，先功夫一个好消息，浪尖的微信公众号支持内容搜索了，入口请点击原文阅读。 https://data.newrank.cn/m/s.html?s=PSkwPS48MT87 也可以去菜单栏，点击进入入
62540发布于 2018-12-14 - 来自专栏Java课堂
分库分表后如何设计索引？全局索引、二级索引
大家好，我是小富~ 分布式数据库架构下，索引的设计也需要做调整，否则无法充分发挥分布式架构线性可扩展的优势。今天我们就来聊聊 “在分布式数据库架构下，如何正确的设计索引？” 索引设计 通过分片键可以把 SQL 查询路由到指定的分片，但是在现实的生产环境中，业务还要通过其他的索引访问表。 当然，这里我们谈的设计都是针对于唯一索引的设计，如果是非唯一的二级索引查询，那么非常可惜，依然需要扫描所有的分片才能得到最终的结果，如： SELECT * FROM Orders WHERE o_orderate 如下面的设计： 唯一索引 最后我们来谈谈唯一索引的设计，与主键一样，如果只是通过数据库表本身唯一约束创建的索引，则无法保证在所有分片中都是唯一的。 总结 今天介绍了非常重要的分布式数据库索引设计，内容非常干货，是分布式架构设计的重中之重，建议反复阅读，抓住本文的重点，总结来说： 分布式数据库主键设计使用有序 UUID，全局唯一； 分布式数据库唯一索引设计使用
1.5K30编辑于 2022-12-10 - 来自专栏爱可生开源社区
第30期：索引设计（全文索引中文处理）
本篇是全文索引终篇，来细聊下 MySQL 全文索引对中文如何处理。在了解 MySQL 全文索引如何处理中文之前，先来看看什么是分词。 MySQL 全文索引默认是基于单字节流处理的，也就是按照单词与停止词（默认空格或者标点符号）来划分各个关键词，并且把关键词的文档 ID 和位置保存到辅助表用于后期检索。 如果按照默认的全文索引处理，搜索其中任何子句，结果肯定是出不来。这也间接导致大家说 MySQL 的全文检索结果不准确，不靠谱，其实并非如此，主要是 MySQL 全文索引对分词以及停止符界定有差异。 回顾下之前介绍的全文索引，可能就想到了，分词长度不够或者是停止词不对，分词长度见下面参数，停止词默认是空格或者标点符号。 除了分词数据保存方式不同，其他和默认的全文索引没有任何异同。 例如看看内部索引表存储是否类似，查询出来结果和默认的也一样。
1K10发布于 2021-07-16 - 来自专栏爱可生开源社区
第22期：索引设计（组合索引适用场景）
建立在多个列上的索引即组合索引（联合索引），适用在多个列必须一起使用或者是从左到右方向部分连续列一起使用的业务场景。 组合索引和单值索引类似，索引上的每个键值按照一定的大小排序。 比如下面对表 t3 查询，t3 的索引 udx_multi 是一个唯一索引。 ，因为 f1 为索引 idx_multi 的第一个字段，查询时如果仅仅包含字段 f1，那 MySQL 也仅仅只使用 f1 的索引数据，不会让索引 idx_multi 的所有列都被使用； 同理，基于字段 ，不需要单独再建立部分字段的组合索引，保留原来组合索引即可。 ，日常业务中，如果一个列已经在组合索引，并且在第一位，应当避免建立额外的单个索引。
40810发布于 2021-03-16
腾讯云开发者
