我们的一位用户正在使用Cloud SQL（MySQL）。
它们打开general logs标志，并且log_output为file。
由于某些特殊情况，他们需要这些常规日志。
MySQL生成大约8TB的常规日志，这些日志导致磁盘使用量更大。
这是棘手的部分：
他们想删除这些general logs file [1]以减小磁盘的大小。
但是，这是他们的生产数据库。他们担心此操作会影响数据库的性能。
由于这些日志文件位于/var/log/mysql.log中，因此删除日志操作将在操作系统级别执行，对吗？ -> 这是我们不确定的部分。
如果我们的用户执行此truncateAPI，此操作是否会影响其数据库的性能？
有没有针对这种情况的最佳实践？
P.S：我们的用户不想关闭general logs标志。他们将尝试一段时间截断这些日志。但是目前，他们需要截断过去几个月积累的大量日志。
[1] https://cloud.google.com/sql/docs/mysql/admin-api/v1beta4/instances/truncateLog
答案 0 :(得分：1)
我了解到您已打开general logs标志，并且log_output是FILE，并且您想删除这些常规日志文件以减小磁盘大小。
根据官方文档link：
要使常规或慢速查询日志可用，请启用 相应的标志，并将log_output标志设置为FILE。这使得 使用Google Cloud中的Logs Viewer可获得的日志输出 平台控制台。请注意，需要支付Stackdriver Logging费用。
如果log_output设置为NONE，则将无法访问日志。
如果将log_output设置为TABLE，则日志输出将放置在以下位置的表中 您的数据库。如果此表变大，可能会影响实例 重新启动时间或导致实例失去其SLA覆盖范围；为了这 原因，不建议使用TABLE选项。如果需要，您可以 使用API截断日志表。有关更多信息，请参见 instances.truncateLog参考页。
Instances: truncateLog截断MySQL常规和慢速查询日志表。
如果我的理解正确，您将无法“截断它们在过去几个月中积累的大量日志”，因为您没有将log_output设置为TABLE，因此没有要截断的表。 / p>
关于数据库性能：TRUNCATE TABLE Statement
在具有大型InnoDB缓冲池和 启用innodb_adaptive_hash_index，TRUNCATE TABLE操作可能 由于进行LRU扫描而导致系统性能暂时下降 删除InnoDB表的自适应哈希索引条目时发生。 该问题已在MySQL 5.5.23中针对DROP TABLE解决（错误 13704145，错误＃64284），但仍然是TRUNCATE TABLE的已知问题（错误＃68184）。
在这里您可以检查MySQL Server Log Maintenance。
删除MySQL general_log文件不应影响数据库的性能。