云服务器内容精选
-
原因分析 查看表结构发现存在JSON格式的大字段 create table `t1` ( `id` bigint not null, `num` int not null, `rank` int not null, `j1` json default null, `j2` json default null, `j3` json default null, primary key (`id`, `num`)) engine = InnoDB default charset = utf8 社区全字段排序特性导致该问题，对于BLOB/TEXT/JSON/GEOMETRY等大字段类型，虽然理论上最大可以达到4GB，但是在实际应用中基本不会达到这个数量级，如果只根据row IDs去做排序而不是完整的行，会导致需要二次回表去取数据，在这种场景下瓶颈就在回表上。因此如果开启了全字段排序，当sort_buffer_size比较小而行数据比较大，就会导致超过阈值报错。
-
场景描述 执行以下查询报Out of sort memory，调大sort_buffer_size仍然报错，排查表数量较小 SELECT * FROM `t1` WHERE num = 4250 ORDER BY rank desc; 执行失败，失败原因：(conn=24259576) Out of sort memory, consider increasing server sort buffer size
-
解决方案 将存储emoji表情的字段的字符集修改为utf8mb4。 如果涉及的表和字段比较多，建议把对应表、数据库的编码也设置为utf8mb4。参考命令： ALTER DATABASE database_name CHARACTER SET= utf8mb4 COLLATE= utf8mb4_unicode_ci; ALTER TABLE table_name CONVERTTOCHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE table_name MODIFY 字段名 VARCHAR(128) CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci; 若对应字段的字符集已经是utf8mb4，则为客户端或MySQL服务端字符集转换问题，将客户端和MySQL服务端的字符集都设置为utf8mb4。
-
场景描述 业务插入或更新带有emoji表情的数据时，报错Error 1366。 java.sql.SQLException: Incorrect string value: '\xF0\x9F\x90\xB0\xE5\xA4...' for column 'username' at row 1 ; uncategorized SQLException for SQL []; SQL state [HY000]; error code [1366]; Incorrect string value: '\xF0\x9F\x90\xB0\xE5\xA4...' for column 'username' at row 1; 执行SQL中包含的emoji的insert/update语句，再去查询插入的记录，emoji表情显示为? SQL中包含emoji表情，在写入过程中会发生截断，表情后面的文本丢失。 客户端字符集为utf8mb4，执行SQL报错无法正常执行。 Conversion from collation utf8mb4_general_ci into utf8_general_ci impossible for parameter
-
解决方案 为已有数据的表添加自增列时，请先创建相同表结构的新表，再在新表上添加自增列，将原表数据导入（导入数据时，请尽量保持原表无写入操作，否则会造成原表与新表数据不一致）。 按照如下步骤解决主备节点查询数据不一致问题。 在主节点上创建一个与无主键表（称之为原无主键表t1）相同的新表t2，并为新表中添加自增主键。 示例如下： CREATE TABLE t2 LIKE t1; ALTER TABLE t2 ADD id INT AUTO_INCREMENT PRIMARY KEY; 将原无主键表的数据全部插入到新表t2中。 示例如下： INSERT INTO t2(col1, col2) SELECT col1, col2 FROM t1 ORDER BY col1, col2; 为了确保主备节点对应表中数据的顺序相同，ORDER BY子句必须包含原无主键表的所有列。 删除原无主键表t1，并将新表重命名为原无主键表名。 示例如下： DROP TABLE t1; RENAME TABLE t2 TO t1;
-
原因分析 查询确认，发现消失的账号在mysql.user表中已经被删除，因此在控制台不再显示。 使用账号名和旧密码还能连接登录，说明使用的是delete from mysql.user方式删除用户。使用这种方式删除用户，需要执行flush privileges后，才会清理内存中相关数据，该用户才彻底不能登录。 使用delete from mysql.user方式删除用户，无法重新创建相应账户（报错ERROR 1396），原因是内存中相关数据仍然存在。 正确删除用户的方式为drop user语句，注意以下几点： drop user语句可用于删除一个或多个用户，并撤销其权限。 使用drop user语句必须拥有MySQL数据库的DELETE权限或全局CREATE USER权限。 在drop user语句的使用中，若没有明确地给出账户的主机名，则该主机名默认为“%”。 故障场景恢复示例： 创建用户后用delete删除用户，再创建同名用户时报错ERROR 1396。通过执行flush privileges后，可正常创建同名用户。
-
原因分析 在“innodb_large_prefix”设置为off的情况下，InnoDB表的单字段索引的最大字段长度不能超过767字节，联合索引的每个字段的长度不能超过767字节，且所有字段长度合计不能超过3072字节。 当“innodb_large_prefix”设置为on时，单字段索引最大长度可为3072字节，联合索引合计最大长度可为3072字节。 索引长度与字符集相关。使用utf8字符集时，一个字符占用三个字节，在“innodb_large_prefix”参数设置为on情况下，索引的所有字段的长度合计最大为1072个字符。 查看表结构如下： CREATE TABLE `xxxxx` (……`subscription_type` varchar(64) NOT NULL DEFAULT 'DEVICE_EXCEPTION' COMMENT '订阅类型',`auth_key` varchar(255) DEFAULT '' COMMENT '签名，接口请求头会根据这个值增加token',`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',PRIMARY KEY (`id`) USING BTREE,UNIQUE KEY `enterprise_id` (`subscription_type`,`enterprise_id`,`callback_url`) USING BTREE)) ENGINE=InnoDB AUTO_INCREMENT=1039 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC 该表使用了utf8字符集，一个字符占用三个字节。联合索引“enterprise_id”包含了“callback_url”字段，如果执行DDL操作将“callback_url”修改为varchar(1024)，会超出联合索引最大长度限制，所以报错。
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
