# TaurusDB大表优化最佳实践
#### 操作场景
在数据库运维中，大表通常指数据量达到千万行、占用空间上百GB甚至TB级别的表。随着业务发展，大表带来的挑战主要体现在三个方面：
- 存储瓶颈：单节点磁盘容量不足，需要频繁扩容或拆分数据，对业务影响较高。
- 性能下降：索引维护成本高，写入性能衰减，查询响应变慢，对业务影响较高。
- 运维困难：DDL操作耗时极长，加字段、加索引可能阻塞业务数小时，对业务影响较高。
传统MySQL社区版在处理大表时，受限于单机架构设计，往往需要通过分库分表来分散压力。然而，这会带来新的问题：应用层需要改造SQL、引入中间件以及维护分片路由规则，导致整体架构复杂度大幅上升。
TaurusDB采用计算存储分离架构，支持单表存储TB级数据，从而有效解决大表场景下的存储和性能瓶颈，同时避免应用层改造带来的复杂度提升。本文将详细介绍如何在不拆分数据的情况下，高效管理和优化大表。
#### 存储能力优化
当业务量超出预期，单表数据量从数百万行迅速膨胀至数十亿行，本地磁盘频繁发出容量告警。此时，我们面临两种解决方案：垂直扩容，即更换更大容量的服务器，但这种方式成本高昂且存在扩容上限；分库分表，即改造业务代码并引入Sharding中间件，然而其开发和运维成本较高。
TaurusDB采用**计算节点 + 分布式存储集群**的架构：
- 计算层：负责SQL解析、执行计划生成、事务处理，可根据负载灵活扩缩容。
- 存储层：基于华为DFV存储，提供强一致和高性能的分布式存储能力，存储集群采取池化部署，可以有效提升存储使用效率，构建以数据为中心的全栈数据服务架构的解决方案
  表1架构对比 
  | **特性** | **传统单机MySQL**  | **TaurusDB** |
  |:---|:---|:---|
  | 最大存储容量 | 受限于单机磁盘（通常数TB） | 128TB，按需扩展   |
  | 扩容方式   | 停机更换硬件或迁移数据    | 在线自动扩容，业务无感知 |
  | 成本模式   | 预购固定容量，容易浪费    | 按实际使用量计费     |
     
  
 
#### 计算能力优化
在InnoDB存储引擎中，Redo日志（重做日志）是保证事务持久性的关键机制。每次数据修改都会产生Redo日志，事务提交前必须确保Redo日志已持久化到磁盘。当大表面临高并发写入时（例如批量插入、高频UPDATE），Redo日志的写入压力会急剧上升。
- 传统方式：单线程顺序写入，日志缓冲区容易成为瓶颈。
- 性能表现：日志写入延迟增加，事务提交变慢，整体吞吐量受限。
通过多线程并行写入Redo日志机制，将日志写入任务分散到多个线程并行处理，充分利用底层分布式存储的高吞吐能力。
表2TaurusDB计算能力优化性能数据 
| **指标**     | **优化前** | **优化后**  |
|:---|:---|:---|
| Redo日志吞吐峰值 | 约1 GB/s | 4 GB/s   |
| 单集群IO吞吐极限  | 约2 GB/s | 5.2 GB/s |
   
#### DDL能力优化
- 并行DDL 传统的DDL操作基于单核和传统硬盘设计，导致针对大表的DDL操作耗时较久，延迟过高。以创建二级索引为例，过高延迟的DDL操作会阻塞后续依赖新索引的DML查询操作。
  云数据库 TaurusDB支持[并行创建索引](https://support.huaweicloud.com/kerneldesc-taurusdb/taurusdb_20_0013.html)的功能。当数据库硬件资源空闲时，您可以通过并行创建索引功能加速DDL执行，避免阻塞后续相关的DML操作，缩短执行DDL操作的窗口期。
  表3并行DDL性能数据 
  | **数据规模**  | **传统单线程DDL** | **并行DDL（32线程）** | **耗时对比**  |
  |:---|:---|:---|:---|
  | 1亿行       | 约30分钟        | 约1.5分钟          | **提升20倍** |
  | 10亿行      | 约5小时         | 约15分钟           | **提升20倍** |
  | 60亿行（5TB） | 约15小时        | **约1小时**        | **提升15倍** |
     
  
- 秒级DDL（添加字段） TaurusDB支持使用ALGORITHM=INSTANT快速添加列，避免造成锁等待影响业务或者SQL执行超时无法新增成功。
  执行时间与表大小无关，1亿行和100亿行的耗时相同，不占用额外磁盘空间（无需临时表），不阻塞DML操作。
  详细的使用方法和约束限制请参见[秒级DDL（添加字段）](https://support.huaweicloud.com/taurusdb_faq/taurusdb_faq_0022.html)。
  
- 快速Truncate/Drop大表 执行Truncate/Drop时，社区版MySQL需要从Buffer Pool的LRU链表中移除该表的所有数据页，并从Flush链表中移除脏页，从而释放表空间文件。
  当Buffer Pool配置较大时（如256 GB、512 GB），扫描整个Buffer Pool的过程会非常耗时。此外，执行一张大表的DROP操作可能会导致实例卡顿数十秒甚至数分钟，进而影响业务查询的响应速度。
  TaurusDB支持快速Truncate/Drop功能，默认通过 innodb_rds_fast_truncate_or_drop_tablespace 参数开启。该功能对Buffer Pool页管理策略进行了深度优化：采用按表空间ID（Space ID）精准定位待清理页，以异步方式延迟清理，替代原有的全局扫描机制，从而大幅降低TRUNCATE/DROP操作对Buffer Pool的影响。
  
- DDL快速超时 在MySQL社区中，所有DDL操作均需获取MDL锁。当DDL操作在等待MDL锁时，会阻塞后续的DML操作。
  TaurusDB在执行ALTER TABLE、CREATE INDEX、DROP INDEX操作时，支持设置MDL锁等待超时时间。当DDL无法在指定时间内获取MDL锁时，将自动放弃执行，避免长时间阻塞后续DML操作。
  详细内容请参见[DDL快速超时](https://support.huaweicloud.com/kerneldesc-taurusdb/taurusdb_20_0014.html)。
  
- 非阻塞DDL 用户在执行DDL操作的时候，如果目标表存在未提交的长事务或大查询，DDL将持续等待获取MDL锁/MDL-X锁。在TaurusDB中，由于MDL锁/MDL-X锁具有最高优先级，等待DDL在等待MDL锁/MDL-X锁的过程中，新进入的事务请求会被排在DDL之后,将阻塞目标表上所有的新事务，这将导致业务连接的堆积和阻塞，可能会造成整个业务系统崩溃的严重后果。
  TaurusDB提供的[非阻塞DDL](https://support.huaweicloud.com/kerneldesc-taurusdb/taurusdb_20_0015.html)功能，可以保证即使在无法获得MDL锁/MDL-X锁的情况下，依然允许新事务进入目标表，从而保证整个业务系统的稳定。
  您也可以使用开源工具gh-ost，用于执行[Online DDL](https://support.huaweicloud.com/kerneldesc-taurusdb/taurusdb_20_0078.html)操作，避免传统DDL操作导致的长时间锁表，允许对该表进行并发的数据读写操作，从而最大限度地保证业务的连续性和可用性。