• 关于 mysql 大字段 的搜索结果

回答

单字段过大频繁更新会增加binlog 日志量,加重服务器负担;1,可以把大字段拆分出单独的表,平时如果频繁更新的不是大字段本身,这种做法可有效降低服务器负载及Binlog 增长速度;2,大字段如果频繁更新,可以考虑使用Mongodb 文档存储等其他存储;mysql 不太适合这种场景;

religioser 2019-12-02 02:00:41 0 浏览量 回答数 0

问题

mysql笔试遇到的问题

落地花开啦 2019-12-01 19:54:57 656 浏览量 回答数 1

回答

请在my.cnf下配置 [mysqld]max_allowed_packet=100M 重启mysql 回复 @码上中国博客:将my.default.init复制重命名为my.init,再修改,最后重启下mysql回复 @码上中国博客:这个要自己创建的5.7的MySQL没有这个init文件,只有my.default.init我修改了这个init文件后重启,不管用,再次查看那个值得大小还是不变,按照网上的命令执行后重启了还是不行另外数据库最好不要存储blob、txt之类的大字段,查询分页不是只有blob大对象会有这种问题吗,怎么text也有这种问题了,我用了一个longtext还pgsql吧。一劳永逸用pg管理爬取到的大量网页、图片、pdf毫无压力回复 @554330833a:不是mysql不可以,感觉应该是它不是为这类场景设计的,默认设置比较保守吧。为什么pg可以mysql不可以呢 引用来自“mark35”的评论还pgsql吧。一劳永逸有时是程序设计问题(不适合的场景),后时候是配置问题,虽然基本都能解决,但mysql这些需要耗费时间精力成本的小问题太多。不如要么上商业db要么上免费的pgsql,彻底没这些细节魔鬼 楼主是通过setglobal语句改的max_allowed_packet?然后又用了连接池吧。 另外对于mysql的配置文件,使用命令mysql--help看他的配置文件加载顺序,选其中一个(没有就创建)即可。

爱吃鱼的程序员 2020-06-09 15:46:22 0 浏览量 回答数 0

中小企业与商标那些事

企业品牌保护从商标开始,如何挑选一家靠谱的渠道注册商标,解读品牌权益维护的重要节点。

问题

Myeclipse中如何设置一个字段为大字段?能存很长的文本信息呢??报错

爱吃鱼的程序员 2020-06-22 19:21:37 0 浏览量 回答数 1

回答

1、历史原因 varchar在MySQL 5.0.3之前只支持0-255byte,在MySQL 5.0.3之后才支持到0-65535byte 这里的255是字符的长度 2、varchar的最大长度 看一段代码 mysql> show variables like '%col%'; +---------------------------+-----------------+ | Variable_name | Value | +---------------------------+-----------------+ | collation_connection | utf8_general_ci | | collation_database | utf8_general_ci | | collation_server | utf8_general_ci | | protocol_version | 10 | | slave_compressed_protocol | OFF | +---------------------------+-----------------+ 5 rows in set (0.00 sec) mysql> show char set; +----------+-----------------------------+---------------------+--------+ | Charset | Description | Default collation | Maxlen | +----------+-----------------------------+---------------------+--------+ | big5 | Big5 Traditional Chinese | big5_chinese_ci | 2 | | dec8 | DEC West European | dec8_swedish_ci | 1 | | cp850 | DOS West European | cp850_general_ci | 1 | | hp8 | HP West European | hp8_english_ci | 1 | | koi8r | KOI8-R Relcom Russian | koi8r_general_ci | 1 | | latin1 | cp1252 West European | latin1_swedish_ci | 1 | | latin2 | ISO 8859-2 Central European | latin2_general_ci | 1 | | swe7 | 7bit Swedish | swe7_swedish_ci | 1 | | ascii | US ASCII | ascii_general_ci | 1 | | ujis | EUC-JP Japanese | ujis_japanese_ci | 3 | | sjis | Shift-JIS Japanese | sjis_japanese_ci | 2 | | hebrew | ISO 8859-8 Hebrew | hebrew_general_ci | 1 | | tis620 | TIS620 Thai | tis620_thai_ci | 1 | | euckr | EUC-KR Korean | euckr_korean_ci | 2 | | koi8u | KOI8-U Ukrainian | koi8u_general_ci | 1 | | gb2312 | GB2312 Simplified Chinese | gb2312_chinese_ci | 2 | | greek | ISO 8859-7 Greek | greek_general_ci | 1 | | cp1250 | Windows Central European | cp1250_general_ci | 1 | | gbk | GBK Simplified Chinese | gbk_chinese_ci | 2 | | latin5 | ISO 8859-9 Turkish | latin5_turkish_ci | 1 | | armscii8 | ARMSCII-8 Armenian | armscii8_general_ci | 1 | | utf8 | UTF-8 Unicode | utf8_general_ci | 3 | | ucs2 | UCS-2 Unicode | ucs2_general_ci | 2 | | cp866 | DOS Russian | cp866_general_ci | 1 | | keybcs2 | DOS Kamenicky Czech-Slovak | keybcs2_general_ci | 1 | | macce | Mac Central European | macce_general_ci | 1 | | macroman | Mac West European | macroman_general_ci | 1 | | cp852 | DOS Central European | cp852_general_ci | 1 | | latin7 | ISO 8859-13 Baltic | latin7_general_ci | 1 | | utf8mb4 | UTF-8 Unicode | utf8mb4_general_ci | 4 | | cp1251 | Windows Cyrillic | cp1251_general_ci | 1 | | utf16 | UTF-16 Unicode | utf16_general_ci | 4 | | utf16le | UTF-16LE Unicode | utf16le_general_ci | 4 | | cp1256 | Windows Arabic | cp1256_general_ci | 1 | | cp1257 | Windows Baltic | cp1257_general_ci | 1 | | utf32 | UTF-32 Unicode | utf32_general_ci | 4 | | binary | Binary pseudo charset | binary | 1 | | geostd8 | GEOSTD8 Georgian | geostd8_general_ci | 1 | | cp932 | SJIS for Windows Japanese | cp932_japanese_ci | 2 | | eucjpms | UJIS for Windows Japanese | eucjpms_japanese_ci | 3 | +----------+-----------------------------+---------------------+--------+ 40 rows in set (0.00 sec) mysql> create database testdbx DEFAULT CHARACTER SET latin1; mysql> use testdb; Database changed mysql> use testdbx; Database changed mysql> drop table if exists testa;create table testa (name varchar(65532)); mysql> drop table if exists testa;create table testa (name varchar(65533)); Query OK, 0 rows affected (0.01 sec) ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs mysql> drop table if exists testa;create table testa (name varchar(65533) not null); 总结如下 name varchar(100) not null will be 1 byte (length) + up to 100 chars (latin1) name varchar(500) not null will be 2 bytes (length) + up to 500 chars (latin1) name varchar(65533) not null will be 2 bytes (length) + up to 65533 chars (latin1) name varchar(65532) will be 2 bytes (length) + up to 65532 chars (latin1) + 1 null byte mysql的vachar字段的类型虽然最大长度是65535,但是并不是能存这么多数据,最大可以到65533(不允许非空字段的时候),当允许非空字段的时候只能到65532 3、varchar物理存储 在物理存储上,varchar使用1到2个额外的字节表示实际存储的字符串长度(bytes)。如果列的最大长度小于256个字节,用一个字节表示(标识)。如果最大长度大于等于256,使用两个字节。 当选择的字符集为latin1,一个字符占用一个byte varchar(255)存储一个字符,使用2bytes物理空间存储数据实际数据长度和数据值。 varchar(256)存储一个字符,使用2bytes表示实际数据长度,一共需要3bytes物理存储空间。 varchar对于不同的RDBMS引擎,有不通的物理存储方式,虽然有统一的逻辑意义。对于mysql的不同存储引擎,其实现方法与数据的物理存放方式也不同。 4、InnoDB中的varchar InnoDB中varchar的物理存储方式与InnoDB使用的innodb_file_format有关。 早期的innodb_file_forma = Antelope;支持redundant和compact两种row_format5.5开始或者InnoDB1.1,可以使用一种新的file format = Barracuda;Barracuda兼容Redundant,另外还支持dynamic和compressed两种row_format当innodb_file_format=Antelope,ROW_FORMAT=REDUNDANT 或者COMPACT。innodb的聚集索引(cluster index)仅仅存储varchar、text、blob字段的前768个字节,多余的字节存储在一个独立的overflow page中,这个列也被称作off-page。768个字节前缀后面紧跟着20字节指针,指向overflow pages的位置。 另外,在innodb_file_format=Antelope情况下,InnoDB中最多能存储10个大字段(需要使用off-page存储)。innodbd的默认page size为16KB,InnoDB单行的长度不能超过16k/2=8k个字节,(768+20)*10 < 8k。 当innodb_file_format=Barracuda, ROW_FORMAT=DYNAMIC 或者 COMPRESSED innodb中所有的varchar、text、blob字段数据是否完全off-page存储,根据该字段的长度和整行的总长度而定。对off-page存储的列,cluster index中仅仅存储20字节的指针,指向实际的overflow page存储位置。如果单行的长度太大而不能完全适配cluster index page,innodb将会选择最长的列作为off-page存储,直到行的长度能够适配cluster index page。 5、MyISAM中的varchar 对于MyISAM引擎,varchar字段所有数据存储在数据行内(in-line)。MyISAM表的row_format也影响到varchar的物理存储行为。 MyISAM的row_format可以通过create或者alter sql语句设为fixed和dynamic。另外可以通过myisampack生成row_format=compresse的存储格式。 当MyISAM表中不存在text或者blob类型的字段,那么可以把row_format设置为fixed(也可以为dynamic),否则只能为dynamic。 当表中存在varchar字段的时候,row_format可以设定为fixed或者dynamic。使用row_format=fixed存储varchar字段数据,浪费存储空间,varchar此时会定长存储。row_format为fixed和dynamic,varchar的物理实现方式也不同(可以查看源代码文件field.h和field.cc),因而myisam的row_format在fixed和dynamic之间发生转换的时候,varchar字段的物理存储方式也将会发生变化。 总结 : 1、存储2^8 = 256 / overflow pages / 历史原因 3、varchar不一定比char慢 3、如果有大字段使用text,请拆表 4、varchar建立索引的时候,前面20个字符以内即可 5、其实该怎么用还要怎么用 varchar(30) 、 vachar(300)等 参考资料:http://dev.mysql.com/doc/refman/5.5/en/column-count-limit.html 1、历史原因varchar在MySQL 5.0.3之前只支持0-255byte,在MySQL 5.0.3之后才支持到0-65535byte这里的255是字符的长度 2、varchar的最大长度看一段代码 mysql> show variables like '%col%'; +---------------------------+-----------------+ | Variable_name | Value | +---------------------------+-----------------+ | collation_connection | utf8_general_ci | | collation_database | utf8_general_ci | | collation_server | utf8_general_ci | | protocol_version | 10 | | slave_compressed_protocol | OFF | +---------------------------+-----------------+ 5 rows in set (0.00 sec) mysql> show char set; +----------+-----------------------------+---------------------+--------+ | Charset | Description | Default collation | Maxlen | +----------+-----------------------------+---------------------+--------+ | big5 | Big5 Traditional Chinese | big5_chinese_ci | 2 | | dec8 | DEC West European | dec8_swedish_ci | 1 | | cp850 | DOS West European | cp850_general_ci | 1 | | hp8 | HP West European | hp8_english_ci | 1 | | koi8r | KOI8-R Relcom Russian | koi8r_general_ci | 1 | | latin1 | cp1252 West European | latin1_swedish_ci | 1 | | latin2 | ISO 8859-2 Central European | latin2_general_ci | 1 | | swe7 | 7bit Swedish | swe7_swedish_ci | 1 | | ascii | US ASCII | ascii_general_ci | 1 | | ujis | EUC-JP Japanese | ujis_japanese_ci | 3 | | sjis | Shift-JIS Japanese | sjis_japanese_ci | 2 | | hebrew | ISO 8859-8 Hebrew | hebrew_general_ci | 1 | | tis620 | TIS620 Thai | tis620_thai_ci | 1 | | euckr | EUC-KR Korean | euckr_korean_ci | 2 | | koi8u | KOI8-U Ukrainian | koi8u_general_ci | 1 | | gb2312 | GB2312 Simplified Chinese | gb2312_chinese_ci | 2 | | greek | ISO 8859-7 Greek | greek_general_ci | 1 | | cp1250 | Windows Central European | cp1250_general_ci | 1 | | gbk | GBK Simplified Chinese | gbk_chinese_ci | 2 | | latin5 | ISO 8859-9 Turkish | latin5_turkish_ci | 1 | | armscii8 | ARMSCII-8 Armenian | armscii8_general_ci | 1 | | utf8 | UTF-8 Unicode | utf8_general_ci | 3 | | ucs2 | UCS-2 Unicode | ucs2_general_ci | 2 | | cp866 | DOS Russian | cp866_general_ci | 1 | | keybcs2 | DOS Kamenicky Czech-Slovak | keybcs2_general_ci | 1 | | macce | Mac Central European | macce_general_ci | 1 | | macroman | Mac West European | macroman_general_ci | 1 | | cp852 | DOS Central European | cp852_general_ci | 1 | | latin7 | ISO 8859-13 Baltic | latin7_general_ci | 1 | | utf8mb4 | UTF-8 Unicode | utf8mb4_general_ci | 4 | | cp1251 | Windows Cyrillic | cp1251_general_ci | 1 | | utf16 | UTF-16 Unicode | utf16_general_ci | 4 | | utf16le | UTF-16LE Unicode | utf16le_general_ci | 4 | | cp1256 | Windows Arabic | cp1256_general_ci | 1 | | cp1257 | Windows Baltic | cp1257_general_ci | 1 | | utf32 | UTF-32 Unicode | utf32_general_ci | 4 | | binary | Binary pseudo charset | binary | 1 | | geostd8 | GEOSTD8 Georgian | geostd8_general_ci | 1 | | cp932 | SJIS for Windows Japanese | cp932_japanese_ci | 2 | | eucjpms | UJIS for Windows Japanese | eucjpms_japanese_ci | 3 | +----------+-----------------------------+---------------------+--------+ 40 rows in set (0.00 sec) mysql> create database testdbx DEFAULT CHARACTER SET latin1; mysql> use testdb; Database changed mysql> use testdbx; Database changed mysql> drop table if exists testa;create table testa (name varchar(65532)); mysql> drop table if exists testa;create table testa (name varchar(65533)); Query OK, 0 rows affected (0.01 sec) ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs mysql> drop table if exists testa;create table testa (name varchar(65533) not null); 总结如下 name varchar(100) not null will be 1 byte (length) + up to 100 chars (latin1) name varchar(500) not null will be 2 bytes (length) + up to 500 chars (latin1) name varchar(65533) not null will be 2 bytes (length) + up to 65533 chars (latin1) name varchar(65532) will be 2 bytes (length) + up to 65532 chars (latin1) + 1 null byte mysql的vachar字段的类型虽然最大长度是65535,但是并不是能存这么多数据,最大可以到65533(不允许非空字段的时候),当允许非空字段的时候只能到65532 3、varchar物理存储 在物理存储上,varchar使用1到2个额外的字节表示实际存储的字符串长度(bytes)。如果列的最大长度小于256个字节,用一个字节表示(标识)。如果最大长度大于等于256,使用两个字节。 当选择的字符集为latin1,一个字符占用一个byte varchar(255)存储一个字符,使用2bytes物理空间存储数据实际数据长度和数据值。 varchar(256)存储一个字符,使用2bytes表示实际数据长度,一共需要3bytes物理存储空间。 varchar对于不同的RDBMS引擎,有不通的物理存储方式,虽然有统一的逻辑意义。对于mysql的不同存储引擎,其实现方法与数据的物理存放方式也不同。 4、InnoDB中的varchar InnoDB中varchar的物理存储方式与InnoDB使用的innodb_file_format有关。 早期的innodb_file_forma = Antelope;支持redundant和compact两种row_format5.5开始或者InnoDB1.1,可以使用一种新的file format = Barracuda;Barracuda兼容Redundant,另外还支持dynamic和compressed两种row_format当innodb_file_format=Antelope,ROW_FORMAT=REDUNDANT 或者COMPACT。innodb的聚集索引(cluster index)仅仅存储varchar、text、blob字段的前768个字节,多余的字节存储在一个独立的overflow page中,这个列也被称作off-page。768个字节前缀后面紧跟着20字节指针,指向overflow pages的位置。 另外,在innodb_file_format=Antelope情况下,InnoDB中最多能存储10个大字段(需要使用off-page存储)。innodbd的默认page size为16KB,InnoDB单行的长度不能超过16k/2=8k个字节,(768+20)*10 < 8k。 当innodb_file_format=Barracuda, ROW_FORMAT=DYNAMIC 或者 COMPRESSED innodb中所有的varchar、text、blob字段数据是否完全off-page存储,根据该字段的长度和整行的总长度而定。对off-page存储的列,cluster index中仅仅存储20字节的指针,指向实际的overflow page存储位置。如果单行的长度太大而不能完全适配cluster index page,innodb将会选择最长的列作为off-page存储,直到行的长度能够适配cluster index page。 5、MyISAM中的varchar 对于MyISAM引擎,varchar字段所有数据存储在数据行内(in-line)。MyISAM表的row_format也影响到varchar的物理存储行为。 MyISAM的row_format可以通过create或者alter sql语句设为fixed和dynamic。另外可以通过myisampack生成row_format=compresse的存储格式。 当MyISAM表中不存在text或者blob类型的字段,那么可以把row_format设置为fixed(也可以为dynamic),否则只能为dynamic。 当表中存在varchar字段的时候,row_format可以设定为fixed或者dynamic。使用row_format=fixed存储varchar字段数据,浪费存储空间,varchar此时会定长存储。row_format为fixed和dynamic,varchar的物理实现方式也不同(可以查看源代码文件field.h和field.cc),因而myisam的row_format在fixed和dynamic之间发生转换的时候,varchar字段的物理存储方式也将会发生变化。 总结 : 1、存储2^8 = 256 / overflow pages / 历史原因 3、varchar不一定比char慢 3、如果有大字段使用text,请拆表 4、varchar建立索引的时候,前面20个字符以内即可 5、其实该怎么用还要怎么用 varchar(30) 、 vachar(300)等 参考资料:http://dev.mysql.com/doc/refman/5.5/en/column-count-limit.html

西秦说云 2019-12-02 01:33:17 0 浏览量 回答数 0

回答

回 2楼(小猪猪) 的帖子 RDS可用区正在开发中,12月初就会大家见面,请密切关注我们的官网变动。 ------------------------- 回 3楼(小哈哈乖乖) 的帖子 您问的是多实例之间dblink功能吧,dblink功能目前RDS由于权限控制问题还无法支持到,我们会记录下需求,后面作为我们改进的方向。 ------------------------- 回 8楼(胜哥) 的帖子 从RDS的角度来说,RDS性能和RDS的内存,cpu,IOPS都有关系,如果网站的访问量很大,负载高,数据库的压力大,那么首先看下是不是sql写的不够好,控制台会有优化的建议可以参考下(索引,主键等),如果有问题可以做相应的优化,如果确实是内存规格不够用,cpu达到瓶颈,可以考虑升级内存规格来解决(内存越大对应的cpu处理能力也越大)。 关于内网速度也说一下,相同地域的ECS内网连RDS速度不会是瓶颈,绝大部分用户也都是这种连法。 ------------------------- 回 9楼(nizuzong) 的帖子 呵呵,您的不是RDS的问题吧,ECS问题可以到ECS论坛提问 ------------------------- 回 13楼(lxd5866) 的帖子 云数据库,自己看吧,官网有介绍。 ------------------------- 回 16楼(mahaidong) 的帖子 1.UDF权限目前没有支持计划,开放UDF对权限要求很高,涉及主机级别,安全风险很大。 2.建议可以用mysql的压缩特性compress对大字段进行压缩。建议也可以参考下此链接: http://hidba.org/?p=551 ------------------------- 回 17楼(wei2014) 的帖子 抱歉,控制台的优化我们在继续,我们记录下您的建议,新版控制台正在设计,年前会和大家见面。 ------------------------- 回 22楼(binfeng) 的帖子 抱歉,此功能确实困扰了一部分用户,当前我们实现了做切换内外网的时候可以保持域名不变,切换后就不需要再修改连接地址,内外网同时实现的问题我们已经在预研阶段,我们会尽快推进,努力早点实现。 ------------------------- 回 25楼(dfar2008) 的帖子 抱歉给你带来了困扰,数据库和账号个数的放开是我们近期的计划,预计15年Q1前就可以放开。 ------------------------- 回 26楼(耳朵哥) 的帖子 暂时还无好的办法。 ------------------------- 回 34楼(水中剑) 的帖子 1. 不会锁表。 2. 只读实例本身就是一个实例配置,只不过只提供读的权限,由于只读实例的生存周期可控,随时创建随时释放,所以只能采用按量付费的方式,即目前的按小时计费。 ------------------------- 回 37楼(chinaoc) 的帖子 您的需求我们记录下来,后面会进行评估的。 ------------------------- 回 43楼(会友运动网) 的帖子 RDS的数据是写多重备份的,可靠性是经过一定的算法得出,具体的参数不便透露。 ------------------------- 回 45楼(橘子) 的帖子 抱歉此问题给你带来的困扰,目前我们正在做调整,将实例规格的连接数放开,快的话12月份就会全线大幅上调连接数,让每个规格不再有连接数不够的问题,同时价格不会变化。 ------------------------- 回 53楼(浅小思) 的帖子 楼主关注我上面的回复,快的话12月份我们就可以全面大幅上调连接数的,价格会维持不变。 ------------------------- 回 50楼(hi50029130) 的帖子 RDS创建后由于有一些数据库必须的文件,如数据库元文件,ibdata等,这部分数据会占用500MB,另外上传过数据后也会产生部分日志文件会占用部分空间,是正常的情况。 ------------------------- 回 54楼(stanwei) 的帖子 这个需要在应用程序端做配置,读和写请求分发的不同的实例(我们只读实例也会提供一个连接地址)。 ------------------------- 回 55楼(mangowang) 的帖子 RDS底层默认就是主从的架构,不需要你再额外搭建从库,平时只有主实例在工作,备实例做高可用,主实例故障后就会切换到备库,我们的RDS(MySQL)和官方的是兼容的,您的数据库完全可以迁移上来,不会有兼容性问题。 ------------------------- 回 62楼(sttt) 的帖子 RDS默认就是HA 主备架构。 ------------------------- 回 58楼(因为爱) 的帖子 看到您的吐槽,我们深感压力,我们知道这个内外网不能同时存在的问题确实困扰了你,由于是内部和外部都要连RDS的情况,目前还没办法很好的解决,由于内外网共存会涉及底层架构的调整,此事我们也正在稳步推进中,后续我们推出安全链路模式的RDS,基于安全链路我们推出内外网同时存在,预计15年1月份左右。 ------------------------- 回 89楼(苦茶独酌) 的帖子 有支持的计划,计划15年上半年完成对PG的支持。 ------------------------- 回 67楼(ivytest) 的帖子 RDS不是在虚机上装的类似镜像的东西,RDS有一套自己的集群,系统,主备架构保证高可用,内存和磁盘空间在使用过程中都是可以随时升级的,IOPS每个规格对应的数据都不一样,当然对应的数值都是可以满足的,不存在缺斤少两。 ------------------------- 回 71楼(tewang) 的帖子 权限细化我们正在努力做,15年Q1会有新变化。 ------------------------- 回 61楼(meexun) 的帖子 楼主,1000万PV和用那个RDS没有必然关系,要看应用访问数据库的情况决定,光这些数据无法判断用何种配置RDS。 ------------------------- 回 100楼(小优信息) 的帖子 楼主,我们现在已经支持免费体验了,需要体验下吗,控制端的功能正在全力开发中呢。

rds-pd 2019-12-02 00:53:09 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 SQL审核 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 人工智能 阿里云云栖号 云栖号案例 云栖号直播