polardb mysql 针对大表做ddl 有没有什么 best practice？

在PolarDB MySQL版中，针对大表执行DDL操作时，有一些最佳实践（Best Practice）可以帮助您优化性能并减少对业务的影响。以下是详细的建议和操作方法：

1. 启用并行DDL功能

PolarDB MySQL版支持并行DDL功能，可以显著提升大表上创建索引或重建表的效率。

• 适用场景：

  • 创建主键索引或二级索引（不包括全文索引、空间索引和虚拟列上的二级索引）。
  • 针对大表（如5 TB、60亿行）的DDL操作。

• 前提条件：

  • PolarDB集群版本需满足以下条件之一：
  • 8.0.2版本：修订版本为8.0.2.1.7及以上。
  • 8.0.1版本：修订版本为8.0.1.1.10及以上。
  • 5.7版本：修订版本为5.7.1.0.7及以上。

• 配置参数：

  • innodb_polar_parallel_ddl_threads：设置并行线程数。
  • innodb_parallel_build_primary_index：用于并行构建主键索引。
  • 注意：开启并行DDL会增加CPU、内存和IO资源的占用，建议在业务低峰期或硬件资源充足时使用。

2. 选择合适的DDL算法

PolarDB MySQL版支持多种DDL执行算法，您可以根据需求选择最优方案。

• INSTANT算法：

  • 特点：仅修改元数据，无需复制或重建表。
  • 适用场景：秒级完成的操作，如添加字段、修改字符集等。
  • 限制：不适用于涉及列存索引变更的DDL操作。

• INPLACE算法：

  • 特点：在引擎内部完成数据复制和重建，允许并发读写访问。
  • 适用场景：需要修改表结构但不希望阻塞业务的场景。
  • 示例：RENAME TABLE、ADD COMMENT等操作。

• COPY算法：

  • 特点：将所有数据复制到新表，期间持有SNW锁（共享无写锁）。
  • 适用场景：不支持并发写入的DDL操作。
  • 注意：对业务影响较大，尽量避免使用。

• 自动选择：PolarDB会按照INSTANT > INPLACE > COPY的优先级自动选择最佳算法。如果需要手动指定，可以通过ALTER TABLE语句的ALGORITHM子句进行控制。

3. 优化DDL锁行为

通过调整锁策略，可以减少DDL操作对业务的影响。

• LOCK子句：

  • DEFAULT：允许最大程度的并发读取和写入。
  • NONE：允许并发读写，如果不支持则返回错误。
  • SHARED：允许并发读取但阻止写入。
  • EXCLUSIVE：禁止一切并发读写操作。

• 建议：

  • 在业务高峰期，使用LOCK=NONE或LOCK=SHARED以减少对业务的影响。
  • 在业务低谷期，可以使用LOCK=EXCLUSIVE以加速DDL操作。

4. 针对列存索引的DDL优化

如果表中包含列存索引，DDL操作可能需要额外的处理。

• 异步DDL：

  • 在RW节点上完成元数据修改后，列存索引的构建会在只读列存节点上异步进行。
  • 注意：在列存索引构建完成前，OLAP查询仍会通过行存方式执行。

• INSTANT DDL与列存索引：

  • 在支持INSTANT DDL的版本中（如8.0.1.1.42及以上），默认使用INSTANT DDL加列。
  • 如果需要兼容旧版重建模式，需将参数imci_enable_add_column_instant_ddl设置为OFF。

• 查看索引状态：

  • 使用INFORMATION_SCHEMA.IMCI_INDEXES查询列存索引的创建状态。

5. 其他优化建议

• 业务低峰期执行DDL：

  • 即使使用了并行DDL或无锁变更，DDL操作仍可能导致IOPS和CPU的上升，建议在业务低峰期执行。

• 监控资源使用：

  • 开启并行DDL后，需密切监控CPU、内存和IO资源的使用情况，避免对其他SQL操作造成影响。

• 避免频繁DDL：

  • 频繁的DDL操作可能导致系统不稳定，建议提前规划表结构变更，减少不必要的操作。

6. 性能测试与验证

• 使用工具（如Sysbench）对DDL操作进行性能测试，确保优化后的操作能够满足业务需求。
• 测试结果表明，PolarDB MySQL版在高并发场景下，单个大表的性能与小表相当，能够有效支持一般业务流量。

通过以上最佳实践，您可以显著提升PolarDB MySQL版在大表上的DDL操作性能，同时减少对业务的影响。