值比较 跟 索引比较

要分清 值比较 跟 索引比较。值比较常见的有字符串,数字跟布尔。索引比较常见的有对象,数组跟函数。索引比较的话只要索引不同即不等。


如图所示




原始类型和引用类型

原始类型:

  • String
  • Number
  • Boolean
  • Null
  • Undefined

引用类型:

引用类型通常叫做类(class),也就是说,遇到引用值,所处理的就是对象。

注意:从传统意义上来说,ECMAScript 并不真正具有类。事实上,除了说明不存在类,在 ECMA-262 中根本没有出现“类”这个词。ECMAScript 定义了“对象定义”,逻辑上等价于其他程序设计语言中的类。

对象是由 new 运算符加上要实例化的对象的名字创建的。例如,下面的代码创建 Object 对象的实例:

var o = new Object();

这里写图片描述

原始类型的值不会被改变,引用类型的值会改变。

<think>嗯,用户的问题是关于数据库索引优化的,具体是问"null较多的字段是否适合创建数据库索引"。我需要结合数据库索引的原理MySQL的特性来回答这个问题。 用户提到的引用内容很有价。引用1引用3都提到了MySQL唯一索引对NULL的特殊处理:唯一索引允许存在多个NULL,因为SQL标准认为NULL不等于任何包括自身。引用2则提到索引设计的注意事项,特别是频繁更新字段低区分度字段不适合建索引。 从技术角度看,NULL较多的字段创建索引需要权衡几个因素。首先是索引效率问题,B+树索引中NULL会被特殊处理,可能影响范围查询效率。其次是存储空间,虽然NULL索引中占用空间较小,但大量NULL仍会消耗存储资源。最后是查询优化器的使用限制,当WHERE条件包含"IS NULL"时,索引可能无法被充分利用。 用户可能正在设计数据库表结构,遇到了包含大量空的字段(如选填项),想知道是否得为其创建索引。这需要分情况讨论:如果该字段经常作为查询条件且非NULL比较高(比如超过10%),那么索引可能有效;但如果NULL占比极高(如超过90%),或者该字段很少在查询中使用,创建索引反而会成为负担。 考虑到用户关注性能优化,我还应该补充替代方案。比如使用过滤索引(MySQL 8.0的部分索引功能),或者将NULL转换为特定默认再建立索引。这些方案都能在特定场景下提升索引效率。 最后需要强调测试的重要性,因为实际效果取决于数据分布查询模式。建议用户用EXPLAIN分析执行计划,对比建索引前后的性能差异。</think>在数据库索引优化中,**包含大量 NULL 的字段通常不适合创建索引**,但需结合具体场景分析。以下是关键考量因素优化建议: --- ### **一、不建议创建索引的情况** 1. **索引效率低下** - B+树索引中,NULL 会被单独存储。当字段中 NULL 占比极高时(如 >90%),索引的过滤效果显著降低。 - 范围查询(如 `WHERE col > 10`)会跳过 NULL ,导致索引利用率下降。 2. **空间与维护成本** - 索引占用额外存储空间,尤其当字段总行数巨大时,维护成本(如 INSERT/UPDATE/DELETE)增加,但回报率低。 3. **查询优化器限制** - 对 `WHERE col IS NULL` 的查询,优化器可能选择全表扫描而非索引(因 NULL 索引中分布分散)[^2]。 --- ### **二、可考虑创建索引的场景** 1. **非 NULL 区分度高** - 若实际有效(非 NULL)具有高选择性(如唯一或重复率低),且这些频繁用于查询条件(如 `WHERE col = 'value'`),索引可能有效。 2. **覆盖索引优化查询** - 若该字段与其他高频查询字段组成联合索引,且能覆盖查询所需列(避免回表),可提升性能。 --- ### **三、替代优化方案** 1. **使用过滤索引(部分索引)** - **MySQL 8.0+** 支持部分索引,仅对非 NULL 创建索引: ```sql CREATE INDEX idx_non_null ON table_name (col_name) WHERE col_name IS NOT NULL; ``` - 此方案节省空间,提升索引效率。 2. **转换 NULL 为默认** - 将 NULL 替换为特定默认(如 `''` 或 `0`),再创建唯一索引: ```sql ALTER TABLE table_name ADD UNIQUE INDEX idx_unique (COALESCE(col_name, '')); ``` 3. **联合索引优化** - 若 NULL 字段与其他高区分度字段组合查询,可创建联合索引: ```sql CREATE INDEX idx_composite ON table_name (other_col, nullable_col); ``` --- ### **四、决策建议** | **场景** | **建议** | |-----------------------------------|-----------------------------| | NULL 占比 > 90% | ❌ 避免创建索引 | | 非 NULL 区分度高且查询频繁 | ✅ 创建索引或过滤索引 | | 与其他字段组成覆盖索引 | ✅ 创建联合索引 | | 需强制唯一性(含 NULL) | ✅ 使用默认转换 + 唯一索引 | --- ### **验证方法** 执行查询前用 `EXPLAIN` 分析: ```sql EXPLAIN SELECT * FROM table_name WHERE nullable_col IS NULL; EXPLAIN SELECT * FROM table_name WHERE nullable_col = 'value'; ``` 观察 `possible_keys` `key` 字段,确认索引是否被使用。 > **结论**:NULL 较多的字段通常不是理想的索引候选,但在特定场景下通过**过滤索引**、**默认转换**或**联合索引**可优化性能。需结合数据分布查询模式综合评估[^1][^2][^3]。 --- ### 相关问题 1. **如何识别 MySQL 中低效的索引?** 2. **联合索引中字段顺序如何影响查询性能?** 3. **MySQL 8.0 的不可见索引(Invisible Indexes)有什么作用?** 4. **哪些类型的查询无法利用索引?**
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值