Null 值对索引排序的影响案例一则

最新推荐文章于 2024-06-29 10:34:08 发布
最新推荐文章于 2024-06-29 10:34:08 发布
阅读量131 收藏
点赞数
文章标签： 数据库
原文链接：http://www.cnblogs.com/plluoye/p/8423838.html
版权 
--原SQL 语句如下：
select *
  from (select tmp_tb.*, ROWNUM row_id
          from (select wpid,
                       customer_id,
                       customer_name,
                       gender,
                       to_char(wi.call_time, 'yyyy-mm-dd hh24:mi:ss') call_time,
                       call_num,
                       phoneno,
                       tel,
                       cardtype,
                       cardnum,
                       note,
                       sessionid,
                       (select c.nodevalue
                          from sys_code c
                         where c.auto_id = wi.wp_type) wp_type,
                       smalltype,
                       order_type,
                       priority,
                       is_callback,
                       is_hidden,
                       district,
                       address,
                       summary,
                       wp_title,
                       wp_remark,
                       (select c.nodename
                          from sys_code c
                         where c.auto_id = wi.wp_source) wp_source,
                       (select c.nodevalue
                          from sys_code c
                         where c.auto_id = wi.class1) class1,
                       (select c.nodevalue
                          from sys_code c
                         where c.auto_id = wi.class2) class2,
                       (select c.nodevalue
                          from sys_code c
                         where c.auto_id = wi.class3) class3,
                       (select c.nodevalue
                          from sys_code c
                         where c.auto_id = wi.class4) class4,
                       upload_acceptance,
                       upload_handle,
                       upload_back,
                       upload_supervise,
                       is_repeat,
                       to_char(wi.starttime, 'yyyy-mm-dd hh24:mi:ss') starttime,
                       sender,
                       to_char(wi.updatetime, 'yyyy-mm-dd hh24:mi:ss') updatetime,
                       lastmessage,
                       (select sf.statename
                          from sys_function sf
                         where sf.auto_id = wi.state) state,
                       (select sf.statename
                          from sys_function sf
                         where sf.auto_id = wi.next_state) next_state,
                       next_state next_state_id,
                       dept_center,
                       (select stu.stru_name
                          from sys_stru stu
                         where stu.auto_id = wi.dept_level1) dept_level1,
                       (select stu.stru_name
                          from sys_stru stu
                         where stu.auto_id = wi.dept_level2) dept_level2,
                       (select stu.stru_name
                          from sys_stru stu
                         where stu.auto_id = wi.dept_level3) dept_level3,
                       (select stu.stru_name
                          from sys_stru stu
                         where stu.auto_id = wi.dept_cooperate1) dept_cooperate1,
                       (select stu.stru_name
                          from sys_stru stu
                         where stu.auto_id = wi.dept_cooperate2) dept_cooperate2,
                       is_reminder,
                       is_supervise,
                       is_overtime,
                       is_review,
                       to_char(wi.send_time, 'yyyy-mm-dd hh24:mi:ss') send_time,
                       to_char(wi.time_boundry, 'yyyy-mm-dd hh24:mi:ss') time_boundry,
                       source_address,
                       ciid1,
                       ciid2,
                       complaintname,
                       complainttel,
                       compensate_money,
                       back_source,
                       donereport,
                       reply_point,
                       to_char(wi.reply_time, 'yyyy-mm-dd hh24:mi:ss') reply_time,
                       solved,
                       passoperator,
                       to_char(wi.donetime, 'yyyy-mm-dd hh24:mi:ss') donetime,
                       dept_workno,
                       specialSeat_type,
                       to_char(wi.acceptTime_boundry, 'yyyy-mm-dd hh24:mi:ss') acceptTime_boundry,
                       to_char(wi.acceptTime, 'yyyy-mm-dd hh24:mi:ss') acceptTime,
                       orderSymbol,
                       timeout_flag,
                       send_flag,
                       getLastWorknoByWpid(wi.wpid) operatorno,
                       is_relation,
                       (select count(1)
                          from wp_info wp
                         where wp.relation_wpid = wi.wpid) total,
                       ep_flag,
                       is_difficult,
                       (select count(1)
                          from wp_early_warning_info
                         where wpid = wi.wpid) lid,
                       endresult
                  from xxx_info wi
                 where 1 = 1
                 order by wi.starttime desc) tmp_tb
         where ROWNUM <= 10)
 where row_id > 0
--执行时间 147s
通过 explain plan for 上述语句,获取其执行计划
select * from table(dbms_xplan.display());

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 964360475

---------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name                    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                         |    10 |   116K|       |   205K  (1)| 00:41:04 |
|   1 |  TABLE ACCESS BY INDEX ROWID| SYS_CODE                |     1 |    17 |       |     2   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | SYS_C005980             |     1 |       |       |     1   (0)| 00:00:01 |
|   3 |  TABLE ACCESS BY INDEX ROWID| SYS_CODE                |     1 |    17 |       |     2   (0)| 00:00:01 |
|*  4 |   INDEX UNIQUE SCAN         | SYS_C005980             |     1 |       |       |     1   (0)| 00:00:01 |
|   5 |  TABLE ACCESS BY INDEX ROWID| SYS_CODE                |     1 |    17 |       |     2   (0)| 00:00:01 |
|*  6 |   INDEX UNIQUE SCAN         | SYS_C005980             |     1 |       |       |     1   (0)| 00:00:01 |
|   7 |  TABLE ACCESS BY INDEX ROWID| SYS_CODE                |     1 |    17 |       |     2   (0)| 00:00:01 |
|*  8 |   INDEX UNIQUE SCAN         | SYS_C005980             |     1 |       |       |     1   (0)| 00:00:01 |
|   9 |  TABLE ACCESS BY INDEX ROWID| SYS_CODE                |     1 |    17 |       |     2   (0)| 00:00:01 |
|* 10 |   INDEX UNIQUE SCAN         | SYS_C005980             |     1 |       |       |     1   (0)| 00:00:01 |
|  11 |  TABLE ACCESS BY INDEX ROWID| SYS_CODE                |     1 |    17 |       |     2   (0)| 00:00:01 |
|* 12 |   INDEX UNIQUE SCAN         | SYS_C005980             |     1 |       |       |     1   (0)| 00:00:01 |
|  13 |  TABLE ACCESS BY INDEX ROWID| SYS_FUNCTION            |     1 |    15 |       |     1   (0)| 00:00:01 |
|* 14 |   INDEX UNIQUE SCAN         | SYS_FUNC_ID             |     1 |       |       |     0   (0)| 00:00:01 |
|  15 |  TABLE ACCESS BY INDEX ROWID| SYS_FUNCTION            |     1 |    15 |       |     1   (0)| 00:00:01 |
|* 16 |   INDEX UNIQUE SCAN         | SYS_FUNC_ID             |     1 |       |       |     0   (0)| 00:00:01 |
|  17 |  TABLE ACCESS BY INDEX ROWID| SYS_STRU                |     1 |    21 |       |     2   (0)| 00:00:01 |
|* 18 |   INDEX UNIQUE SCAN         | STRU_ID_PK              |     1 |       |       |     1   (0)| 00:00:01 |
|  19 |  TABLE ACCESS BY INDEX ROWID| SYS_STRU                |     1 |    21 |       |     2   (0)| 00:00:01 |
|* 20 |   INDEX UNIQUE SCAN         | STRU_ID_PK              |     1 |       |       |     1   (0)| 00:00:01 |
|  21 |  TABLE ACCESS BY INDEX ROWID| SYS_STRU                |     1 |    21 |       |     2   (0)| 00:00:01 |
|* 22 |   INDEX UNIQUE SCAN         | STRU_ID_PK              |     1 |       |       |     1   (0)| 00:00:01 |
|  23 |  TABLE ACCESS BY INDEX ROWID| SYS_STRU                |     1 |    21 |       |     2   (0)| 00:00:01 |
|* 24 |   INDEX UNIQUE SCAN         | STRU_ID_PK              |     1 |       |       |     1   (0)| 00:00:01 |
|  25 |  TABLE ACCESS BY INDEX ROWID| SYS_STRU                |     1 |    21 |       |     2   (0)| 00:00:01 |
|* 26 |   INDEX UNIQUE SCAN         | STRU_ID_PK              |     1 |       |       |     1   (0)| 00:00:01 |
|  27 |  SORT AGGREGATE             |                         |     1 |     2 |       |            |          |
|* 28 |   INDEX RANGE SCAN          | IDX_WPINFO_RELATIONWPID |    32 |    64 |       |     1   (0)| 00:00:01 |
|  29 |  SORT AGGREGATE             |                         |     1 |    15 |       |            |          |
|* 30 |   INDEX RANGE SCAN          | IDX_WEWI_WPID           |     1 |    15 |       |     1   (0)| 00:00:01 |
|* 31 |  VIEW                       |                         |    10 |   116K|       |   205K  (1)| 00:41:04 |
|* 32 |   COUNT STOPKEY             |                         |       |       |       |            |          |
|  33 |    VIEW                     |                         |  1051K|    11G|       |   205K  (1)| 00:41:04 |
|* 34 |     SORT ORDER BY STOPKEY   |                         |  1051K|   778M|  1026M|   205K  (1)| 00:41:04 |
|  35 |      TABLE ACCESS FULL      | WP_INFO                 |  1051K|   778M|       | 33545   (1)| 00:06:43 |
---------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
   4 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
   6 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
   8 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
  10 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
  12 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
  14 - access("SF"."AUTO_ID"=TO_NUMBER(:B1))
  16 - access("SF"."AUTO_ID"=TO_NUMBER(:B1))
  18 - access("STU"."AUTO_ID"=:B1)
  20 - access("STU"."AUTO_ID"=:B1)
  22 - access("STU"."AUTO_ID"=:B1)
  24 - access("STU"."AUTO_ID"=:B1)
  26 - access("STU"."AUTO_ID"=:B1)
  28 - access("WP"."RELATION_WPID"=:B1)
  30 - access("WPID"=:B1)
  31 - filter("ROW_ID">0)
  32 - filter(ROWNUM<=10)
  34 - filter(ROWNUM<=10)

该语句看起来挺长，但主要还是从WP_INFO 表取数据，无其他where条件限制，根据starttime 对全表倒序排序，取前十
执行计划看出WP_INFO表 行数1051K ，全表扫描，排序操作用了1026M空间。那么该如何优化呢？
既然存在排序行为，那么是否可以考虑在排序列建索引呢？索引存储了已排序好的非空列值，那么是否可以通过建索引的方式避免排序操作呢？

检查该表发现starttime列已经存在索引。
那么为什么不走索引呢？难道一定要有限制条件？还是说空值限制了索引的使用？ starttime 列确实可为空。
针对空值有两种处理办法：
1. 修改表的列 starttime 属性非空,但生产库岂敢随意修改。
alter table xxx modify starttime  not null;
2. Where 条件中添加限制，只取非空值，如下：
　　　　　　　　　　where 1 = 1
		 and wi.starttime is not null
　　　　　　　　　　order by wi.starttime desc) tmp_tb
查看新的执行计划：

 PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 793409466

----------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                         |    10 |   116K|    12   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID   | SYS_CODE                |     1 |    17 |     2   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN            | SYS_C005980             |     1 |       |     1   (0)| 00:00:01 |
|   3 |  TABLE ACCESS BY INDEX ROWID   | SYS_CODE                |     1 |    17 |     2   (0)| 00:00:01 |
|*  4 |   INDEX UNIQUE SCAN            | SYS_C005980             |     1 |       |     1   (0)| 00:00:01 |
|   5 |  TABLE ACCESS BY INDEX ROWID   | SYS_CODE                |     1 |    17 |     2   (0)| 00:00:01 |
|*  6 |   INDEX UNIQUE SCAN            | SYS_C005980             |     1 |       |     1   (0)| 00:00:01 |
|   7 |  TABLE ACCESS BY INDEX ROWID   | SYS_CODE                |     1 |    17 |     2   (0)| 00:00:01 |
|*  8 |   INDEX UNIQUE SCAN            | SYS_C005980             |     1 |       |     1   (0)| 00:00:01 |
|   9 |  TABLE ACCESS BY INDEX ROWID   | SYS_CODE                |     1 |    17 |     2   (0)| 00:00:01 |
|* 10 |   INDEX UNIQUE SCAN            | SYS_C005980             |     1 |       |     1   (0)| 00:00:01 |
|  11 |  TABLE ACCESS BY INDEX ROWID   | SYS_CODE                |     1 |    17 |     2   (0)| 00:00:01 |
|* 12 |   INDEX UNIQUE SCAN            | SYS_C005980             |     1 |       |     1   (0)| 00:00:01 |
|  13 |  TABLE ACCESS BY INDEX ROWID   | SYS_FUNCTION            |     1 |    15 |     1   (0)| 00:00:01 |
|* 14 |   INDEX UNIQUE SCAN            | SYS_FUNC_ID             |     1 |       |     0   (0)| 00:00:01 |
|  15 |  TABLE ACCESS BY INDEX ROWID   | SYS_FUNCTION            |     1 |    15 |     1   (0)| 00:00:01 |
|* 16 |   INDEX UNIQUE SCAN            | SYS_FUNC_ID             |     1 |       |     0   (0)| 00:00:01 |
|  17 |  TABLE ACCESS BY INDEX ROWID   | SYS_STRU                |     1 |    21 |     2   (0)| 00:00:01 |
|* 18 |   INDEX UNIQUE SCAN            | STRU_ID_PK              |     1 |       |     1   (0)| 00:00:01 |
|  19 |  TABLE ACCESS BY INDEX ROWID   | SYS_STRU                |     1 |    21 |     2   (0)| 00:00:01 |
|* 20 |   INDEX UNIQUE SCAN            | STRU_ID_PK              |     1 |       |     1   (0)| 00:00:01 |
|  21 |  TABLE ACCESS BY INDEX ROWID   | SYS_STRU                |     1 |    21 |     2   (0)| 00:00:01 |
|* 22 |   INDEX UNIQUE SCAN            | STRU_ID_PK              |     1 |       |     1   (0)| 00:00:01 |
|  23 |  TABLE ACCESS BY INDEX ROWID   | SYS_STRU                |     1 |    21 |     2   (0)| 00:00:01 |
|* 24 |   INDEX UNIQUE SCAN            | STRU_ID_PK              |     1 |       |     1   (0)| 00:00:01 |
|  25 |  TABLE ACCESS BY INDEX ROWID   | SYS_STRU                |     1 |    21 |     2   (0)| 00:00:01 |
|* 26 |   INDEX UNIQUE SCAN            | STRU_ID_PK              |     1 |       |     1   (0)| 00:00:01 |
|  27 |  SORT AGGREGATE                |                         |     1 |     2 |            |          |
|* 28 |   INDEX RANGE SCAN             | IDX_WPINFO_RELATIONWPID |    32 |    64 |     1   (0)| 00:00:01 |
|  29 |  SORT AGGREGATE                |                         |     1 |    15 |            |          |
|* 30 |   INDEX RANGE SCAN             | IDX_WEWI_WPID           |     1 |    15 |     1   (0)| 00:00:01 |
|* 31 |  VIEW                          |                         |    10 |   116K|    12   (0)| 00:00:01 |
|* 32 |   COUNT STOPKEY                |                         |       |       |            |          |
|  33 |    VIEW                        |                         |    10 |   116K|    12   (0)| 00:00:01 |
|  34 |     TABLE ACCESS BY INDEX ROWID| WP_INFO                |  1051K|   778M|    12   (0)| 00:00:01 |
|* 35 |      INDEX FULL SCAN DESCENDING| IDX_WPINFO_STIME        |    10 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
   4 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
   6 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
   8 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
  10 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
  12 - access("C"."AUTO_ID"=TO_NUMBER(:B1))
  14 - access("SF"."AUTO_ID"=TO_NUMBER(:B1))
  16 - access("SF"."AUTO_ID"=TO_NUMBER(:B1))
  18 - access("STU"."AUTO_ID"=:B1)
  20 - access("STU"."AUTO_ID"=:B1)
  22 - access("STU"."AUTO_ID"=:B1)
  24 - access("STU"."AUTO_ID"=:B1)
  26 - access("STU"."AUTO_ID"=:B1)
  28 - access("WP"."RELATION_WPID"=:B1)
  30 - access("WPID"=:B1)
  31 - filter("ROW_ID">0)
  32 - filter(ROWNUM<=10)
  35 - filter("WI"."STARTTIME" IS NOT NULL)

cost 从205k 下降到了12 ，评估执行时间从41min 下降到0.01 s， 效果很好有木有。看下面执行计划走了索引全扫描，没了排序操作。

实际执行 0.06s ，从147s 下降到0.06s 效率提升了2000多倍。
要等很久的一个查询秒出了。想想就有点小激动，所以记录一下。

总结：索引只保存确定值，而 Null 值不确定所以并不被索引记录，如果根据索引排序，那么这个排序并没有Null值，排序结果对于原表来说不准确，数据库不能返回给你一个假的结果，所以不能走索引。
如果索引列根本没有空值呢？所有的值都被索引所记录？ 事实是不论这个列是否有空值，但既然可以为空，那么数据库就认为可能存在空值,坚决不能走索引。
通过修改列属性为非空，或在条件中限制只取非空值，数据库就知道索引中确实包含了你需要的所有值，数据库就可以放心大胆的走索引了。
同理类似,select max/min/count(1)/count(*)  都会因为可能存在空值导致返回结果不准确而不走索引。

 

转载于:https://www.cnblogs.com/plluoye/p/8423838.html

weixin_30773135
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
mysql中NULL值对索引的影响
MRZHQ的博客
10-09 2248
mysql中NULL值对索引的影响NULL的三种形式innodb提供了一个系统变量： NULL的三种形式 NULL值代表一个未确定的值，每一个NULL值都是独一无二的，在统计列不重复值的时候应该都当作独立的。 NULL值在业务上就是代表没有，所有的NULL值代表的意义是一样的，所以所有的NULL值都一样，在统计列不重复值的时候应该只算一个。 NULL完全没有意义，在统计列不重复值的时候应该忽略NULL。 innodb提供了一个系统变量： show global variables like '%inno
MySQL中NULL对索引的影响深入讲解
12-16
前言 看了很多博客，也听过很多人说，包括我们公司的DBA，说MySql中如果某一列中含有null，那么包含该列的索引就无效了。 翻了下《高性能MySQL第二版》和《MySQL技术内幕——InnoDB存储引擎第2版》，并没有看到关于这个的介绍。但在本地试了下，null列是可以用到索引的，不管是单列索引还是联合索引，但仅限于is null，is not null是不走索引的。 后来在官方文档中找到了说明，如果某列字段中包含null，确实是可以使用索引的，地址：https://dev.mysql.com/doc/refman/5.7/en/is-null-optimization.html。
MySQL_列值为null对索引的影响_实践
weixin_30444105的博客
11-05 462
一.首先看一个我在某公众号看到的一个关于数据库优化的举措 二.如果where子句中查询的列执行了 “is null” 或者 “is not null” 或者 “<=> null” 会不会使用索引呢？ 先列出结论：where子句中使用上述对null的判断，如果判断的列设置了索引，那就可以使用到索引 官方依据在：https://dev.mysql.com/doc/refma...
MySQL中NULL值与索引：查询性能的影响
最新发布
My_wife_QBL的博客
06-29 664
在数据库设计和优化过程中，理解NULL值对索引使用的影响至关重要。NULL值在数据库中表示未知或不适用的值，而索引是提升查询性能的关键。本文将深入探讨MySQL中列值为NULL时，查询是否会用到索引，并提供示例SQL语句，以帮助数据库管理员和开发人员更好地理解和优化查询性能。
mysql建表的时候设置默认值为null会对存储和索引有影响吗？
gb4215287的博客
09-18 732
mysql建表的时候设置默认值为null会对存储和索引有影响吗？
分享一个自己写的table表格排序js插件(高效简洁)
10-28
`_Sort`函数则负责根据指定的列索引和排序规则（升序或降序）对数组进行排序。 在实际应用中，这个插件可能需要与其他功能（如隔行换色）配合使用。当增加新的功能时，可能会遇到兼容性问题，如描述中提到的“效果...
数据库索引
08-16
- **非聚集索引结构（a字段）**：对于特定的值（如`rf`），需要三次I/O操作，其余情况则需要一次。 - **非聚集索引结构（gender字段）**：对于特定的值（如`b`），需要三次I/O操作，其他情况下的次数不确定。 - **非...
c语言的选择排序
11-29
2. **查找最小值**：从第二个元素开始遍历整个数组，如果当前元素比`Min`所指向的元素还要小，则更新`Min`的值为当前元素的索引。 3. **交换位置**：当遍历结束后，如果`Min`不等于最开始的索引，则交换`arr[i]`和`...
CASE表达式实现基于条件逻辑来返回一个值
09-10
CASE表达式是SQL语言中的一种条件判断语句，它允许我们根据特定的条件来返回不同的值。在数据库查询中，CASE表达式常被用来转换、分类或者解释数据，尤其是在需要根据某一列的值来决定输出何种信息时。下面我们将...
索引列中有null值 会不会使索引失效？
zyjzyjjyzjyz的博客
11-06 2228
上面我说过mysql内部认为null是相等的，所以导致当插入过多null值，造成重复率过多，is null不会走索引。1、null_equal:认为所有的null值都是相等的，也是默认值，这种统计方式，会让优化器认为某个列中的平均一个值的重复次数特别多，倾向于不适用索引去访问。其实这和普通索引上的情况相同，我们把null值当成正常的值，mysql默认认为null是相同的，所以重复率特别高的话，优化器肯定不会走索引，而是走全表扫描。可以看到和上面的条件都是相同的，但是却是走了全表扫描，还没想明白？
空值对索引的影响
fmghbfn的博客
07-09 176
我们首先做一些测试数据： SQL&gt; create table t(x int, y int);   Table created   请注意，这里我对表t 做了一个唯一（联合）索 引： SQL&gt; create unique index t_idx on t(x,y);   Index cr...
NULL在MySQL中的角色: 索引的使用与影响
博客
02-08 979
索引是一种数据结构，用于加速数据库查询。它是一个独立的数据结构，包含指向实际数据的指针。在MySQL中，NULL值在索引的使用和性能方面可能会产生一些影响。了解NULL值的含义、在MySQL中的应用以及它与索引的关系，可以帮助我们更好地使用和管理NULL值和索引。
数据库优化之null和notnull使用对索引的可能影响（以mysql为例）
热门推荐
leige_ge的博客
08-23 1万+
大致分为四种情况 一 字段不可以为null 1.首先建一个name字段不可以为null的表，表中插入几条数据 CREATE TABLE staffs ( id INT PRIMARY KEY AUTO_INCREMENT, NAME VARCHAR (24) NOT NULL DEFAULT ” COMMENT ‘姓名’, age INT NOT NULL DEFAU...
使用索引的误区之四：空值对索引的影响
峰不疯
05-20 874
使用索引的误区之四：空值对索引的影响我们首先做一些测试数据：SQL> create table t(x int, y int); Table created 请注意，这里我对表t做了一个唯一（联合）索引：SQL> create unique index t_idx on t(x,y); Index created SQL> insert into t values(1,1); 1 row inse
MySQL索引失效的几种情况
weixin_34043301的博客
10-29 444
1.索引不存储null值 更准确的说，单列索引不存储null值，复合索引不存储全为null的值。索引不能存储Null，所以对这列采用is null条件时，因为索引上根本 没Null值，不能利用到索引，只能全表扫描。 为什么索引列不能存Null值？ 将索引列值进行建树，其中必然涉及到诸多的比较操作。Null值的特殊性就在于参与的运算大多取值为null。 这样的话，null值实际上是不能参与...
空值的排序规则与性能
lyu1026的博客
08-11 891
一、KingbaseES 对于空值的默认排序规则 KingbaseES 对于 null 值的排序默认是最大的，也就是比任何值都大。具体见以下例子： test=# create table test(id integer,name text); test=# insert into test values(1,'a'); test=# insert into test values(2,null...
MySQL中NULL对索引的影响
10-31 8770
https://www.jianshu.com/p/3cae3e364946 看了很多博客，也听过很多人说，包括我们公司的DBA，说MySql中如果某一列中含有null，那么包含该列的索引就无效了。 翻了下《高性能MySQL第二版》和《MySQL技术内幕——InnoDB存储引擎第2版》，并没有看到关于这个的介绍。但在本地试了下，null列是可以用到索引的，不管是单列索引还是联合索引，但仅限于i...
SQLServer2008案例：数据操作与函数应用
`CASE`函数允许条件性地返回不同的值，而空值处理函数（如ISNULL）则帮助处理数据库中的NULL值。 最后，资源中提到了逻辑主键和业务主键的概念。逻辑主键通常是无业务意义的自动递增ID，而业务主键则是基于业务数据...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值