GaussDB (for MySQL)超大表删除索引有哪些风险 删除索引是一个风险很大的操作，建议非必要不删除索引，主要原因如下： 删除索引会导致使用该索引的查询操作性能下降，慢SQL占满系统资源，影响业务正常运行。 删除索引的过程中会导致表锁定，其他用户无法访问该表，影响系统可用性。

查看更多 →

表和索引 搜索表 创建索引 索引使用约束 父主题： 全文检索

查看更多 →

index：表示使用索引，如果只有 Using index，说明没有查询到数据表，只用索引表即完成了这个查询，这种情况为覆盖索引。如果同时出现Using where，代表使用索引来查找读取记录， 也是可以用到索引的，但是需要查询到数据表。 Using where：表示条件查询，如

查看更多 →

GaussDB(for MySQL) CPU使用率高的解决方法 联合索引设置不当导致慢SQL的解决办法 长事务产生大量临时表导致内存超限的解决办法 持锁长事务导致后续业务报等锁超时的解决办法 GaussDB(for MySQL)的临时盘使用说明 GaussDB(for MySQL)实例在空负载下CPU占用说明

查看更多 →

0新增的Instant秒级加列的算法的原理，使用限制，适用场景等。 MySQL原生的Copy算法由于在拷贝数据的过程中对源表加MDL写锁，导致DML语句被长时间阻塞，已经不推荐使用。 Inplace算法相比Copy算法有很大的改进，采用在原表上进行更改的方法，不需要生成临时表，占用的额外空间

查看更多 →

目标库如果有死锁，可能导致全量数据无法写入。以MySQL为例，可执行以下命令查看、删除死锁。 查看是否锁表：show OPEN TABLES where In_use > 0;。 查看锁表进程：show processlist;。 删除锁表的进程：KILL [CONNECTION |

查看更多 →

--time=6000 run 在目标表sbtest1 上开启一个新事务但不提交，该事务持有目标表sbtest1的MDL锁。 begin; select * from sbtest1; 开启一个新会话，在开启和关闭非阻塞 DDL功能的条件下，分别对表sbtest1进行加列操作，观察TPS的变化情况。

查看更多 →

--time=6000 run 在目标表sbtest1 上开启一个新事务但不提交，该事务持有目标表sbtest1的MDL锁。 begin; select * from sbtest1; 开启一个新会话，在开启和关闭非阻塞 DDL功能的条件下，分别对表sbtest1进行加列操作，观察TPS的变化情况。

查看更多 →

查看CES指标实时复制时延，下图仅供参考： 原因分析 根据MySQL主备复制延迟场景及解决方案和MySQL主备复制原理简介的相关分析，可以推测此场景为大事务或DDL操作导致。 可以通过分析全量日志或慢日志，观察是否有大事务或DDL操作： 慢日志中有如下加索引的DDL操作，表的数据量上亿，耗时近一天，从而导

查看更多 →

索引 唯一索引 普通索引和前缀索引 HASH索引 BTREE索引 SPATIAL空间索引 FULLTEXT全文索引 删除索引 索引重命名 父主题： MySQL语法迁移

查看更多 →

索引 在GaussDB(DWS)中创建索引期间，索引名不能与模式名一起指定。该索引将在创建索引表的模式中自动创建。 图1 输入：索引 图2 输出：索引 输入：基于CASE函数的索引 函数索引是基于列函数或表达式计算结果创建的索引。 输入 1 2 3 4 5 6 7 8 9 CREATE

查看更多 →

Operational_Acc_Obtained_Id ); 由于索引列的列表（organic_name）不是DISTRIBUTE BY列的列表（serial_no、organic_name）的超集，因此索引中删除了UNIQUE。 输入：CREATE TABLE，使用主键和非唯一主索引（未添加DISTRIBUTE BY

查看更多 →

如果是lock_type='RECORD' 行级锁 ,为锁住的页号，如果是表锁为null。 lock_rec String 如果是lock_type='RECORD' 行级锁 ,为锁住的堆号，如果是表锁为null。 lock_data String 事务锁住的主键值，若是表锁，则该值为null。 表7 InnodbLockWaits

查看更多 →

MySQL原生的DDL工具 Copy算法 按照原表定义创建一个新的临时表。 对原表加写锁（禁止DML）。 在1建立的临时表执行DDL。 将原表中的数据copy到临时表。 释放原表的写锁。 将原表删除，并将临时表重命名为原表。 采用copy方式期间需要锁表，禁止DML写操作。当Lock

查看更多 →

避免使用分区表，如有需要，可以使用多个独立的表代替。 分区表的缺点： DDL操作需要锁定所有分区，导致所有分区上操作都被阻塞。 当表数据量较大时，对分区表进行DDL或其他运维操作难度大风险高。 分区表使用较少，存在未知风险。 当单台 服务器 性能无法满足时，对分区表进行分拆的成本较高。

查看更多 →

新增列将会放到最后，不支持改变列的顺序（MySQL 8.0.29后支持任意位置加列）。 不支持在行格式为COMPRESSED的表上快速加列或删除。 不支持在已经有全文索引的表上快速加列或删除。 不支持在临时表上快速加列或删除。 重命名列的限制： 不支持重命名被其他表引用的列。 不支持重命名列的

查看更多 →

的转换产生乱码。 所有的表和字段都需要添加注释。使用comment从句添加表和列的备注，从设计初期维护好数据字典。 表单行长度不得超过1024字节。 谨慎使用RDS for MySQL分区表，避免跨分区查询，否则查询效率会降低。分区表在逻辑上表现为一个表，但是在物理层面上将数据存储在多个文件。

查看更多 →

对于DDL的等锁超时，其真实超时时间是lock_wait_timeout和rds_ddl_lock_wait_timeout的最小值。 对于DDL过程中InnoDB层的加表锁超时（行锁不在该考虑范围），其真实超时时间是innodb_lock_wait_timeout和rds_ddl_lock_wait_timeout）的最小值。

查看更多 →

对于DDL的等锁超时，其真实超时时间是lock_wait_timeout和rds_ddl_lock_wait_timeout的最小值。 对于DDL过程中InnoDB层的加表锁超时（行锁不在该考虑范围），其真实超时时间是innodb_lock_wait_timeout和rds_ddl_lock_wait_timeout）的最小值。

查看更多 →

判断使用分区表还是非分区表 根据表的使用场景一般将表分为事实表和维度表： 事实表通常整表数据规模较大，以新增数据为主，更新数据占比小，且更新数据大多落在近一段时间范围内（年或月或天），下游读取该表进行ETL计算时通常会使用时间范围进行裁剪（例如最近一天、一月、一年），这种表通常可以通

查看更多 →

Hudi表索引设计规范 规则 禁止修改表索引类型。 Hudi表的索引会决定数据存储方式，随意修改索引类型会导致表中已有的存量数据与新增数据之间出现数据重复和数据准确性问题。常见的索引类型如下： 布隆索引：Spark引擎独有索引，采用bloomfiter机制，将布隆索引内容写入到Parquet文件的footer中。

查看更多 →