常见问题
连接数耗尽
先区分连接泄漏、慢 SQL、锁等待和容量不足。直接提高 max_connections 可能让实例因并发内存、CPU 和锁争用更快失效。
检查连接状态、事务持续时间、来源应用和连接池指标，优先终止明确无用的异常会话，并修复超时与归还逻辑。
DDL 长时间等待
常见原因是长期事务持有 Metadata Lock。等待中的 DDL 又阻塞后续请求时，会形成队列放大。
使用 performance_schema.metadata_locks、processlist 和 information_schema.innodb_trx 找到阻塞者。结束会话前应确认事务内容和业务影响。
磁盘即将写满
分别检查数据文件、临时文件、Undo、Redo、Binlog、Relay Log、General/Slow Log 和备份。不要在 Data Directory 中直接删除不认识的文件。
可安全处理的对象也应使用相应命令或保留策略，例如在确认所有 Replica 和备份不再需要后 PURGE BINARY LOGS。
误执行 UPDATE 或 DELETE
已提交事务不能依靠 Undo 手工恢复。正确路径通常是：
- 暂停继续扩大影响的写入。
- 确认误操作时间、事务和影响范围。
- 在隔离实例恢复完整备份并重放 Binlog 到目标点。
- 导出受影响数据，经业务确认后回补，或整体切换恢复实例。
不要在生产实例中直接逆向猜测 SQL，尤其涉及并发修改时。
大表删除后文件没有缩小
DELETE 释放的 Page 通常先在 InnoDB 表空间内部复用，不保证 .ibd 文件立即归还操作系统。OPTIMIZE TABLE 可能重建表并需要额外磁盘、长时间和复制资源，不应把它作为每次删除后的固定动作。
按时间淘汰的大表更适合分区并删除整个 Partition；是否使用分区应同时考虑唯一键、查询裁剪和维护复杂度。
实例异常后无法启动
保留原始 Error Log 和数据目录，不删除 ibdata、Redo、Undo 或 .ibd。先确认磁盘空间、权限、配置变更、版本升级和存储错误。
innodb_force_recovery 只用于受控的数据抢救，并且不同级别可能禁止写入或进一步损害一致性。应复制现场、在专业恢复流程中只读导出数据，再建立新实例。
ORDER BY 慢
确认 Filter 与 Sort 能否由同一复合索引按顺序提供，是否因为范围条件、方向混合、表达式或 Collation 触发额外排序。提高 sort_buffer_size 不是通用修复，因为它可能按连接或执行分配并放大内存。