- 综合排序
- 最热优先
- 最新优先
- 来自专栏技术一号位指南(小诚信驿站)
系统设计：索引
如果有人跟你谈索引，是不是你会第一时间想到数据库，那么索引解决了什么问题？比如查询SQL慢了，发生这种情况时，首先要做的事情之一是查看是否慢SQL走了数据库索引。 因此，当我们在表的列上创建索引时，我们将该列和指向索引中整行的指针存储在索引中。 索引是实现这一点的最佳方法。 索引为什么会降低写性能？ 索引可以极大地加快数据检索速度，但由于额外的键，索引本身可能很大，这会减慢数据插入和更新的速度。 题外笔者补充 谷歌系统设计指南指定了我们说的索引的好处和坏处，那么其实深层次去思考，索引是解决的读问题，数据存储是解决的写问题，而在我们设计系统，中间件的过程中，你会发现大量的设计都是读写分开的，比如写磁盘是顺序写 所以是否使用索引的目的在于我们进行权衡，索引是否对我们有帮助，如果只有一条数据记录那么没有索引也可以。如果数据非常庞大，构建了很多冗余索引那么无疑是给我们写入的性能增加了难度。
1.6K61发布于 2021-08-26 - 来自专栏圣杰的专栏
索引设计指南
Sql Server索引设计指南——脑图链接 参考资料： SQL Server 索引设计指南 Clustered and Nonclustered Indexes Described
40120发布于 2019-09-12 - 来自专栏兜兜毛毛
MySQL 索引（3）
3. 平衡二叉树（AVL Tree） 平衡二叉树的定义：左右子树深度差绝对值不能超过1。 什么意思呢？比如左子树的深度是2，右子树的深度只能是1或者3。 https://www.cs.usfca.edu/~galles/visualization/BTree.html 比如MaxDegree（路数）是3的时候，我们插入数据1、2、3，在插入3的时候，本来应该在第一个磁盘块 把中间的数据2提上去，把1和3变成2的子节点。 ? 从这个里面我们也能看到，在更新索引的时候会有大量的索引的结构的调整，所以解释了为什么我们不要在频繁更新的列上建索引，或者为什么不要更新主键。 在查找数据时一次页的查找代表一次IO，也就是说，一张2000万左右的表，查询数据最多需要访问3次磁盘。 所以在InnoDB中B+树深度一般为1-3层，它就能满足千万级的数据存储。 索引的创建 1、在用于where判断order排序和join的（on）字段上创建索引 2、索引的个数不要过多。——浪费空间，更新变慢。 3、区分度低的字段，例如性别，不要建索引。
56920发布于 2020-08-11 - 来自专栏爱可生开源社区
第21期：索引设计（函数索引）
函数索引替代前缀索引？ 之前讲过前缀索引，可能会有这样的疑问。前缀索引能不能被函数索引替代？当然是不行的！ 下面例子用来模拟下是否可以用函数索引替代前缀索引。示例表 t3，一个前缀索引和两个函数索引实现的目的一样，但是实际查询的时候 SQL 语句并不一样。 # SQL 3 select * from t3 where r1 like 'de45c7d9%'; # SQL 4 select * from t3 where left(r1,8) ='de45c7d9 idx_func_index_3, SQL 4 就无法走正确的索引。 `t3`.`id` AS `id`,`ytt`.`t3`.`r1` AS `r1` from `ytt`.`t3` where (left(`ytt`.`t3`.
1K10发布于 2021-02-26 - 来自专栏爱可生开源社区
第20期：索引设计（前缀索引）
那面对这样的数据，我们该如何建立索引呢？ 大致有以下 3 种方法： 拿整个串的数据来做索引 这种方法来的最简单直观，但是会造成索引空间极大的浪费。 *) from t1 where r1 like 'sample%'； # SQL 2 select count(*) from t1 where r1 like 'sampl%'； # SQL 3 select count(*) from t1 where r1 like 'sa%'； # SQL 6 select count(*) from t1 where r1 like 's%'; 那可否设计一个合适的前缀索引来让以上 除了要加字段，此方法很完美~ 建一个表 t3，把表 t2 的数据导进去。 CREATE TABLE `t3` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT, `r1` varchar(300) DEFAULT NULL,
89920发布于 2021-02-01 - 来自专栏码上遇见你
MySQL索引设计原则
MySQL索引的设计原则： 索引设计原则一： 针对sql语句中的where,order by,group by条件设计索引。 并且注意where,order by,group by后面跟的字段的顺序，是不是某个联合索引的最左侧字段开始的部分字段 索引设计原则二： 需要考虑字段基数的问题,一般建立索引尽量使用那些基数较大的字段， 索引设计原则三 尽量对那些字段类型较小的字段来设计索引。 对于前缀索引，仅仅包含部分字符到索引树中，where查询是可以使用的，但是order by和group by就用不上了 索引设计原则四 设计索引需要考虑到数据插入更新时索引树也会进而更新，以及主键一定要是自增的 避免数据稀疏造成频繁的页分裂，其次就是索引不要设计的太多，毕竟维护成本较高，也占用磁盘，还有就是插入的数据不是按照顺序来的，从而会导致某个索引树里的索引页自动分裂这就会很浪费时间 总结： 简单来说建立索引需要考虑的点主要一下几个方面
40720编辑于 2023-06-28 - 来自专栏IT技术精选文摘
MySQL索引设计概要
在关系型数据库中设计索引其实并不是复杂的事情，很多开发者都觉得设计索引能够提升数据库的性能，相关的知识一定非常复杂。 本文会介绍 数据库索引设计与优化 中设计索引的一些方法，让各位读者能够快速的在现有的工程中设计出合适的索引。 无论我们是想要读取一个页面上的多条数据还是一条数据，都需要消耗约 10ms 左右的时间： 10ms 的时间在计算领域其实是一个非常巨大的成本，假设我们使用脚本向装了 SSD 的磁盘上顺序写入字节，那么在 10ms 内可以写入大概 3MB 这 10ms 的一次随机读取是按照每秒 50 次的读取计算得到的，其中等待时间为 3ms、磁盘的实际繁忙时间约为 6ms，最终数据页从磁盘传输到缓冲池的时间为 1ms 左右，在对查询进行估算时并不需要准确的知道随机读取的时间 索引的设计 作者相信文章前面的内容已经为索引的设计提供了充足的理论基础和知识，从总体来看如何减少随机读取的次数是设计索引时需要重视的最重要的问题，在这一节中，我们将介绍 数据库索引设计与优化 一书中归纳出的设计最佳索引的方法
1.9K60发布于 2018-01-30 - 来自专栏爱可生开源社区
第26期：索引设计（索引下推）
MySQL 存储引擎层：按照 MySQL 服务层下发的请求，通过索引或者全表扫描等方式把数据上传到 MySQL 服务层。 3. MySQL 索引扫描：根据指定索引过滤条件（比如 where id = 1) ，遍历索引找到索引键对应的主键值后回表过滤剩余过滤条件。 4. MySQL 索引过滤：通过索引扫描并且基于索引进行二次条件过滤后再回表。 ICP 就是把以上索引扫描和索引过滤合并在一起处理，过滤后的记录数据下推到存储引擎后的一种索引优化策略。 的处理流程大概如图 1： 使用 ICP 扫描的过程： MySQL 存储引擎层，先根据过滤条件中包含的索引键确定索引记录区间，再在这个区间的记录上使用包含索引键的其他过滤条件进行过滤，之后规避掉不满足的索引记录 我上面举的例子即是 ref 类型，ICP 尤其是对联合索引的部分列模糊查找非常有效。 2. ICP 同样适用于分区表。 3. ICP 的目标是减少全行记录读取，从而减少 I/O 操作，仅用于二级索引。
77330发布于 2021-04-23 - 来自专栏爱可生开源社区
第31期：索引设计（索引数量探讨）
一般提到索引，大家都只关注索引的优点，一个优秀的索引的确会让查询请求的效率大幅提升、亦或是大幅提升带有索引键进行过滤的写入请求（update、delete)效率。 为了维护索引数据的准实时性而让优化器基于索引做出更优化的执行计划，数据库会自动更新索引数据分布，比如带来索引页的拆分与合并等。 那索引的存在对写入请求影响到底有多大？ 这里用来测试索引数量的表有 10 个，分别为 t1 到 t10 ，除了每张表索引数量不一样外，字段定义等都一样：t1 有 1 个索引，t2 有个 2 个，依次类推，t10 有 10 个索引，字段类型都是整形 （索引数量不包含主键，只包含二级索引）。 从以上简单测试结果可以得到， 新增一个索引，就会导致额外的写入时间消耗。在写入优先的业务中，索引并不是越多越好，最好是保留必要的索引，删除掉不必要的索引。
40220发布于 2021-07-16 - 来自专栏爱可生开源社区
第17期：索引设计（主键设计）
InnoDB 表是索引组织表，主键既是数据也是索引。 主键的设计原则 1. 举个例子，假设武汉市每个区都有自己的医保数据，并且以前每个区都是自己独立设计的数据库，现在医保要升级为全市统一，以市为单位设计新的数据库模型。 --+ 3 rows in set (0.00 sec) 由于之前两个区数据库设计的人都没有考虑以后合并的事情，所以每个区的表都有自己独立的自增主键， 考虑这样建立一张汇总表 n3，有新的自增 ID，并且设计导入老系统的 可以新建一个自增主键或者 uuid_short() 函数字段，实际业务字段非主键设计，变为普通唯一索引。 但是如果有与业务不相关的主键，只需要更改业务字段（二级索引）就可以，不需要更改依赖这张表的子表。 关于 MySQL 主键的设计思路大致介绍到此，有问题欢迎留言，欢迎指正本篇任何不足之处。 ----
82210发布于 2020-12-14 - 来自专栏爱可生开源社区
第29期：索引设计（监测全文索引）
接着讲 MySQL 全文索引，这篇主要探讨 MySQL 全文索引的监测。 MySQL 有很完整的元数据表来监测全文索引表的插入，更新，删除；甚至全文索引表以及辅助表的数据追踪。 第一部分， 全文索引监测相关参数： innodb_ft_aux_table ：动态设置被监测的全文索引表名。这个参数必须显式设置，才能对全文索引正常监测。 第二部分，全文索引数据监测元数据表： MySQL 目前提供以下字典表，用来监测全文索引信息 INNODB_FT_CONFIG ：存放全文索引元数据以及相关内部处理数据。 | 3 | 3 | 1 | 3 | 4 | | gfs | 7 | | 3 | 1 | 3 | 0 | +-----------+--------------+-------------+----------
67920发布于 2021-06-16 - 来自专栏爱可生开源社区
第28期：索引设计（使用全文索引）
上一篇介绍了全文索引的基本原理，这篇来讲讲如何更好的使用全文索引。 varchar(200) DEFAULT NULL, `log_time` datetime DEFAULT NULL, `s2` varchar(200) DEFAULT NULL, `s3` # SQL 3 select count(if(match(s1) against ('cluster' in natural language mode),1,null)) as "count(*)" from fx; 分别看下三个SQL 的执行计划： SQL 1 最优，EXTRA栏结果显示这是一个最优化的查询； SQL 2次之，走全文索引ft_s1; SQL 3 没有WHERE 过滤条件，所以全表扫描 ，后面会继续讲解如何提高全文索引结果的准确性以及全文索引的优化与中文插件的使用。
86630发布于 2021-06-16 - 来自专栏爱可生开源社区
第16期：索引设计（MySQL 的索引结构）
上一章（第15期：索引设计（索引组织方式 B+ 树））讲了数据库基本上都用 B+ 树来存储索引的原因：适合磁盘存储，能够充分利用多叉平衡树的特性，磁盘预读，并且很好的支持等值，范围，顺序扫描等。 记录如下： 那对应的两个 B+ 树索引如下图所示， 主键字段索引树： 上图是一个 3 阶的 B+ 树，非叶子节点按照主键的值排序存储，叶子节点同样按照主键的值排序存储，并且包含指向磁盘上的物理数据行指针 年龄字段索引树： 上图年龄字段索引树同样是一个 3 阶的 B+ 树，非叶子节点按照年龄字段的值顺序存储，叶子节点保存年龄字段的值以及指向磁盘上的物理数据行指针。 二级索引由于同时保存了主键值，体积会变大。特别是主键设计不合理的时候，比如用 UUID 做主键。下一篇我详细介绍如何设计合理的主键。 2. 对二级索引的检索需要检索两次索引树。 本篇主要介绍 MySQL 常见的两种引擎 MYISAM 和 INNODB 的索引组织方式以及各自的优缺点。有问题欢迎批评指正，下一篇我来介绍 MySQL 如何很好的对主键进行设计。
1.1K20发布于 2020-11-19 - 来自专栏格姗知识圈
MySQL索引原理及设计
引擎的 MySQL 索引的相关概念，以及如何针对 InnoDB 进行索引的设计和使用，以及三星索引的概念，会从我所了解到的知识去解释为什么需要这样，如果有错误的地方还请指出。 查询 2: SELECT * FROM employees WHERE name='iCell'; 根据 (name, age, gender) 这个索引树来查找，找到 id 为 3 的索引数据符合条件 ，然后通过相邻的节点链接继续查找，发现下一个数据也符合条件，继续根据节点链接查找，直到发现数据已经不符合条件了，于是命中索引的就是 id 为 3，4，5 的几条数据，然后继续根据这几个 id 值进行回表操作 查询 3: SELECT * FROM employees WHERE age=17; 根据“最左前缀”原则，并不存在 age 为前缀的索引，所以这个查询无法使用 (name, age, gender) 假设一个数据页只能存储 3 条数据，且已经有 3 条数据（100， 200， 300）了，这时候想插入一条 150 的数据，就会再申请一个新的数据页，100，150 两条数据存放在原来的数据页中，200
91530发布于 2019-07-19 - 来自专栏飞鸟的专栏
Elasticsearch 性能优化-索引设计
索引设计原则在进行索引设计时，我们需要考虑以下几个方面：索引的存储需求在设计索引时，我们需要考虑到所需的存储空间，尤其是在存储大规模数据集时。 索引的查询需求在设计索引时，我们还需要考虑到所需的查询需求，包括搜索查询、聚合查询、排序查询等。 索引设计实践下面我们将通过一个实际的例子来介绍 Elasticsearch 索引设计的实践。假设我们有一个数据集包含用户信息，包括用户 ID、用户名、性别、年龄、所在城市、注册时间等字段。 索引的字段设计在进行索引设计时，我们需要先考虑索引的字段设计。根据上述查询需求，我们可以设计以下字段：id: 用户 ID，使用 keyword 类型存储。 } }{ "id": "3", "username": "user3", "gender": "male", "age": 40, "city": "Guangzhou", "registered_at
841101编辑于 2023-05-09 - 来自专栏程序生涯
MySQL设计索引的原则
而用来记录性别的列，只含有 “ M ” 和 “ F ” ，则对此列进行索引没有多大用处（不管搜索哪个值，都会得出大约一半的行） 3. 使用短索引。 多列索引可起几个索引的作用，因为可利用索引中最左边的列集来匹配行。这样的列 集 称为最左前缀。（这与索引一个列的前缀不同，索引一个列的前缀是利用该的前 n 个 字符作为索引值。） 5. 不要过度索引。 不要以为 索引 “ 越多越好 ” ，什么东西都用索引是错的。每个额外的 索引都要占用额外的磁盘空间，并降低写操作的性能，这一点我们前面已经介绍 过。 此外， MySQL 在生成一个执行计划时，要考虑各个索引，这也要费时间。创建多余的 索引给查询优化带来了更多的工作。索引太多，也可能会使 MySQL 选择不到所要使用的最好索引。 只保持所需的索引有利于查询优化。如果想给已索引的表增加索引，应该考虑所要增加的索引是否是现有多列索引的最左 索引。如果是，则就不要费力去增加这个索引了，因为已经有了。 6.
91730发布于 2020-08-14 - 来自专栏大数据成神之路
Phoenix全局索引设计实践
文章详情：大数据技术与架构、暴走大数据 概述 全局索引是Phoenix的重要特性，合理的使用二级索引能降低查询延时，让集群资源得以充分利用。本文将讲述如何高效的设计和使用索引。 全局索引说明 全局索引的根本是通过单独的HBase表来存储数据表的索引数据。我们通过如下示例看索引数据和主表数据的关系。 索引表中的主键将会是索引列和数据表主键的组合值，include的列被存储在索引表的普通列中，其目的是让查询更加高效，只需要查询一次索引表就能够拿到数据，而不用去回查主表。其过程如下图 ? 全局索引设计 我们继续使用DATA_TABLE作为示例表，创建如下组合索引。之前我们已经提到索引表中的Row key是字典序存储的，什么样的查询适合这样的索引结构呢？ 其它 对于order by字段或者group by字段仍然能够使用二级索引字段来加速查询。 尽量通过合理的设计数据表的主键规避建更多的索引表，因为索引表越多写放大越严重。
1.2K20发布于 2019-09-29 - 来自专栏Spark学习技巧
Hbase Rowkey设计及索引
开头，先功夫一个好消息，浪尖的微信公众号支持内容搜索了，入口请点击原文阅读。 https://data.newrank.cn/m/s.html?s=PSkwPS48MT87 也可以去菜单栏，点击进入入
67740发布于 2018-12-14 提升YashanDB索引设计技巧
在 YashanDB（基于国产数据库生态的分布式数据库）中，合理的索引设计能显著提升查询效率、减少I/O开销。以下是一些实用的索引设计技巧：1. 设计原则1. 高选择性优先- 优先为区分度高（不同值多）的列建索引。- 例如：性别字段（仅“男/女”）不适合单独建索引。2. 覆盖索引- 将查询中 SELECT 的字段全部包含在索引里，避免回表。 ;3. 避免过度索引- 索引过多会影响写入性能（INSERT/UPDATE/DELETE）。- 尽量合并索引需求，避免重复。4. 冷热分离- 对历史数据、归档表减少索引，活跃数据表适当增加索引。5. 结合分区与索引- YashanDB支持分区表：分区键选择与索引字段要协调。- 常见：按时间分区，同时在分区键上建索引，提高范围查询效率。3. �� 如果你希望，我可以帮你写一份 YashanDB 索引设计最佳实践清单（Checklist），方便在项目中逐条对照使用。要不要我整理一个简洁表格版本给你？
19410编辑于 2025-10-10- 来自专栏Java课堂
分库分表后如何设计索引？全局索引、二级索引
大家好，我是小富~ 分布式数据库架构下，索引的设计也需要做调整，否则无法充分发挥分布式架构线性可扩展的优势。今天我们就来聊聊 “在分布式数据库架构下，如何正确的设计索引？” 索引设计 通过分片键可以把 SQL 查询路由到指定的分片，但是在现实的生产环境中，业务还要通过其他的索引访问表。 当然，这里我们谈的设计都是针对于唯一索引的设计，如果是非唯一的二级索引查询，那么非常可惜，依然需要扫描所有的分片才能得到最终的结果，如： SELECT * FROM Orders WHERE o_orderate 如下面的设计： 唯一索引 最后我们来谈谈唯一索引的设计，与主键一样，如果只是通过数据库表本身唯一约束创建的索引，则无法保证在所有分片中都是唯一的。 总结 今天介绍了非常重要的分布式数据库索引设计，内容非常干货，是分布式架构设计的重中之重，建议反复阅读，抓住本文的重点，总结来说： 分布式数据库主键设计使用有序 UUID，全局唯一； 分布式数据库唯一索引设计使用
1.7K30编辑于 2022-12-10
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号