精华内容
下载资源
问答
  • 最近刚开始使用spring-boot框架来做项目,使用框架自动生成代码是真滴爽,但是会使我们对于较为底层的代码生疏,尤其是封装性越好的框架,越容易使人忽略底层。...这就在考虑一个问题,修改字段长度会不会影...

    最近刚开始使用spring-boot框架来做项目,使用框架自动生成代码是真滴爽,但是会使我们对于较为底层的代码生疏,尤其是封装性越好的框架,越容易使人忽略底层。


    好了,说一下我的问题

    问题

    使用框架自动生成了前端页面和controller层、entity层等代码后,发现数据库中对name设置的字段长度不统一,想要将长度为255的name字段统一变为80。

    这就在考虑一个问题,修改字段长度会不会影响程序正常运行,尤其是自动生成的部分代码,涉及到很多表,还要重新生成编译,感觉很是麻烦,又不敢不生成。

    解决办法

    通过查询和寻问大佬,发现修改字段长度会不会影响程序,是要分情况的:

    1.增长字段长度

    理论上是不会影响程序正常运行的(在你没有其他骚操作的情况下)。

    2.缩减字段长度

    • 数据库对应字段尚未存入数据情况下,不会影响程序正常运行。
    • 数据库对应字段存入数据,但是数据长度没有超过缩减到的长度的情况下,不会影响程序正常运行。
    • 数据库对应字段存入数据,数据长度超过缩减到的长度的情况下,会影响程序正常运行,需要修改程序对应部分。

    由于在赶项目的进度,所以就没有深入探究原理,先欠上,日后一定补回来!

    展开全文
  • 而当需要启用到预留的字段时,可能已经有很多数据,此时要根据需要修改字段长度, 若能够不需要重做数据,则能够减少这个修改操作对线上服务的影响。 几点说明 1、 注意到这里适用的是varchar类型, char类型.....

    前一篇文章末尾提到InnoDB快速修改字段长度。其实用场景在于,在设计表时,若需要预留varchar类型字段,还无法确定实际需要的长度。而当需要启用到预留的字段时,表中可能已经有很多数据,此时要根据需要修改字段长度, 若能够不需要重做数据,则能够减少这个修改操作对线上服务的影响。

    几点说明

    1、 注意到这里适用的是varchar类型, char类型不在本文讨论范围内。实际上,由于varchar类型字段数据并不是直接存储在聚簇索引中,才使得快速修改成为可能。而char类型改变长度至少要将整个聚簇索引重做,因此不能做到“不修改数据”

    2、 与前一篇文章的思路类似,我们的目的是在执行alter table语句的时候,只修改frm文件。

    3、 当然实际执行alter table修改字段长度的时候,考虑到字段中可能已经有数据,因此若是长度定义变小,则必须重做数据,因为超过长度的数据要作截断,否则逻辑上就不通过了。 因此这里只适用于将长度改大的情况。 从我们的需求出发点来看,这一点问题并不大,在预留的时候设置“小一些”即可。(小是相对的,后面会说到)

    4、 我们用到的语句形如 alter table t c c varchar(300) default null. c字段原来声明为varchar(290) default null.

    源码分析

    从前一篇文章中我们知道MySQLcompare_tables这个函数中判断当前执行的alter table语句是否需要重做数据。

    在这个函数中有这么一段

    /*

    Go through fields and check if the original ones are compatible

    with new table.

    */

    for()

    {

    if (!(tmp= field->is_equal(tmp_new_field)))

    {

    *need_copy_table= ALTER_TABLE_DATA_CHANGED;

    DBUG_RETURN(0);

    }

    }

    for循环中对每个字段的修改作了判断,其中field->is_equal就用于判断修改前后的字段定义是否完全相同。这里field是一个基类对象,通过多态调用Field_varstring::is_equal (sql/field.cc).

    uint Field_varstring::is_equal(Create_field *new_field)

    {

    if (new_field->sql_type == real_type() &&

    new_field->charset == field_charset)

    {

    if (new_field->length == max_display_length())

    return IS_EQUAL_YES;

    if (new_field->length > max_display_length() &&

    ((new_field->length <= 255 && max_display_length() <= 255) ||

    (new_field->length > 255 && max_display_length() > 255)))

    return IS_EQUAL_PACK_LENGTH; // VARCHAR, longer variable length

    }return IS_EQUAL_NO;

    }

    这个函数的逻辑比较简单。 real_type()返回的是当前的字段类型(当然是varcahr), field_charset是当前字段实用的字符集, max_display_length()返回当前定义的长度。

    我们看到这个函数有三种返回值, 其中IS_EQUAL_PACK_LENGTH类似我们需要的情况,为什么说类似呢, 这个判断中要求的不仅仅是长度增大,还要求修改前后的长度定义,要么都小于255,要么都大于255 这个深层原因给我们带来一点麻烦,后面再说。

    IS_EQUAL_PACK_LENGTH这个返回值,说明框架层考虑到这种情况是可以特殊处理的,而遗憾的是InnoDB源码中没有利用这个值,我们就用这个返回值来修改一下InnoDB中的判断逻辑。

    简单修改

    为了不影响其他引擎的结果,我们只在InnoDB内部修改。我们知道check_if_incompatible_data这个函数的返回值,决定了MySQL是否重做表数据。

    bool

    ha_innobase::check_if_incompatible_data(

    HA_CREATE_INFO* info,

    uint table_changes)

    {

    if (table_changes != IS_EQUAL_YES) {

    return(COMPATIBLE_DATA_NO);

    }

    }

    这个传入的table_changes, 是前面各种判断的异或结果(因此在我们的例句中,这里的值是IS_EQUAL_YES|IS_EQUAL_PACK_LENGTH)

    这里判断逻辑要求必须是 IS_EQUAL_YES. 按照我们的分析,修改成如下

    bool

    ha_innobase::check_if_incompatible_data(

    HA_CREATE_INFO* info,

    uint table_changes)

    {

    if ((table_changes == IS_EQUAL_NO) ||

    (table_changes & ~(IS_EQUAL_YES|IS_EQUAL_PACK_LENGTH) != 0)) return(COMPATIBLE_DATA_NO);

    }

    }

    说明:虽然目前只有三种返回值,但从逻辑严谨出发,还是要判断table_changes是否在(IS_EQUAL_YES|IS_EQUAL_PACK_LENGTH)所表示的位标识范围内。

    重新编译发布后,执行结果如下。

    mysql> alter table t c c varchar(300) default null;

    Query OK, 0 rows affected (0.01 sec)

    Records: 0 Duplicates: 0 Warnings: 0

    可以看到,这回执行基本不需要时间。

    遗留问题

    细心读者一定发现我们的例子故意绕过了上面说到的255的问题,实际上如果原来定义为varchar(4) 再修改为varchar(300),按照我们的实现,还是需要重做数据的。

    判断逻辑可以很简单的修改,问题是,MySQL为什么要作这个255的分界判断?

    实际上,varchar字段的实际内容前有1个或2个字节表示实际内容的长度,而到底是1个字节还是2个字节,就取决于创建表或修改的时候,这个字段声明的长度。也就是说,varchar(4) 字段的实际内容前,用1个字节表示实际长度,而varchar(300)的实际内容前,用2个字节。

    因此,如果只是在修改前后长度在255两侧,则必须重做数据。

    这样造成的问题是,从我们的需求出发,要预留字段时候,就必须先估计预留的字段大概的长度(是否超过255)。

    可以将所有的varcahr字段都预留超过255字节,问题并不大,只是增加了1个字节空间而已。

    遗留问题的解决方案

    当然这事儿也不是不能解决的,InnoDB是为了节省空间,如果我们放弃这个节省策略,对于所有的varchar,都用2个字节来保存实际长度,就没这个问题了。下篇再续。

    再次呼唤,本文所作修改目前只作了简单的回归测试。还没有完全确认是否引入副作用,若有相关文章涉及与此相关,请回复或站内私信我。

    展开全文
  • 前两天测试同学问了一个问题,中某一个字段,需要改一下长度,对业务是否会有影响可能隐约之中,我们觉得没影响,但又好像有影响,究竟有何影响,我们从实验来看最科学。 首先建测试,NAME字段是...

    前两天测试同学问了一个问题,表中某一个字段,需要改一下长度,对业务是否会有影响?

     

    可能隐约之中,我们觉得没影响,但又好像有影响,究竟有何影响,我们从实验来看最科学。

     

    首先建测试表,NAME字段是VARCHAR2(10),10个字节的字符串类型,表有256万数据。我们将其长度改为20,从执行时间看,只有20毫秒,

     

     

    我们对上面的操作,做一下10046 trace,发现确实,首先使用LOCK以EXCLUSIVE模式锁定了TBL表,

     

    接下来执行alter table修改操作,

     

     

    从trace文件看,主要是针对一些数据字典表的操作,其中包含28次select,10次update,12次delete,可以想象一个改字段长度的操作,就有几十次SQL操作,但用时仅为毫秒级,效率可见一斑。

     

    我们从alter table新增字段操作究竟有何影响?(下篇)的介绍,可以知道,EXCLUESIVE模式的锁,是最高级别的锁,Alter table,Drop table,Drop index,Truncate table这些常见的DDL操作,都会需要这种级别的锁,我们知道Oracle中select这种查询(不带for update)是不会有锁的,因此若表有EXCLUSIVE级别的锁时,仅允许select操作(不带for update),禁止其他类型的操作,

    从锁的强弱看,EXCLUSIVE(exclusive,X)>SHARE ROW EXCLUSIVE(S/Row-X,SRX)>SHARE(Share,S)>ROW EXCLUSIVE(Row-X,RX)>ROW SHARE(Row-S,RS)。

     

    最后,引述一篇博客的总结(http://blog.itpub.net/9252210/viewspace-626388/),

    2级锁Row-S行共享(RS):共享表锁,sub share,锁有:Select for update,Lock For Update,Lock Row Share。

    3级锁Row-X行独占(RX):用于行的修改,sub exclusive,锁有:Insert, Update, Delete, Lock Row Exclusive。

    4级锁Share共享锁(S):阻止其他DML操作,share,锁有:Create Index, Lock Share,locked_mode为2,3,4不影响DML(insert,delete,update,select)操作, 但DDL(alter,drop等)操作会hang。

    5级锁S/Row-X共享行独占(SRX):阻止其他事务操作,share/sub exclusive,锁有:Lock Share Row Exclusive,具体来讲有主外键约束时update / delete … ; 可能会产生4,5的锁。

    6级锁exclusive 独占(X):独立访问使用,exclusive,锁有:Alter table, Drop table, Drop Index, Truncate table, Lock Exclusive。

     

    因此,针对上面VARCHAR2(10)改为VARCHAR2(20)的操作,我们的结论是修改字段长度的操作是会阻碍其他非select操作,但是持续的时间很有限,几乎可以说是忽略不计,因为需要操作的是数据字典信息,并不是表自身,所以和要操作表的记录总量,没有任何关系。

     

    无意之中,发现了另一个问题,将字段长度从VARCHAR2(20)改为VARCHAR2(10),用时比之前要久,540毫秒,几乎是之前的10倍,

     

    我们看下他的trace,首先还是以EXCLUSIVE模式锁表,

     

    接着执行alter table操作,

     

    我们从下面的信息,看出了一些端倪,

     

    以FIRST_ROWS优化器模式执行select操作,条件是字段NAME长度>10,因为现在是要将字段长度,从20改为10,就需要判断是否已存数据中,有违反长度的记录,如果有则禁止此操作,所以需要以全表扫描,来检索表中所有记录,rows是0,则继续执行其他操作,需要注意的是,他采用了FIRST_ROWS模式,会以最快的速度返回记录,因此执行时间还是可控的,从操作上来看,整个操作包含27次select,10次update,12次delete,其中判断LENGTH("NAME")>10的语句占用了几乎90%的SQL执行时间。

     

    总结:

    1. 若是增加长度的操作,会以EXCLUSIVE模式锁表,但其主要操作的是数据字典表,锁占用时间几乎可以忽略不计,所以几乎不会影响业务。

    2. 若是缩短长度的操作,还会以EXCLUSIVE模式锁表,但需要以FIRST_ROWS优化器模式,执行全表扫描,判断已存数据是否有超长的记录,因此相比(1)执行时间会略久,但基本可控。

     

     

     

    展开全文
  • 目录 怎样控制哈希长度 怎样设计哈希函数 字符串哈希算法 优秀的字符串哈希算法 怎样处理哈希冲突 ...哈希长度一般是定长的,在存储数据之前我们应该知道存储的数据规模是多大,应该尽可能地避免频...

    目录

    怎样控制哈希表的长度

    怎样设计哈希函数

    字符串哈希算法

    优秀的字符串哈希算法

    怎样处理哈希冲突

    一、开放定址法

      1.线性探测法

      2.二次探测法

      3.再哈希法

    二、拉链法(哈希桶)


    哈希表的设计主要是为了对内存中的数据进行快速查找,它的查找时间复杂度是O(1)。设计一个哈希表的关键有三个:怎么控制哈希表的长度,怎么设计哈希函数,怎么处理哈希冲突。

     

    怎样控制哈希表的长度

    哈希表的长度一般是定长的,在存储数据之前我们应该知道存储的数据规模是多大,应该尽可能地避免频繁地让哈希表扩容。我们设计的哈希表的大小,必须要做到尽可能地减小哈希冲突,并且也要尽可能地不浪费空间,选择合适的哈希表的大小是提升哈希表性能的关键。

    当我们选择哈希函数的时候,经常会选择除留余数法,即用存储数据的key值除以哈希表的总长度,得到的余数就是它的哈希值。常识告诉我们,当一个数除以一个素数的时候,会产生最分散的余数(哈希值会对key有更多的依赖)。由于我们通常使用表的大小对哈希函数的结果进行模运算,如果表的大小是一个素数,那么这样我们就会尽可能地产生分散的哈希值。

    哈希表中还有一个概念就是表的装填因子(负载因子),它的值一般被定义为:

    装填因子 a = 总键值对数(下标占用数)/ 哈希表总长度装填因子 a = 总键值对数(下标占用数) /  哈希表总长度

    至于为什么要设计这样一个概念,我们可以想,如果一个哈希表中的数据装的越多,是不是越容易发生哈希冲突。如果当哈希表中满到只剩下一个下标可以插入的时候,这个时候我们还要往这个哈希表中插入数据,于是我们可能会达到一个O(n)级别的插入效率,我们甚至要遍历整个哈希表才可能找到那个能存储的位置。

    通常,我们关注的是使哈希表平均查找长度最小,把平均查找长度保证在O(1)级别。装填因子a的取值越小,产生冲突的机会就越小,但是也不能取太小,这样我们会造成较大的空间浪费。即如果我们a取0.1,而我们哈希表的长度为100,那我们只装了10个键值对就存不下了,就要对哈希表进行扩容,而剩下90个键值对空间其实是浪费了的。通常,只要a取的合适(一般取0.7-0.8之间),哈希表的平均查找长度就会是常数也就是O(1)级别的

    当然,根据数据量的不同,会有不同的哈希表的大小。当数据量小的时候,最好就是能够实现哈希表扩容的机制,即达到了哈希表当前长度的装填因子,我们就需要扩大哈希表大小,一般都是乘2。

    下面,对上面这些观点进行一个总结,来设计一个效率尽可能高的哈希表大小

    1. 确保哈希表长度是一个素数,这样会产生最分散的余数,尽可能减少哈希冲突
    2. 设计好哈希表装填因子,一般控制在0.7-0.8
    3. 确认我们的数据规模,如果确认了数据规模,可以将数据规模除以装填因子,根据这个结果来寻找一个可行的哈希表大小
    4. 当数据规模可能会动态变化,不确定的时候,这个时候我们也需要能够根据数据规模的变化来动态给我们的哈希表扩容,所以一开始需要自己确定一个哈希表的大小作为基数,然后在此基础上达到装填因子规模时对哈希表进行扩容。

     

    怎样设计哈希函数

    哈希函数,是用来计算存储数据的哈希值的,根据存储数据的类型,可以设计不同的哈希函数。

    一个好的哈希函数(让哈希表效率高的函数),一般都具备下面两个特点:

    1. 速度快(能够快速的计算一个key的哈希值)
    2. 能够将得到的哈希值均匀地分布在整个哈希表中,尽量不产生聚集

    通常一个哈希函数具有下面的形式:哈希值 = 计算后的存储值 / 哈希表的大小

    对于如果存储的数是整数这种类型,我们完全可以不用计算,直接将整数的值作为上式中计算后的存储值。

    而对于非整数,如字符串这种类型,我们要设计一个相对较好的算法,来计算出它们的存储值。

    下面介绍一些常见的字符串哈希算法,其他类型的数据都可以用相似的思路来设计适合自己的哈希算法。

    字符串哈希算法

    马上就能想到的算法:简单地将字符串中每个字符的ASCII码加起来

    size_t stringHash(const string& key){
        size_t hashKey = 0;
     
        for(size_t i = 0; i < key.size(); ++i)
            hashKey += key[i];
        
        return hashKey;
    }

    用上面的方法可以很快地算出哈希值,但是如果表很大时,则函数就不能很好的分配。比如我的表的大小是10000,即我的数据规模大概是7000个左右(取装填因子为0.7),但是我的字符最多只有8个字符长,由于ASCII码最大值是127,因此hash函数计算出来的哈希值只能在0-1016之间取值,其中127 * 8 =1016,这就会有一种聚集的效果,这就不是我们上面提到的两点想要的,我们要尽可能地避免聚集。

    这个方法可能是刚接触字符串哈希函数的人会马上想到的,但其实我们有很多的优秀的字符串哈希算法。

    优秀的字符串哈希算法

    BKDR哈希算法

    size_t BKDR_hash(const string& key){
        size_t hashKey = 0;
        size_t seed = 131;    //也可以是31 131 1313 13131 131313
        for(size_t i = 0; i < key.size(); ++i)
            hashKey += hashKey * seed + key[i];
     
        return hashKey;
    }

    根据上面的算法,我们就可以根据结果得到非聚合的一些哈希值。

    这个算法是效率很高的一个算法,其他的字符串算法可以看这里:字符串哈希算法,是人家总结的一篇文章,涵盖了当今很多的哈希算法。

     

    怎样处理哈希冲突

    所谓哈希冲突,就是两个key值经过哈希函数计算以后得到了相同的哈希值,而一个下标只能存放一个key,这就产生了哈希冲突。

    产生了哈希冲突,我们就要解决。选择一个好的解决哈希冲突的方法,也是提高哈希表效率的关键。

    一、开放定址法

    当冲突发生时,通过查找哈希表的一个空位,将数据填入。

    根据查找空位时,查找下标的增量取值方式,再细分为三种:

      1.线性探测法

    线性探测空位。当数据通过哈希函数计算应该放在 i 这个位置,但是 i 这个位置已经有数据了,那么接下来就应该查看 i+1 位置是否空闲,再查看 i+2 位置,依次类推,直至找到空位置。

    需要注意的是,当哈希表中接近被填满时,向表中插入数据就会效率很低,当hash表真的被填满了,这时候算法应该停止,在这之前应该对数组进行扩展,对hash表中的数据进行转移。

    聚集现象:当哈希表越来越满时,这导致产生非常长的探测长度,后续的数据插入将会非常费时。通常数据超过三分之二满时性能下降严重,因此设计哈希表关键确保不会超过这个数据容量的一半,最多不超过三分之二。

      2.二次探测法

    从冲突位置不断往后找x的二次方的下标,其中x从1开始线性增大。也就是:1,4,9,16,25........

    二次探测可以消除在线性探测中产生的聚集问题,但是二次探测还是会产生一种更明确更细的聚集:二次聚集。二次聚集是在二次探测的基础上产生的现象。

    二次探测并不常用,解决聚集问题还是有一种更好的办法:再哈希法。

      3.再哈希法

    再哈希法是在二次探测法的基础上将步长的改进:当第一次哈希发生冲突时,第二次哈希得到的结果是索引需要加的值。这样不同的key各自对应着不同的探测步长,发生聚集的几率大大降低。

    缺点:每次冲突都要重新哈希,计算时间增加。

    二、拉链法哈希桶

    每个下标中存的都是一个链表,相同哈希值的key直接插入到链表。

    这种方法的特点是表的大小和存储的数据数量差不多(大不了每个下标都只放一个节点,如果下标一样的都是放在同一下标的链表中,并没有占据新的下标),因此哈希桶的方法没有特别依赖于装载因子,哈希表快满时,它还是可以做到较好的效率,而开放地址法就需要保证装载因子。

    拉链法的缺点:

    • 它需要稍微多一点的空间来存放元素,因为还要有一个指向下一个节点的指针。
    • 每次探测也要花费较多的时间,因为它需要间接引用指针,而不是直接访问元素。

    但其实这些缺点是微不足道的,所以实际使用哈希时,一般都是用哈希桶来解决冲突(C++STL的hash_map用的就是拉链法)

     

    手写拉链法的哈希表【C++】

    C++11新特性:STL中的无序关联容器unordered_map的底层实现和用法

     

    展开全文
  • 在mysql中alter命令可以修改字段类型,长度,名称或一些其它的参数,下面我来给大家介绍alter函数修改字段长度与类型的两个命令,希望文章来给各位带来帮助。 mysql 修改字段长度 alter table news modify ...
  • 一:Http Get方法提交的数据大小长度无限制...:web服务器对其长度最大限制(字符) Apache :8192 IIS:16384 3>:各浏览器允许域下的最大cookie数目 IE :原先为20个,后来升级为50个 Firefox: 50个 Opera:30个
  • 哈希查找——成功和不成功时的平均查找长度

    万次阅读 多人点赞 2017-09-17 13:27:21
    哈希查找——成功和不成功时的平均查找长度 以下求解过程是按照“计算机统考的计算方法”,不同的老师、教材在“处理冲突”上可能会有不同的方法,所以最主要的是掌握原理即可,对于考研的朋友最好掌握统考...
  • 关于HashMap基本的大家都知道,但是为什么数组的长度必须是2的指数次幂,为什么HashMap的加载因子要设置为0.75,为什么链表长度大于等于8时转成了红黑树? HashMap添加元素分析 当添加元素时,会通过哈希值和数组...
  • mysql创建时字段长度相关注意事项

    千次阅读 2019-04-12 10:53:25
    转载文章出处:...MySQL 建表字段长度的限制 在MySQL建表时,遇到一个奇怪的现象: root@localhost : test 10:30:54>CREATE TABLE tb_test ( -> recordid varchar(32) NOT NULL, -> areaShow va...
  • 织梦(dedecms)的TAGS默认字数较少,只能写12个字符,多出的字符就会自动截断,或者直接去除,经常给我们带来一些麻烦,下面介绍如何修改织梦(dedecms)TAGS的字数限制。 默认情况下,在织梦5.7中,tag的长度是12字节...
  • mysql修改字段长度命令_值得收藏:一份非常完整的 MySQL 规范 一、数据库命令规范 二、数据库基本设计规范 三、数据库字段设计规范 四、索引设计规范 五、常见索引列建议 六、如何选择索引列的顺序 七、...
  • 可变大小数据是其大小在编译时未知或其大小在运行时可能发生变化的数据。Use the Ports and Data Manager to enable or disable variable-size data support in aMATLAB Function block.使用 Ports and Data Manager...
  • 初始化页大小的选择不仅影响表空间数据文件的大小选择,也会对表中每个字段及每条记录产生限制,页大小对字符数据类型实际最大长度及每行记录、表空间数据文件大小的影响如下表所示(此表数据仅供参考,因部署环境、...
  • URL长度

    千次阅读 2010-04-28 21:28:00
    对于超过限定长度的URL所指向的页面,搜索引擎就可能放弃收录。决定URL长度的主要因素包括域名长度、路径长度及文件名长度。4.5.1 域名长度域名长度是指“子域名+域名名称+域名类型”所占用的字符数。例如对于...
  • 原因在于当我们对表的结构进行修改的时候,对数据的存储产生了很大影响。 二、建立测试环境 Use test go if object_id ( 'tb' ) is not null   drop table tb go create table ...
  • 1. 配置每行数据显示最大长度为 200 . 个人不太喜欢 Eclipse 默认长度,弄得代码很容易折行反而不利于查看代码. 配置方法: Windows ->preferences->Java->Code Style->Formatter->Edit->Line Wrapping Maximum l
  • mysql 分区 查看分区 修改表分区

    万次阅读 2015-11-30 11:00:50
    如果从分区中删除了大量的行,或者对一个带有可变长度的行(也就是说,有VARCHAR,BLOB,或TEXT类型的列)作了许多修改,可以使用“ALTER TABLE ... OPTIMIZE PARTITION”来收回没有使用的空间,并整理分区数据文件...
  • 破解AES秘钥长度限制

    万次阅读 2018-01-02 18:33:32
    破解AES秘钥长度限制 高级加密标准 AES:在密码学中又称Rijndael加密法,是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES。 密码说明 因为Rijndael加密法可以支持更大范围的区块和...
  • mysql InnoDB引擎索引超过长度限制

    千次阅读 2018-06-27 10:51:30
    组合索引长度之和大于 767 bytes并无影响,当有某个字段定义长度大于 767 bytes(1000*3)时,仅产生告警,但不影响创建,超长字段会取前 255 字符作为前缀索引,并且组合索引中字段出现的顺序并无关系。为什么3072...
  • 添加学籍信息字段长度报错

    热门讨论 2019-05-02 20:19:10
    出现这个错误的原因是自己输入的字段内容长度和数据库要求的字段内容长度不一致导致的,需要查看数据库字段进行修改 有的时候不能对数据进行操作,操作之后无法保存 解决方法: Sql server工具-选项-设计器-取消...
  • ArrayList初始化长度

    万次阅读 2018-07-24 11:10:19
    自动增长会带来数据向新数组的重新拷贝,因此,如果可预知数据量的多少,可在构造ArrayList时指定其容量。在添加大量元素前,应用程序也可以使用ensureCapacity操作来增加ArrayList实例的容量,这可以减少递增式再...
  • 超过了最大请求长度

    2019-09-28 18:56:29
    页面超过了最大请求长度问题 ... 在页面回传时,产生超过了最大请求长度的 问题 分析:这可能是由于viewstate或Session包含数据量过大,引起回传request包含数据量过大。 解决方案:可以在webconfig...
  • mysql中varchar字段长度超过限制长度自动截取的问题 2007年08月29日 10:30:00wiflish_xie阅读数 399 mysql手册的说明: 如果分配给CHAR或VARCHAR列的值超过列的最大长度,则对值进行裁剪以使其适合。如果被裁掉的...
  •  对于绝大部分正常的情况,都是将的字段类型的长度扩大,但是有的时候是需要缩小的字段长度的,甚至有的时候是要修改表的数据类型的。SQL&gt; CREATE TABLE T AS SELECT ROWNUM ID, A.* FROM DBA...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 448,115
精华内容 179,246
关键字:

修改表长度可能产生的影响