配置建议

CPU飙升

• 建议新上业务时，提前对关键SQL通过EXPLAIN、SQL诊断等工具进行执行计划分析，根据优化建议添加索引，避免全表扫描。
• 如果实例规格较小，可以适当地扩大实例规格。
• 开启读写分离：将读请求分流到只读节点，减轻主库压力。

1. 获取明显导致CPU冲高的SQL，并对其进行SQL限流。
2. 若难以找到明显导致CPU冲高的SQL，则可以选择以下方式快速恢复：
   1. 主备倒换：当主节点的CPU打满，但是只读节点CPU不高时，可以主备倒换快速恢复业务。
   2. 重启只读节点：当某个只读CPU打满时，可以重启该只读节点。
   3. 重启实例：请谨慎使用（重启会导致Buffer Pool中的热数据被清空）。重启实例为最后手段，当所有节点的CPU都打满时，可以重启实例快速恢复业务。

SQL优化：使用EXPLAIN分析执行计划，添加合适的索引避免全表扫描。

内存高负载

• 适度调小innodb_buffer_pool_size参数值，保证其大小不超过实例内存的70%。修改参数详情内容请参见修改TaurusDB实例参数。
• 如果实例规格较小，可以适当地扩大实例规格。
• kill空闲会话。
• 设置监控告警。

获取明显导致内存冲高的SQL，并对其进行SQL限流。

优化异常SQL，避免其大量消耗内存，例如：

1. 只查询必要字段，而不使用select *。
2. 加上limit使用分页查询，而不是一次性查询全量数据。
3. 尽可能利用索引避免排序，例如为排序字段建立联合索引。
4. 使用join时，被驱动表的连接列必须有索引，通常选择小表作为驱动表（可通过 STRAIGHT_JOIN 强制指定）
5. 使用IN查询时，值列表控制在200 个以内，并确保 IN 列有索引。
6. 针对大的Insert语句，建议分批插入，values后的值个数通过不超过100。
7. 针对大的Update语句，建议分配更新，SQL后面加上limit N，N值通常不超过100。
8. 避免一次查询过多含BLOB、TEXT 字段的数据行，可以通过分页查询LIMIT，减少查询数据量。

连接数满

1. 业务侧合理配置连接池，业务侧无连接池容易导致连接数满。

2. 结合业务实际，合理设置max_connections、max_user_connections、wait_timeout/interactive_timeout等参数值。

3. 定期kill掉空闲会话、长会话等。

• 临时调大max_connections的值，一般建议扩大为当前值的一倍。业务恢复之后再调回原值。
• 对异常SQL进行SQL限流。

排查业务找出连接泄露的原因并整改。例如业务未使用连接池，则合理配置连接池。