新增功能和性能优化： 优化datatime/timestamp/time字段行为向前兼容。 优化PQ支持并行磁盘hash join场景。 启用并行INSERT/REPLACE SELECT的功能优化查询速度。 增加连接建立/断开日志打印，提高定位连接相关问题效率。 优化慢日志中增加

查看更多 →

普通索引和前缀索引 GaussDB (DWS)不支持前缀索引，也不支持内联普通索引。DSC工具迁移时会根据GaussDB(DWS)的特性将其迁移为普通索引。 内联普通(前缀)索引。 输入示例 1 2 3 4 5 6 CREATE TABLE IF NOT EXISTS `public`

查看更多 →

用高。 解决方案 复杂查询语句导致磁盘打满，建议客户从业务侧优化响应查询语句，常见优化措施： 加上合适的索引。 在where条件中过滤更多的数据。 重写SQL，优化执行计划。 如果不得不使用临时表，那么一定要减少并发度。 临时规避措施：考虑业务侧优化复杂查询语句需要一定时间，可以通过临时扩容磁盘空间规避。

查看更多 →

，通过审计日志查看SQL执行记录协助定位问题原因。 解决方法一 分析慢SQL日志以及CPU使用率指标来定位效率低的查询，再优化查询效率低的语句。 查看慢SQL日志来确定是否存在运行缓慢的SQL查询以及各个查询的性能特征（如果有），从而定位查询运行缓慢的原因。 查询RDS for MySQL日志，请参见查询慢SQL。

查看更多 →

走全表扫描且单条扫描行数在35万+，其并未走索引。 进一步查看该表的表结构，发现该表仅对字段“is_deleted”添加了一个索引“IDX_XX_USERID”，因此上述查询无索引可选。建议业务侧给字段“idx_user_id”新增索引后，实例在16:37分左右CPU下降到正常水平，业务恢复。

查看更多 →

索引并不是越多越好，索引可以提高查询的效率，但会降低写数据的效率。有时不恰当的索引还会降低查询的效率。 禁止给表中的每一列都建立单独的索引。设计良好的联合索引比每一列上的单独索引效率要高出很多。 建议在下面的列上建立索引： 在SELECT，UPDATE，DELETE语句的WHERE从句上的列。

查看更多 →

索引并不是越多越好，索引可以提高查询的效率，但会降低写数据的效率。有时不恰当的索引还会降低查询的效率。 禁止给表中的每一列都建立单独的索引。设计良好的联合索引比每一列上的单独索引效率要高出很多。 建议在下面的列上建立索引： 在SELECT，UPDATE，DELETE语句的WHERE从句上的列。

查看更多 →

用高。 解决方案 复杂查询语句导致磁盘打满，建议客户从业务侧优化响应查询语句，常见优化措施： 加上合适的索引。 在where条件中过滤更多的数据。 重写SQL，优化执行计划。 如果不得不使用临时表，那么一定要减少并发度。 临时规避措施：考虑业务侧优化复杂查询语句需要一定时间，可以通过临时扩容磁盘空间规避。

查看更多 →

，通过审计日志查看SQL执行记录协助定位问题原因。 解决方法一 分析慢SQL日志以及CPU使用率指标来定位效率低的查询，再优化查询效率低的语句。 查看慢SQL日志来确定是否存在运行缓慢的SQL查询以及各个查询的性能特征（如果有），从而定位查询运行缓慢的原因。 查询RDS for MySQL日志，请参见查询慢SQL。

查看更多 →

allowed”。详见官方文档。 解决方案 MySQL机制导致，建议优化业务，避免单表创建过多索引。 InnoDB表的其他限制： 一个表最多可以包含1017列（包含虚拟生成列）。 InnoDB对于使用DYNAMIC或COMPRESSED行格式的表，索引键前缀长度限制为3072字节。 多列索引最多允许16列，超过限制会报错。

查看更多 →

by的时候，尽量在合理的情况下设置可以包含所有依赖字段的索引，优化示例： 没有合适索引，导致需要用到临时表。 有合适的索引，不会使用临时表，直接走索引。 解决方案 在使用distinct或group by的时候，尽量在合理的情况下，创建可以包含所有依赖字段的索引。 父主题： SQL类

查看更多 →

by的时候，尽量在合理的情况下设置可以包含所有依赖字段的索引，优化示例： 没有合适索引，导致需要用到临时表。 有合适的索引，不会使用临时表，直接走索引。 解决方案 在使用distinct或group by的时候，尽量在合理的情况下，创建可以包含所有依赖字段的索引。 父主题： SQL类

查看更多 →

走全表扫描且单条扫描行数在35万+，其并未走索引。 进一步查看该表的表结构，发现该表仅对字段“is_deleted”添加了一个索引“IDX_XX_USERID”，因此上述查询无索引可选。建议业务侧给字段“idx_user_id”新增索引后，实例在16:37分左右CPU下降到正常水平，业务恢复。

查看更多 →

联合索引设置不当导致慢SQL的解决办法 场景描述 业务侧云数据库GaussDB(for MySQL)实例上以往执行耗时8秒的查询，在11:00后耗时超过30秒。 原因分析 查看查询变慢对应的时间段中，实例CPU监控指标并无飙升情况且使用率一直都较低，因此排除了CPU冲高导致查询变慢的可能。

查看更多 →

GROUP_CONCAT结果不符合预期 创建二级索引报错Too many keys specified distinct与group by优化 为什么有时候用浮点数做等值比较查不到数据 开通数据库代理后，还是有大量select请求分发到主节点 表空间膨胀问题 MySQL创建用户提示 服务器 错误(ERROR

查看更多 →

具体请参见： 通过内网连接GaussDB(for MySQL)实例 通过控制台设置参数innodb_adaptive_hash_index=off ， 关闭自适应hash索引，减少锁等待。 参数修改具体请参见编辑参数模板。 优化慢查询。 父主题： 数据库连接

查看更多 →

行慢是因为未走索引或选错索引。且通过EXPLAIN查看该SQL的执行计划确实是全表扫描。 图2 慢日志 在实例上对该表执行SHOW INDEX FROM检查三个字段的索引区分度（或基数）。 图3 查看索引区分度 可知基数最小的字段“query_date”在联合索引的第一位，基数最

查看更多 →

allowed”。详见官方文档。 解决方案 MySQL机制导致，建议优化业务，避免单表创建过多索引。 InnoDB表的其他限制： 一个表最多可以包含1017列（包含虚拟生成列）。 InnoDB对于使用DYNAMIC或COMPRESSED行格式的表，索引键前缀长度限制为3072字节。 多列索引最多允许16列，超过限制会报错。

查看更多 →

索引管理 索引简介 创建索引 查询索引 删除索引

查看更多 →

放对象的容器。 关系型数据库 RDS.MySQL 关系型数据库（Relational Database Service，以下简称RDS）是一种基于 云计算平台 的即开即用、稳定可靠、弹性伸缩、便捷管理的在线关系型数据库服务。 RDS.MySQL.DataBase 一个数据库实例可以包

查看更多 →

GIN索引 GS_104010009 错误码： posting list is too long. 解决方案：减小Maintenance_work_mem。 level： ERROR GS_104200059 错误码： recovery is in progress. 解决方案：恢复时无法清理GIN挂起列表。

查看更多 →