方法一：
进入mysql，执行set global slow_query_log=0;
将慢sql日志删除或改名备份：
rm -rf slow.log
或
mv slow.log slow.log_20230403
进入mysql，执行set global slow_query_log=1;
方法二：
先删除slow log,然后执行flush slow log;
```````````````````````````````````````````````````````````````````````````````````
在mysql中 FLUSH LOGS;
线上生产环境主从复制集群谨慎执行flush logs；!!!!!
操作会生成一个新的binlog文件。
如果在从库执行flush logs 不仅会生成一个新的binlog文件，而且会生成一个新的relaylog文件。
不仅如此，flush logs 还影响slow log和general log,
FLUSH LOGS
关闭并重新打开服务器所在的任何日志文件 写作。
此操作的效果等效于组合 这些操作的影响：
FLUSH BINARY LOGS
FLUSH ENGINE LOGS
FLUSH ERROR LOGS
FLUSH GENERAL LOGS
FLUSH RELAY LOGS
FLUSH SLOW LOGS
默认情况下，服务器将 FLUSH 语句写入二进制文件 日志，以便它们复制到副本。要抑制日志记录， 指定可选关键字或其别名。NO_WRITE_TO_BINLOGLOCAL
FLUSH LOGS, FLUSH BINARY LOGS, FLUSH TABLES WITH READ LOCK (with or without a table list), and FLUSH TABLES tbl_name ... FOR EXPORT 在任何情况下都不会将导出写入二进制日志 因为如果复制到副本，它们会导致问题。
flush选项
FLUSH [NO_WRITE_TO_BINLOG | LOCAL] { flush_option [, flush_option] ... | tables_option}flush_option: { BINARY LOGS | DES_KEY_FILE | ENGINE LOGS | ERROR LOGS | GENERAL LOGS | HOSTS | LOGS | PRIVILEGES | OPTIMIZER_COSTS | QUERY CACHE | RELAY LOGS [FOR CHANNEL channel] | SLOW LOGS | STATUS | USER_RESOURCES}tables_option: { TABLES | TABLES tbl_name [, tbl_name] ... | TABLES WITH READ LOCK | TABLES tbl_name [, tbl_name] ... WITH READ LOCK | TABLES tbl_name [, tbl_name] ... FOR EXPORT}FLUSH BINARY LOGS
关闭并重新打开服务器到的二进制日志文件,新生成一个，编号+1。
此操作对用表存binlog relay_log的没有影响 （由master_info_repository和relay_log_info_repository系统变量控制）。
FLUSH RELAY LOGS [FOR CHANNEL channel]
关闭并重新打开服务器所在的任何中继日志文件 写作。如果启用了中继日志记录，则序列号 中继日志文件相对于 以前的文件。
该子句使您能够命名该操作应用于哪个复制通道。
对CHANNEL通道执行刷新中继日志，以刷新特定复制通道的中继日志。
如果没有命名通道，也不存在额外的复制通道，则该操作将应用于默认通道。
如果没有命名通道，并且存在多个复制通道，则该操作将应用于除通道外的所有复制通道。
此操作对用表存二进制文件的表没有影响 和中继日志（由master_info_repository和relay_log_info_repository系统变量控制）。
FLUSH SLOW LOGS
关闭并重新打开服务器的错误日志文件，存在则继续写入，若不存在会生成新的 。
此操作对于table存储的没有影响。
FLUSH ERROR LOGS
关闭并重新打开服务器的错误日志文件，存在则继续写入，若不存在会生成新的 。
FLUSH GENERAL LOGS
关闭并重新打开服务器的错误日志文件，存在则继续写入，若不存在会生成新的 。
此操作对于table存储的没有影响。
FLUSH ENGINE LOGS
会刷新 SHOW ENGINE INNODB STATUS 此状态值
FLUSH HOSTS
清空host cache和Performance Schema host_cache表 缓存内容，并取消阻止任何被阻止的主机。
注意
与 TRUNCATE TABLE performance_schema.host_cache 不同 ，FLUSH HOSTS不会写入二进制日志。
FLUSH OPTIMIZER_COSTS
重新读取成本模型表，以便优化程序启动 使用存储在其中的当前成本估算。
服务器将警告写入错误日志中，以查找任何 无法识别的成本模型表条目。
FLUSH PRIVILEGES
从系统数据库中的授权表中重新读取权限。
如果在服务器启动时指定了 --skip-grant-tables 选项以禁用 MySQL 特权系统，提供了一种启用特权的方法。
释放服务器缓存的内存，作为 GRANT、CREATE USER、CREATE SERVER 和 INSTALL PLUGIN 语句的结果。 此内存不会由相应的 REVOKE、DROP USER、DROP 服务器和 UNINSTALL 插件语句释放， 因此，对于执行许多实例的服务器 导致缓存、缓存内存使用量增加的语句 除非它被刷新释放 特权。
FLUSH QUERY CACHE
对查询缓存进行碎片整理，以更好地利用其内存。刷新查询缓存不 从缓存中删除任何查询，这与刷新表或 .RESET QUERY CACHE
注意
查询缓存从 MySQL 5.7.20 开始已弃用，并且 在 MySQL 8.0 中删除。弃用包括刷新查询缓存。
FLUSH STATUS
刷新状态指示器。
此操作将当前线程的会话状态变量值添加到全局值，并将会话值重置为零。
一些全局变量也可能被重置为零。
它还将密钥缓存（默认和命名）的计数器重置为零，
并将Max_used_connections设置为当前打开的连接数。
注意
FLUSH STATUS不受read_only或super_read_only的影响，并且始终写入二进制日志。
FLUSH USER_RESOURCES
将所有每小时用户资源指示器重置为零。
重置资源指示器使具有 达到了每小时连接、查询或更新限制 立即恢复活动。冲洗 USER_RESOURCES不适用于以下限制 由max_user_connections系统控制的最大同时连接数 变量。
FLUSH DES_KEY_FILE
从指定的文件中重新加载 DES 密钥 位于 --des-key-file 选项位于 服务器启动时间。
注意
DES_ENCRYPT（） 和 DES_DECRYPT（） 函数是 在 MySQL 5.7 中已弃用，在 MySQL 中删除 8.0，并且不应再使用。
因此，--des-key-file 和 也被弃用和 在 MySQL 8.0 中删除。
刷新表语法
注意
这里的描述指示通过关闭表来刷新表，这适用于不同的情况，即将表内容刷新到磁盘，但保持打开状态。
这仍然允许在表打开时复制表文件，只要其他活动不修改它们。
FLUSH TABLES
关闭所有打开的表，强制所有正在使用的表 关闭，并刷新查询缓存和预准备语句 缓存。还刷新表 从查询缓存中删除所有查询结果，如语句。
当有 LOCK TABLES ... READ.时，FLUSH TABLES 不被允许,用 FLUSH TABLES tbl_name ... WITH READ LOCK 替代。
FLUSH TABLES tbl_name [, tbl_name] ...
FLUSH TABLES WITH READ LOCK
关闭所有打开的表并锁定，所有库的表加全局读锁。
此操作是获取备份的非常方便的方法，如果 您有一个文件系统，如 Veritas 或 ZFS，可以 及时快照。使用UNLOCK TABLES以释放锁。
FLUSH TABLES WITH READ LOCK获取全局读取锁，而不是表锁，因此在表锁定和隐式提交方面，它不受与LOCK TABLES和UNLOCK table相同的行为的影响：
只有当任何表当前已被LOCK TABLES锁定时，UNLOCK TABLES才会隐式提交任何活动事务。FLUSH TABLES WITH READ LOCK之后的UNLOCK TABLES不会发生提交，因为FLUSH TABLES WITH READ LOCK不会获取表锁。
开始一个事务会导致使用LOCK TABLES获取的表锁被释放，就好像您已经执行了 UNLOCK TABLES一样。开始事务不会释放使用FLUSH TABLES with read lock获取的全局读取锁。
在 MySQL 5.7.19 之前， FLUSH TABLES WITH READ LOCK与 XA 事务不兼容 交易。
FLUSH TABLES WITH READ LOCK不会阻止服务器将行插入日志表
FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK
刷新并获取命名表的读锁。
由于此操作获取表锁，需要每个表的LOCK TABLES权限+RELOAD权限。
该操作首先获取表的metadata locks，因此它等待打开这些表的事务完成。然后，该操作从表缓存中刷新表，重新打开表，获取表锁（如LOCK tables…READ），并将元数据锁从独占降级为共享。在操作获取锁并降级元数据锁之后，其他会话可以读取但不能修改表。
此操作仅适用于现有基地
（非table
如果一个名称引用了一个基表，则使用该表。
如果它引用了一个表，它将被忽略。
如果名称应用于视图，则会出现ER_WRONG_OBJECT错误。否则，将出现ER_NO_SUCH_TABLE error.TEMPORARY
使用UNLOCK TABLES释放锁，使用LOCK TABLS释放锁并获取其他锁，或使用START TRANSACTION释放锁并开始新事务。
这种FLUSH TABLES变体可以在一次操作中刷新和锁定表。它提供了一种变通方法来解决当存在活动的LOCK TABLES时不允许使用 LOCK TABLES ... READ.限制
此操作不执行隐式解锁表，因此，如果您在有任何活动的锁定表的情况下执行该操作，或者在没有首先释放所获取的锁的情况下第二次使用该操作，则会导致错误。
如果使用 HANDLER 打开刷新的表，则处理程序为 隐含地脸红，失去位置。
如果使用处理程序使用此命令，则处理程序将隐式刷新并丢失其的权限
FLUSH TABLES tbl_name [, tbl_name] ... FOR EXPORT
此FLUSH TABLES变体适用于表格。它确保已将对命名表的更改刷新到磁盘，以便在服务器运行时可以制作二进制表副本
因为FLUSH TABLES FOR EXPORT操作获取表上的锁，为导出表做准备，除了RELOAD权限外，它还需要每个表的LOCK tables和SELECT权限。
它获取命名表的共享元数据锁。只要其他会话具有已修改这些表或为其持有表锁的活动事务，操作就会阻止。获取锁后，操作会阻止试图更新表的事务，同时允许只读操作继续。
它检查表的所有存储引擎是否都支持。如果没有，则会发生ER_ILLEGAL_HA错误，并且操作失败。
该操作会通知每个表的存储引擎，使该表可以导出。存储引擎必须确保将任何挂起的更改写入磁盘。
该操作将会话置于锁表模式，以便在操作完成时不会释放先前获取的元数据锁。
此操作仅适用于现有的基表（非）。
如果一个名称引用了一个基表，则使用该表。
如果它引用了一个表，它将被忽略。
如果名称应用于视图，则会出现ER_WRONG_OBJECT错误。否则，将出现ER_NO_SUCH_TABLE错误。
InnoDB支持具有自己的.ibd文件文件的表
（即，在启用innodb_file_per_table设置的情况下创建的表）。
确保当操作通知任何更改都已刷新到磁盘时。
这允许在操作生效时对表内容进行二进制复制，因为该文件是事务一致的，并且可以在服务器运行时进行复制。不适用于系统表空间文件或具有索引的表。
FLUSH TABLES ...FOR EXPORT 支持分区表
当收到通知时，将某些类型的数据写入磁盘，这些数据通常保存在内存中或表空间文件外的单独磁盘缓冲区中。对于每个表，还会生成一个名为的文件，该文件位于与该表相同的数据库目录中。该文件包含稍后将表空间文件重新导入相同或不同服务器所需的元数据。
操作完成后，已将所有脏页刷新到表数据文件中。任何更改缓冲区条目都会在刷新之前进行合并。此时，表处于锁定和静止状态：表在磁盘上处于事务一致状态，您可以将表空间文件和相应的文件一起复制，以获得这些表的一致快照。
处理完表后，使用UNLOCK tables来释放LOCK TABLS的锁，或者使用START TRANSACTION来释放锁和开始新事务。
当这些语句中的任何一个在会话中有效时，尝试使用FLUSH TABLES。。。FOR EXPORT产生错误：
FLUSH TABLES ... WITH READ LOCK
FLUSH TABLES ... FOR EXPORT
LOCK TABLES ... READ
LOCK TABLES ... WRITE
FLUSH TABLES ... FOR EXPORT在会话中有效，尝试使用以下任何语句都会产生错误：
FLUSH TABLES WITH READ LOCK
FLUSH TABLES ... WITH READ LOCK
FLUSH TABLES ... FOR EXPORT
来源地址：https://blog.csdn.net/u013091109/article/details/129922626
