一、 问题背景

给一个业务表online建索引时遇到了ORA-01450 maximum key length (3215) exceeded报错,看字面意思是字段太长了,检查表字段类型发现基本都是nvarchar2(2000),有些字段(例如unit)明显是不需要这么长的,表的设计有问题,联系开发按实际需求改短后能正常创建。

奇怪的是表的id字段类型也是nvarchar2(2000),但上面是有索引的,好奇为啥这个字段就能建上,以及为啥maximum key length是3215。

二、 报错分析

根据网上文章,9i之后每个index key最大只能为block size的80%。理论上8k的块可以创建最大长度为8096*80%约为6400左右长度的index。但是,online创建(包括rebuild)的过程中会生成一个中间的IOT表,用来记录创建过程中的变化。IOT表的限制比较严格,导致8k的block size最大长度只能有3215。当然普通创建的索引也是有限制的:ORA-01450: maximum key length (6398) exceeded。

按上面的建测试表和索引,发现的确online创建报错,而普通创建可以成功。因为nvarchar2(2000)字段最大可能长度是4000,创建索引时并不会看实际字段长度,直接按的最大长度。

建联合索引会报错,因为nvarchar2(2000)+nvarchar2(2000)字段最大可能长度是8000

再测试varchar2(2000)类型,发现普通创建和online都能成功,因为varchar2(2000)字段最大可能长度是2000

关于索引key最大长度,在文档 ID 136158.1中给出了不同BLOCK SIZE的限制,你会发现8K BLOCK SIZE的maximum key length 文档中写的是3218而不是我们遇到的3215。这可能是由于文档是针对8i的版本,在新版本中这个值变成了3215。

ORA-01450 maximum key length (758) exceeded  ->(2K Block)
ORA-01450 maximum key length (1578) exceeded ->(4K block)
ORA-01450 maximum key length (3218) exceeded ->(8K Block)
ORA-01450 maximum key length (6498) exceeded ->(16K Block)

报错中限制的KEY SIZE包含:索引的长度+存储索引长度的空间(2字节) + ROWID (6字节)+存储ROWID长度占用空间 (1字节),所以真正能够存放的列数据的长度只有3218-2-6-1=3209,新版本应该是3215-2-6-1=3206。

  • 这里的3209并不是实际的数据的长度,而是定义的列的长度。就像前面的例子,定义NVARCHAR2(2000),即使里面只存放了一个字符,创建索引时也会报这个错。ORACLE担心以后里面存放的数据万一超过了,索引那边没办法交代,所以干脆从源头上掐死。
  • 那能不能先定义一个小列,创建完索引后再把这个列的值改大?不行,你会遇到报错:ORA-01404: ALTER COLUMN will make an index too large,告诉你加大列长度的命令可能会导致索引太大
  • 这里面还有一个陷阱,就是你索引创建好了,一直使用也没问题,但是当你ONLINE REBUILD的时候却发现他的KEY SIZE超过限制了,导致索引只能不ONLINE的REBUILD,这对于24*7的系统而且必须REBUILD的情况比较痛苦。

常用的数据类型的KEY长度计算如下:

日期类型的长度是7;字符类型就是字段定义时候的长度;数字类型是22(数字类型的长度=精度/2+1),如果是负数,那么长度要再加1;如果是函数索引,那就要按照函数索引的返回值来进行计算。

为什么ONLINE创建只能使用不到BLOCK SIZE一半的空间?

ORACLE的管理手册中指明了索引的大小不能大于BLOCK_SIZE的一半,然后这一半的空间去掉ORACLE自己的PCTFREE、INITRANS以及BLOCK HEADER等等预留空间,实际可以使用的空间比一半要小很多。

当ONLINE创建一个索引,ORACLE为这个表的变化创建一个中间表,创建好后,ORACLE用表数据的一致性拷贝去创建一个新的索引,然后再把变化的记录拷贝到新创建的索引中,最后更新数据字典,删除临时段并删除这个中间表。这个过程将会锁表两次(ROW SHARE MODE)。一次是开始创建中间表时,另一次是结束时删除中间表。

中间表是一个名字类似SYS_JOURNAL_NNNNN的IOT表,其中的NNNNN是ONLINE REBUILD的索引的OBJECT_ID。因为IOT表的限制只能使用BLOCKSIZE的40%左右,而且这个IOT表的KEY就是索引中使用的KEY并加上ROWID的值,所以只有ONLINE创建或者REBUILD索引的时候会碰到这个问题。

下面来做一个演示,先创建一个表:

create table test(a varchar2(10),b varchar2(11),c varchar2(12),d number(10),e varchar2(13));

然后打开跟踪并ONLINE的创建索引:

create index idx_test on test(a,b,c,d,e) online;

关闭跟踪并查看TRACE文件,可以发现如下语句:


  1. create table "SYS"."SYS_JOURNAL_74346" (C0 VARCHAR2(10), C1 VARCHAR2(11), C2 VARCHAR2(12), C3 NUMBER(10,0), C4
  2. VARCHAR2(13), opcode char(1), partno number, rid rowid, primary key( C0, C1, C2, C3, C4 , rid )) organization
  3. index TABLESPACE "SYSTEM"

其中前面的C0,C1等列就是索引的KEY值,索引由几列组成,临时IOT表也会对应创建,后面三列是不变的,根据字面意思推测应该是操作的代码(增加、删除、更新) 、分区号(分区索引用到)、ROWID。而主键是由所有的KEY值和ROWID列组成,这也正好跟前面的长篇大论相吻合。至于IOT为啥只能用一半,有些说是为了B*TREE的分裂,有些说是ORACLE老版本的小问题,结果为了兼容一直没改。

四、解决方法

查询文档,这个问题其实有挺多绕过的方法,整理学习一下。

1. 改短字段后创建

对于表设计明显不合理的情况,这是比较合理的方法。

查看字段实际最大长度


  1. select max ( length ( text_column ) ) mx_char_length,
  2. max ( lengthb ( text_column ) ) mx_byte_length
  3. from some_table;

改短字段长度

alter table some_table modify text_column nvarchar2(100);

如果确实不能改短,下面有一些workaround,但它们都有各自的限制,需要根据实际选择。

2. 不使用online创建

对于前面的例子,nvarchar2(2000)的字段可以用这个方法绕过最大长度限制。但也就像之前写的,这个长度没办法创建联合索引,以后也不能使用online rebuild,对于7*24小时的系统,如果是大表可能难以接受。

3. 使用更大的block size存储索引

将索引存放在单独的表空间,并将表空间block size设为16k或32k,当然也需要先设置好DB_nK_CACHE_SIZE 参数。这种方法打破了DB的标准化,可能会使运维管理更加复杂。


  1. alter system set DB_32K_CACHE_SIZE=256M;
  2. create tablespace tblsp_32k_blocks datafile 'tblsp_32k_blocks' size 1m blocksize 32768;
  3. create index text_index on some_table(text_column) tablespace tblsp_32k_blocks;

4. 创建基于STANDARD_HASH函数的索引

standard_hash函数会返回一个固定长度的值,在等值查询时能用到该索引。


  1. create index text_index on some_table(standard_hash(text_column));
  2. select * from some_table where text_column = 'this';
  3. ----------------------------------------------------------
  4. | Id | Operation | Name |
  5. ----------------------------------------------------------
  6. | 0 | SELECT STATEMENT | |
  7. |* 1 | TABLE ACCESS BY INDEX ROWID BATCHED| SOME_TABLE |
  8. |* 2 | INDEX RANGE SCAN | TEXT_INDEX |
  9. ----------------------------------------------------------

但范围查询和like查询都用不到


  1. select * from some_table where text_column >= 't' and text_column<'u';
  2. ----------------------------------------
  3. | Id | Operation | Name |
  4. ----------------------------------------
  5. | 0 | SELECT STATEMENT | |
  6. |* 1 | TABLE ACCESS FULL| SOME_TABLE |
  7. ----------------------------------------
  8. select * from some_table where text_column like 'this%';
  9. ----------------------------------------
  10. | Id | Operation | Name |
  11. ----------------------------------------
  12. | 0 | SELECT STATEMENT | |
  13. |* 1 | TABLE ACCESS FULL| SOME_TABLE |
  14. ----------------------------------------

5. 创建基于substr函数的索引

对于范围查询,可以使用基于substr函数的索引(like依然用不到),但是它可能会导致查询效率较低。


  1. create index text_substr_index on some_table(substr(text_column,1,10));
  2. select * from some_table where text_column = 'this';
  3. -----------------------------------------------------------------                     
  4. | Id  | Operation                           | Name              |                     
  5. -----------------------------------------------------------------                     
  6. |   0 | SELECT STATEMENT                    |                   |                     
  7. |*  1 |  TABLE ACCESS BY INDEX ROWID BATCHED| SOME_TABLE        |                     
  8. |*  2 |   INDEX RANGE SCAN                  | TEXT_SUBSTR_INDEX |                     
  9. -----------------------------------------------------------------                     
  10.                                                                                         
  11. select * from some_table where text_column >= 't' and text_column < 'u';
  12. -----------------------------------------------------------------          
  13. | Id  | Operation                           | Name              |          
  14. -----------------------------------------------------------------          
  15. |   0 | SELECT STATEMENT                    |                   |          
  16. |   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| SOME_TABLE        |          
  17. |   2 |   INDEX RANGE SCAN                  | TEXT_SUBSTR_INDEX |          
  18. -----------------------------------------------------------------
  19.  
  20. select * from some_table where text_column like 'this%';
  21. ----------------------------------------                   
  22. | Id  | Operation         | Name       |                   
  23. ----------------------------------------                   
  24. |   0 | SELECT STATEMENT  |            |                   
  25. |   1 |  TABLE ACCESS FULL| SOME_TABLE |                   
  26. ----------------------------------------

6. 定义virtual列

虚拟列其实就是对列进行运算或者在列上使用函数,oracle在运行时才会计算该列的值。我们可以用standard_hash函数建虚拟列,然后对该列建普通索引。虚拟列相比函数索引有以下好处:

  • 优化器可获得虚拟列的统计信息
  • 能够看到索引值,更易于理解

  1. alter table some_table add text_hash varchar2(40 char) as (standard_hash(text_column));
  2. create index vc_text_hash_index on some_table (text_hash);

7. 使用全文索引(Oracle Text Index)

创建时需要指定indextype子句,查询时使用contains操作符


  1. create index oracle_text_index on some_table(text_column) indextype is ctxsys.context;
  2. select * from some_table where contains (text_column,'value')>0;

参考

https://blog.csdn.net/tnndwdl/article/details/78452967

https://blogs.oracle.com/sql/how-to-fix-ora-01450-maximum-key-length-6398-exceeded-errors

ORA-01450 and Maximum Key Length - How it is Calculated (文档 ID 136158.1)

</article>

[转帖]ORA-01450 maximum key length (3215) exceeded的更多相关文章

  1. Using innodb_large_prefix to avoid ERROR #1071,Specified key was too long; max key length is 1000 bytes

    Using innodb_large_prefix to avoid ERROR 1071        单列索引限制上面有提到单列索引限制767,起因是256×3-1.这个3是字符最大占用空间(ut ...

  2. ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes

    今天在MySQL 5.6版本的数据库中修改InnoDB表字段长度时遇到了"ERROR 1071 (42000): Specified key was too long; max key le ...

  3. 索引长度过长 ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes

    1.发现问题 今天在修改innodb表的某个列的长度时,报如下错误: alter table test2 modify column id varchar(500); ERROR 1071 (4200 ...

  4. django.db.utils.OperationalError: (1071, 'Specified key was too long; max key length is 767 bytes');

    在使用utf8mb4字符集的情况下,如果列存在索引,那么varchar的最大长度是191 数据库版本: 在使用utf8字符集的情况下,如果列存在索引,那么varchar的最大长度是255. 在大字段上 ...

  5. used in key specification without a key length

    官方的解释: The error happens because MySQL can index only the first N chars of a BLOB or TEXT column. So ...

  6. 数据库操作提示:Specified key was too long; max key length is 767 bytes

    操作重现: 法1:新建连接——>新建数据库——>右键数据库导入脚本——>提示:Specified key was too long; max key length is 767 by ...

  7. Mysql Specified key was too long; max key length is 767 bytes

    今天导入一个数据库时,看到以下报错信息: Specified key was too bytes 直译就是索引键太长,最大为767字节. 查看sql库表文件,发现有一列定义如下: 列   名:cont ...

  8. Specified key was too long; max key length is 767 bytes mysql

    Specified key was too long; max key length is 767 bytes 说明: 执行当前 Web 请求期间,出现未经处理的异常.请检查堆栈跟踪信息,以了解有关该 ...

  9. mysql 索引过长1071-max key length is 767 byte

    问题 create table: Specified key was too long; max key length is 767 bytes   原因 数据库表采用utf8编码,其中varchar ...

  10. [Bug]The maximum array length quota (16384) has been exceeded while reading XML data.

    写在前面 在项目中,有客户反应无法正常加载组织结构树,弄了一个测试的程序,在日志中查看到如下信息: Error in deserializing body of reply message for o ...

随机推荐

  1. postman——请求与相应

    一.新建一个项目 直接点击左边栏上面的添加目录图标来新增一个根目录,这样就等于新建了一个项目,我们可以把一个项目或一个模块的用例都存放在这个目录之下,并且在根目录之下我们还可以在建立子目录来进行功能用 ...

  2. ASR项目实战-语音识别

    本文深入探讨语音识别处理环节. 本阶段的重点特性为语音识别.VAD.热词.文本的时间偏移.讲话人的识别等. 语音识别 业界流派众多,比如Kaldi.端到端等,具体选择哪一种,需要综合考虑人员能力.训练 ...

  3. 文心一言 VS 讯飞星火 VS chatgpt (170)-- 算法导论13.2 3题

    三.用go语言,设在图 13-2 左边一棵树中,a.b和c 分别为子树a.β和γ中的任意结点.当结点 x 左旋之后,a.b和c 的深度会如何变化? 文心一言: 在二叉树中,左旋操作是改变节点的子节点顺 ...

  4. 【开源项目推荐】Great Expectations—开源的数据质量工具

    大家好,我是独孤风. 又到了本周的开源项目推荐.数据质量是企业进行数据治理非常重要的一个环节,高质量的数据对管理决策,业务支撑都有非常重要的作用. 只有持续的数据质量改进才能推动数据治理体系的完善,差 ...

  5. C#数据结构与算法系列(十六):时间复杂度(上)

    1.时间频度 介绍: 一个算法花费的时间与算法中语句的执行次数成正比例,哪个算法中语句执行次数多,他花费时间越多.一个算法中的语句执行次数称为语句频度或时间频度 举例说明: 比如计算1-100所有数字 ...

  6. Python图像处理丨图像的灰度线性变换

    摘要:本文主要讲解灰度线性变换. 本文分享自华为云社区<[Python图像处理] 十五.图像的灰度线性变换>,作者:eastmount. 一.图像灰度线性变换原理 图像的灰度线性变换是通过 ...

  7. 为了减少代码复杂度,我将if-else升级为面向状态编程

    摘要:面向过程设计和面向对象设计的主要区别是:是否在业务逻辑层使用冗长的if else判断. 本文分享自华为云社区<从面向if-else编程升级为面向状态编程,减少代码复杂度>,作者:br ...

  8. 基于迁移学习的基础设施成本优化框架,火山引擎数智平台与北京大学联合论文被KDD收录

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群   基于迁移学习的基础设施成本优化框架,火山引擎数智平台与北京大学联合论文被KDD收录 近期,第29届国际知识发现 ...

  9. Axure 标记元件

    快照:可以用来表示控件的截图功能 箭头:有了连线,基本很少用它 便签:相关于便利贴,写些说明.备注, 标记:标记好数字,对应数字的标记做解释说明

  10. 深入了解 ReadDirectoryChangesW 并应用其监控文件目录

    简介 监视指定目录的更改,并将有关更改的信息打印到控制台,该功能的实现不仅可以在内核层,在应用层同样可以.程序中使用 ReadDirectoryChangesW 函数来监视目录中的更改,并使用 FIL ...