如何做网站 写代码,登录入口,产品展示型网站有哪些,制作二维码目录 索引应用
MySQL有哪些索引?
普通索引和唯一索引有什么区别? 哪个更新性能更好? 、
聚簇索引的主键索引怎么设置? 追问:假如你不设置会怎么样?
我们一般选择什么样的字段来建立索引?
索引越多越好吗?
索引怎么优化? #xff08;覆盖索引优化、防止索引失效、…目录 索引应用
MySQL有哪些索引?
普通索引和唯一索引有什么区别? 哪个更新性能更好? 、
聚簇索引的主键索引怎么设置? 追问:假如你不设置会怎么样?
我们一般选择什么样的字段来建立索引?
索引越多越好吗?
索引怎么优化? 覆盖索引优化、防止索引失效、主键递增、前缀索引优化
建立了索引查询的时候一定会用到索引吗? 索引失效、优化器基于成本选择执行计划
如果我定义了一个varchar类型的日期字段并且有一个数据是‘20230922’如果这个日期字段上有索引那如果我查询的where条件是where time20230922不加单引号还会命中索引吗? 为什么?
MySQL最新版本解决了索引失效的哪些情况了吗? 函数索引函数计算后的值也能走索引、索引跳跃扫描机制最左前缀
什么是最左匹配原则?
建立联合索引有什么需要注意的? 区分度大的放在最左侧最左匹配原则、范围查询后的不走索引
最左匹配原则查询顺序
索引下推是什么 MySQL5.6 添加的用于优化数据查询
where a1 and b2 and c 3 怎么建立索引?
(A,B,C) 联合索引 select * from tbn where a? and b in (?,?) and c? 会走索引吗
where a100 and b100 and c123 order by d 怎么建立联合索引?
select id ,name from XX where age 10 and name like‘xx%’有联合索引(name,age) 说一下查询过程 索引应用
MySQL有哪些索引?
我了解到 MySQL有主键索引、唯一索引、普通索引、前缀索引、联合索引这几种索引。
Innodb 引擎会要求每一张数据库表都必须要有一个主键索引索引列的值不允许有空值。比如表里的 id 字段就是主键索引
唯一索引: 保证数据列中每行数据的唯一性但允许有空值。
然后针对查询比较频繁的字段我们可以对这个字段建立普通索引如果是多个字段的话可以考虑建立联合索引利用索引覆盖的特性提高查询效率。
对于长文本、字符串等类型的字段比如文章标题、商品名称等我们可以只对这些字段的前缀部分建立索引也就是建立前缀索引这样可以减少索引的存储空间。
普通索引和唯一索引有什么区别? 哪个更新性能更好? 、 查询单个值时唯一索引可能略快因为它在找到第一个匹配项后可以终止搜索。 插入和更新操作普通索引可能略快因为它不需要进行唯一性检查。 普通索引列的值是可以重复的而唯一索引列的值是必须唯一的当我们对唯一索引插入了一条重复的值会因为唯一性约束而报错。 我认为普通索引的更新性能会更好因为普通索引在更新的时候如果更新的数据页不在内存的话可以直接把更新操作缓存在 change buffer 中更新操作就结束了。不需要唯一性检查 但是唯一索引因为需要有唯一性约束如果更新的数据页不在内存的话需要从磁盘读取对应的数据页到内存判断有没有冲突这里会涉及磁盘随机IO的访问。 普通索引因为能使用change buffer 特性所以普通索引的更新相比于唯一索引减少了随机磁盘访问所以更新性能更好
聚簇索引的主键索引怎么设置? 追问:假如你不设置会怎么样?
InnoDB在创建聚簇索引时会根据不同的场景选择不同的列作为索引: 如果有主键默认会使用主键作为聚簇索引的索引键 如果没有主键就选择第一个不包含 NULL值的唯一列作为聚簇索引的索引键 在上面两个都没有的情况下InnoDB将自动生成一个隐式自增rowid列作为聚簇索引的索引键
我们一般选择什么样的字段来建立索引?
适用索引的场景: 字段有唯一性限制的比如商品编码 经常用于WHERE查询条件的字段这样能够提高整个表的查询速度如果查询条件不是一个字段可以建立联合索引 经常用于GROUPBY和ORDER BY的字段这样在查的时候就不需要再去做一次排序了因为建立索引之后在 B Tree 中的记录都是排序好的。
不适合索引的场景 WHERE条件GROUP BYORDER BY 里用不到的字段索引的价值是快速定位如果起不到定位的字段通常是不需要创建索引的因为索引是会占用物理空间的。 区分度低的字段不需要创建索引比如性别字段只有男女如果数据库表中男女的记录分布均匀那么无论搜索哪个值都可能得到一半的数据。在这些情况下还不如不要索引因为 MySQL还有一个查询优化器查询优化器发现某个值出现在表的数据行中的百分比很高的时候它一般会忽略索引进行全表扫描。 频繁更新的字段比如不要对电商项目的用户余额建立索引因为索引字段频繁修改由于要维护 BTree的有序性那么就需要频繁的重建索引这个过程是会影响数据库性能的。 不建议用无序的值(例如身份证、UUID )作为索引当主键具有不确定性会造成叶子节点频繁分裂出现磁盘存储的碎片化 数据表较小当表中的数据量很小或者查询需要扫描表中大部分数据时数据库优化器可能会选择全表扫描而不是使用索引。在这种情况下维护索引的开销可能大于其带来的性能提升。
索引越多越好吗?
不是的索引虽然能提高查询效率但是多建立一个索引就意味着新生成一个 B树索引是需要占用存储空间的特别是在表数据量非常大的时候索引占用的空间越大
索引越多数据库的写入性能会下降因为每次对表进行增删改操作的时候都需要去维护各个 B 树索引的有序性
索引怎么优化? 覆盖索引优化、防止索引失效、主键递增、前缀索引优化
我用过这几种优化的方式 对于需要查询几个字段数据的 SQL 来说我们可以对这些字段建立联合索引这样查询方式就变成了覆盖索引避免了回表减少了大量的I/O 操作。 我们的主键索引最好是递增的值因为我们索引是按顺序存储数据的如果主键的值是随机的值可能会引发页分裂的现象页分裂会导致大量的内存碎片这样索引结构不紧凑了就会影响查询效率。 我们要避免写出发生索引失效的 SQL 的语句比如不要对索引列进行左或者左右模糊匹配、不要对索引进行计算、函数、类型转换操作联合索引要能正确使用要遵循最左匹配原则等等。在WHERE子句中如果在OR 前的条件列是索引列而在OR 后的条件列不是索引列那么索引会失效。 使用不等于或者 NOT 操作符这些操作符通常会使索引失效因为它们会扫描全表。 OR 操作符如果查询条件中使用了 OR并且 OR 两边的条件分别涉及不同的索引那么这些索引可能都无法使用。 使用 OR 操作符时如果 OR 两边的条件涉及不同的索引数据库引擎在大多数情况下无法同时使用多个索引来优化查询。这是因为 OR 操作符要求满足任意一边的条件即可这增加了查询优化的复杂性。 对于一些大字符串的索引我们可以考虑用前缀索引只对索引列的前缀部分建立索引节省索引的存储空间提高查询性能。 索引最好设置为 NOT NULL为了更好的利用索引索引列要设置为 NOT NULL 约束。有两个原因 索引列存在 NULL 就会导致优化器在做索引选择的时候更加复杂更加难以优化 如count操作 NULL 值是一个没意义的值但是它会占用物理空间存在null值列至少会用 1 字节空间存储 NULL 值列表
建立了索引查询的时候一定会用到索引吗? 索引失效、优化器基于成本选择执行计划
不是的。 我了解到即使查询使用到了索引也是可能不走索引的 比如:当我们查询语句对索引字段进行左模糊匹配、表达式计算、函数、隐式类型转换操作这时候查询语句就无法走索引了查询方式就变成了全表扫描的方式。 还有我们使用联合索引进行查询的时候如果没有遵循最左匹配原则也是会发生索引失效的。 优化器是基于成本考虑来选择查询的方式在使用二级索引进行查询的时候优化器会计算回表的成本和全表扫描的成本如果回表的代价太高优化器会选择不走索引而是走全表扫描
如果我定义了一个varchar类型的日期字段并且有一个数据是‘20230922’如果这个日期字段上有索引那如果我查询的where条件是where time20230922不加单引号还会命中索引吗? 为什么?
不会命中索引。
因为 mysql在遇到字符串和数字比较的时候会发生隐式类型转换会将字符串的对象转为数字这个转换的过程实际上会涉及到函数。你说的这个查询日期字段是字符串那么发生隐式类型转换的时候就会作用在日期这个索引字段上对索引进行函数计算的话是会发生索引失效的。 对于整型类型的索引列例如id列它的值是直接存储在索引中的而不会发生函数计算。这意味着在查询中使用id进行匹配时不需要对id进行任何函数计算或转换只是简单地比较整数值。 MySQL最新版本解决了索引失效的哪些情况了吗? 函数索引函数计算后的值也能走索引、索引跳跃扫描机制最左前缀
我了解到 MySQL8.0可以给字段增加函数索引这个新特性可以解决对索引使用函数的时候索引失效的问题。
还有一个新特性是索引跳跃式扫描5.7 版本之前使用联合索引的时候如果不满足最左匹配原则就会发生索引失效而 8.0出了索引跳跃式扫描特性之后即使没有遵循最左匹配原则依然可以使用联合索引。
什么是最左匹配原则?
假设有一个(abc) 联合索引它的存储顺序是先按 a 排序在 a 相同的情况再按b 排序在 b 相同的情况再按 c 排序。由于这个特性在使用联合索引时存在最左匹配原则具体的规则: MySQL的联合索引会从最左边的索引列开始匹配查询条件然后依次从从左到右的顺序匹配如果查询条件没有使用到某个列那么该列右边的所有列都无法使用走索引。 当查询条件中使用了某个列但是该列的值包含范围查询范围查询的字段可以用到联合索引但是在范围查询字段的后面的字段无法用到联合索引。
所以我们在使用联合索引的时候要遵守最左匹配原则否则可能会出现部分索引字段走不了索引。
建立联合索引有什么需要注意的? 区分度大的放在最左侧最左匹配原则、范围查询后的不走索引 最好把区分度比较大的字段放在联合索引最左侧有助于提高索引的过滤效果比如UUID 这类字段就比较适合做索引或排在联合索引列的靠前的位置。 如果区分度很低的字段放在了联合索引最左侧有可能会导致查询优化器会选择全表扫描而不走索引了。 联合索引的最左匹配原则在遇到范围查询如 、的时候就会停止匹配也就是范围查询的字段可以用到联合索引但是在范围查询字段后面的字段无法用到联合索引。但是对于 、、BETWEEN、like 前缀匹配这四种范围查询并不会停止匹配。 在 MySQL 中BETWEEN 包含了 value1 和 value2 边界值类似于 and 。 参考链接 https://zhuanlan.zhihu.com/p/573138586
最左匹配原则查询顺序 select * from T where c1 and a2 and b3;
abc都能走索引因为 where 查询条件字段的顺序并不会影响MySQL优化器会帮我们调整字段的查询顺序所以也是符合最左匹配原则的。
索引下推是什么 MySQL5.6 添加的用于优化数据查询
索引下推能够减少二级索引在查询时的回表操作提高查询的效率因为它将 Server 层部分负责的事情交给存储引擎层去处理了。 不使用索引条件下推优化时存储引擎通过索引检索到数据然后返回给 MySQL ServerMySQL Server 进行过滤条件的判断。 当使用索引条件下推优化时如果存在某些被索引的列的判断条件时MySQL Server 将这一部分判断条件下推给存储引擎然后由存储引擎通过判断索引是否符合 MySQL Server 传递的条件只有当索引符合条件时才会将数据检索出来返回给 MySQL 服务器。
索引条件下推优化可以减少存储引擎查询基础表的次数也可以减少 MySQL 服务器从存储引擎接收数据的次数。 select * from t_user where age 20 and reward 100000;
where a1 and b2 and c 3 怎么建立索引? 创建(abc)、(acb)、(ab)、(ac)联合索引只有 a 能索引 创建(cab)、(cba)、(ca)、(cb)联合索引只有 c能索引 创建(ba)联合索引b和a都能走索引 创建(bc)联合索引b和c都能走索引 创建(bac) 联合索引b 和 a都能走索引但比(ba)联合索引多了一个好处c 字段能索引下推会减少回表的次数; 创建(bca) 联合索引b和c都能走索引但比(bc)联合索引多了一个好处a 字段能索引下推会减少回表的次数;
(A,B,C) 联合索引 select * from tbn where a? and b in (?,?) and c? 会走索引吗
这个查询会使用到联合索引 (A,B,C)因为条件是按照索引列 A、B、C 的顺序来的这是理想的使用场景。 对于 A?这个条件是一个精确匹配MySQL 会使用索引来定位到满足条件 A? 的记录。 对于 B IN (?, ?)这个条件指定了 B 列可以取两个可能的值。MySQL 会利用索引来查找所有匹配 A? 且 B 列为这两个值中任意一个的记录。 对于 C?这个条件是一个范围查询。在已经根据 A 和 B 筛选的基础上MySQL 会继续利用索引来查找 C 列值大于指定值的记录。
where a100 and b100 and c123 order by d 怎么建立联合索引?
我觉得建立 bcda 顺序的联合索引比较好这时候b和c字段都能走索引而且d能用索引有序性避免 file sort额外排序最后的 a 字段虽然无法走索引(a无序)但是可以利用索引下推, 减少回表的次数。
select id ,name from XX where age 10 and name like‘xx%’有联合索引(name,age) 说一下查询过程
联合索引的顺序是先 name再age结构上是先根据 name 排序name 相等的情况下再根据age 排序。所以优化器需要先匹配 namename 这时候是右模糊查询并不会发生索引失效所以这条sql是能走联合索引的
具体的话只有 name 能走索引这是因为由于name右模糊查询后age 字段的值并不是有序的因此age 无法走索引但是age可以进行索引下推。
最后查询的字段是id和name这两个字段都能在联合索引上查找到所以不需要回表,是索引覆盖查询。 name右模糊查询属于范围查询后面字段不能用索引
