MySQL的FLUSH可以清理mysql数据库缓存数据
MySQL的FLUSH句法(清除或者重新加载内部缓存） FLUSH flush_option [,flush_option]，如果你想要清除一些MySQL使用内部缓存，你应该使用FLUSH命令。为了执行FLUSH，你必须有reload权限。
flush_option 可以是下列任何东西：
HOSTS 这个用的最多，经常碰见。主要是用来清空主机缓存表。如果你的某些主机改变IP数字，或如果你得到错误消息Host ... isblocked，你应该清空主机表。当在连接MySQL服务器时，对一台给定的主机有多于 max_connect_errors个错误连续不断地发生，MySQL为了安全的需要将会阻止该主机进一步的连接请求。清空主机表允许主机再尝试连接。
LOGS 关闭当前的二进制日志文件并创建一个新文件，新的二进制日志文件的名字在当前的二进制文件的编号上加1。
PRIVILEGES 这个也是经常使用的，每当重新赋权后，为了以防万一，让新权限立即生效，一般都执行一把，目地是从数据库授权表中重新装载权限到缓存中。
TABLES 关闭所有打开的表，同时该操作将会清空查询缓存中的内容。
FLUSH TABLES WITH READ LOCK 关闭所有打开的表，同时对于所有数据库中的表都加一个读锁，直到显示地执行unlock tables，该操作常常用于数据备份的时候。解锁的语句就是unlock tables。
FLUSH TABLES WITH READ LOCK对于数据库是全局的表锁定，如果只想锁定几个表，可以用LOCK TABLES tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE} 。这个命令同样需要unlock tables来解锁。
read-lock: 允许其他并发的读请求，但阻塞写请求，即可以同时读，但不允许任何写。也叫共享锁。write-lock: 不允许其他并发的读和写请求，是排他的(exclusive)。也叫独占锁
STATUS 重置大多数状态变量到0。
MASTER 删除所有的二进制日志索引文件中的二进制日志文件，重置二进制日志文件的索引文件为空，创建一个新的二进制日志文件,不过这个已经不推荐使用，改成reset master 了。可以想象，以前自己是多土啊，本来一条简单的命令就可以搞定的，却要好几条命令来，以前的做法是先查出来当前的二进制日志文件名，再用purge 操作。
QUERY CACHE 重整查询缓存，消除其中的碎片，提高性能，但是并不影响查询缓存中现有的数据，这点和Flush table 和Reset Query Cache（将会清空查询缓存的内容）不一样的。
SLAVE 类似于重置复制吧，让从数据库忘记主数据库的复制位置，同时也会删除已经下载下来的relay log,与Master一样，已经不推荐使用，改成Reset Slave了。这个也很有用的。
一般来讲，Flush操作都会记录在二进制日志文件中，但是FLUSH LOGS、FLUSH MASTER、FLUSH SLAVE、FLUSH TABLES WITH READ LOCK不会记录，因此上述操作如果记录在二进制日志文件中话，会对从数据库造成影响。
❷ 如何清理mysql数据库缓存数据
1、打开mysql的客户端 这里使用navicat，连接数据库，等到navicat主页面，双击需要操作的数据库连接。
❸ MySQL表对象缓存
表对象缓存： 是将某个表对象的字典信息（定义内容）缓存到内存中，用来提高对表的访问效率。某个表被访问过一次后，只要服务器没有关闭且表定义没有被修改的条件下，访问该表，只需要从内存中找到这个已经缓存起来的对象做相应操作即可。
用户访问表时，表对象在缓存时： 通过HASH算法找到TABLE_SHARE，然后每个线程构造各自的实例化TABLE即可。
用户访问表时，当表没有被缓存的情况下： 第一需要打开表，首先需要从系统表中将这个表的所有信息都读入内存中，这些信息包括表名、库名、所有列信息、列的默认值、表的字符集、对应的frm文件路径、所属存储引擎、主键等，将这些信息构造一个TABLE_SHARE结构体，这个结构体是表对象缓存的第一层，所有用户共享访问且为静态不允许修改，它是缓存在table_def_cache（由参数table_definition_cache控制）中的。
而真正与用户打交道的是TABLE_SHARE的衍生品，它对应结构体为TABLE，在被使用前需要将TABLE_SHARE结构体实例化TABLE才能被使用，由每个线程构造各自的实例化TABLE即可。（实例化的TABLE由table_open_cache及table_open_cache_instance控制）
注意1： DDL操作时会将所有instance锁住，而DML操作时instance之间互不干扰。
(DDL statements still require a lock on the entire cache, but such statements are much less frequent than DML statements.)
注意2： 一个线程中如果打开表过多，超过一个instance限制的大小时，是不能跨instance缓存的
(instance大小：table_open_cache / table_open_cache_instances)
表缓存涉及其他参数： 通过下面参数判断table_open_cache参数设置是否合理
table_open_cache_hit：能够从table open cache的free list中找到table则为命中，+1
table_open_cache_misses：与table_open_cache_hit相反，如果找不到则需要重新实例化则+1，通常发生在初始化第一次加载表或超过table_open_cache的设置被淘汰后需要重新实例化。
table_open_cache_overflow：table cache淘汰的数量，每次淘汰+1
opened_tables:已经打开的表数。如果Opened_tables很大，那么table_open_cache的值可能太小了。
open_tables：总的instance (table cache)的总数
❹ mysql调优技巧 增加线程缓存大小
增加线程缓存大小
连接管理器线程处理服务器监听的网络接口上的客户端连接请求。连接管理器线程将每个客户端连接与专用于它的线程关联，该线程负责处理该连接的身份验证和所有请求处理。因此，线程和当前连接的客户端之间是一对一的比例。确保线程缓存足够大以容纳所有传入请求是非常重要的。
MySQL提供了许多与连接线程相关的服务器变量：
线程缓存大小由thread_cache_size系统变量决定。默认值为0（无缓存），这将导致为每个新连接设置一个线程，并在连接终止时需要处理该线程。如果希望服务器每秒接收数百个连接请求，那么应该将thread_cache_size设置的足够高，以便大多数新连接可以使用缓存线程。可以在服务器启动或运行时设置max_connections的值。
还应该监视缓存中的线程数（Threads_cached）以及创建了多少个线程，因为无法从缓存中获取线程（Threads_created）。关于后者，如果Threads_created继续以每分钟多于几个线程的增加，请考虑增加thread_cache_size的值。
使用MySQL show status命令显示MySQL的变量和状态信息。这里有几个例子：
Monyog线程缓存监测
Monyog提供了一个监控线程缓存的屏幕，名为“线程”。与MySQL线程相关的服务器变量映射到以下Monyog指标：
Monyog线程屏幕还包括“线程缓存命中率”指标。这是一个提示线程缓存命中率的指标。如果值较低，则应该考虑增加线程缓存。在状态栏以百分比形式显示该值；它的值越接近100％越好。
如果这些指标的值等于或超过指定值，则可以将每一个指标配置为发出警告和/或严重警报
❺ MySQL性能调优 – 你必须了解的15个重要变量
前言:
MYSQL 应该是最流行了 WEB 后端数据库。虽然 NOSQL 最近越来越多的被提到，但是相信大部分架构师还是会选择 MYSQL 来做数据存储。本文作者总结梳理MySQL性能调优的15个重要变量，又不足需要补充的还望大佬指出。
1.DEFAULT_STORAGE_ENGINE
如果你已经在用MySQL 5.6或者5.7，并且你的数据表都是InnoDB，那么表示你已经设置好了。如果没有，确保把你的表转换为InnoDB并且设置default_storage_engine为InnoDB。
为什么？简而言之，因为InnoDB是MySQL(包括Percona Server和MariaDB)最好的存储引擎 – 它支持事务，高并发，有着非常好的性能表现(当配置正确时)。这里有详细的版本介绍为什么
2.INNODB_BUFFER_POOL_SIZE
这个是InnoDB最重要变量。实际上，如果你的主要存储引擎是InnoDB，那么对于你，这个变量对于MySQL是最重要的。
基本上，innodb_buffer_pool_size指定了MySQL应该分配给InnoDB缓冲池多少内存，InnoDB缓冲池用来存储缓存的数据，二级索引，脏数据(已经被更改但没有刷新到硬盘的数据)以及各种内部结构如自适应哈希索引。
根据经验，在一个独立的MySQL服务器应该分配给MySQL整个机器总内存的80%。如果你的MySQL运行在一个共享服务器，或者你想知道InnoDB缓冲池大小是否正确设置，详细请看这里。
3.INNODB_LOG_FILE_SIZE
InnoDB重做日志文件的设置在MySQL社区也叫做事务日志。直到MySQL 5.6.8事务日志默认值innodb_log_file_size=5M是唯一最大的InnoDB性能杀手。从MySQL 5.6.8开始，默认值提升到48M,但对于许多稍繁忙的系统，还远远要低。
根据经验，你应该设置的日志大小能在你服务器繁忙时能存储1-2小时的写入量。如果不想这么麻烦，那么设置1-2G的大小会让你的性能有一个不错的表现。这个变量也相当重要，更详细的介绍请看这里。
当然，如果你有大量的大事务更改，那么，更改比默认innodb日志缓冲大小更大的值会对你的性能有一定的提高，但是你使用的是autocommit，或者你的事务更改小于几k，那还是保持默认的值吧。
4.INNODB_FLUSH_LOG_AT_TRX_COMMIT
默认下，innodb_flush_log_at_trx_commit设置为1表示InnoDB在每次事务提交后立即刷新同步数据到硬盘。如果你使用autocommit，那么你的每一个INSERT, UPDATE或DELETE语句都是一个事务提交。
同步是一个昂贵的操作(特别是当你没有写回缓存时)，因为它涉及对硬盘的实际同步物理写入。所以如果可能，并不建议使用默认值。
两个可选的值是0和2:
* 0表示刷新到硬盘，但不同步(提交事务时没有实际的IO操作)
* 2表示不刷新和不同步(也没有实际的IO操作)
所以你如果设置它为0或2，则同步操作每秒执行一次。所以明显的缺点是你可能会丢失上一秒的提交数据。具体来说，你的事务已经提交了，但服务器马上断电了，那么你的提交相当于没有发生过。
显示的，对于金融机构，如银行，这是无法忍受的。不过对于大多数网站，可以设置为innodb_flush_log_at_trx_commit=0|2，即使服务器最终崩溃也没有什么大问题。毕竟，仅仅在几年前有许多网站还是用MyISAM，当崩溃时会丢失30s的数据(更不要提那令人抓狂的慢修复进程)。
那么，0和2之间的实际区别是什么？性能明显的差异是可以忽略不计，因为刷新到操作系统缓存的操作是非常快的。所以很明显应该设置为0，万一MySQL崩溃(不是整个机器)，你不会丢失任何数据，因为数据已经在OS缓存，最终还是会同步到硬盘的。
5.SYNC_BINLOG
已经有大量的文档写到sync_binlog，以及它和innodb_flush_log_at_trx_commit的关系，下面我们来简单的介绍下：
a) 如果你的服务器没有设置从服务器，而且你不做备份，那么设置sync_binlog=0将对性能有好处。
b) 如果你有从服务器并且做备份，但你不介意当主服务器崩溃时在二进制日志丢失一些事件，那么为了更好的性能还是设置为sync_binlog=0.
c) 如果你有从服务器并且备份，你非常在意从服务器的一致性，以及能及时恢复到一个时间点(通过使用最新的一致性备份和二进制日志将数据库恢复到特定时间点的能力)，那么你应该设置innodb_flush_log_at_trx_commit=1，并且需要认真考虑使用sync_binlog=1。
问题是sync_binlog=1代价比较高 – 现在每个事务也要同步一次到硬盘。你可能会想为什么不把两次同步合并成一次，想法正确 – 新版本的MySQL(5.6和5.7，MariaDB和Percona Server)已经能合并提交，那么在这种情况下sync_binlog=1的操作也不是这么昂贵了，但在旧的mysql版本中仍然会对性能有很大影响。
6.INNODB_FLUSH_METHOD
将innodb_flush_method设置为O_DIRECT以避免双重缓冲.唯一一种情况你不应该使用O_DIRECT是当你操作系统不支持时。但如果你运行的是Linux，使用O_DIRECT来激活直接IO。
不用直接IO，双重缓冲将会发生，因为所有的数据库更改首先会写入到OS缓存然后才同步到硬盘 – 所以InnoDB缓冲池和OS缓存会同时持有一份相同的数据。特别是如果你的缓冲池限制为总内存的50%，那意味着在写密集的环境中你可能会浪费高达50%的内存。如果没有限制为50%，服务器可能由于OS缓存的高压力会使用到swap。
简单地说，设置为innodb_flush_method=O_DIRECT。
7.INNODB_BUFFER_POOL_INSTANCES
MySQL 5.5引入了缓冲实例作为减小内部锁争用来提高MySQL吞吐量的手段。
在5.5版本这个对提升吞吐量帮助很小，然后在MySQL 5.6版本这个提升就非常大了，所以在MySQL5.5中你可能会保守地设置innodb_buffer_pool_instances=4，在MySQL 5.6和5.7中你可以设置为8-16个缓冲池实例。
你设置后观察会觉得性能提高不大，但在大多数高负载情况下，它应该会有不错的表现。
对了，不要指望这个设置能减少你单个查询的响应时间。这个是在高并发负载的服务器上才看得出区别。比如多个线程同时做许多事情。
8.INNODB_THREAD_CONCURRENCY
InnoDB有一种方法来控制并行执行的线程数 – 我们称为并发控制机制。大部分是由innodb_thread_concurrency值来控制的。如果设置为0，并发控制就关闭了，因此InnoDB会立即处理所有进来的请求(尽可能多的)。
在你有32CPU核心且只有4个请求时会没什么问题。不过想象下你只有4CPU核心和32个请求时 – 如果你让32个请求同时处理，你这个自找麻烦。因为这些32个请求只有4 CPU核心，显然地会比平常慢至少8倍(实际上是大于8倍)，而然这些请求每个都有自己的外部和内部锁，这有很大可能堆积请求。
下面介绍如何更改这个变量，在mysql命令行提示符执行：
对于大多数工作负载和服务器，设置为8是一个好开端，然后你可以根据服务器达到了这个限制而资源使用率利用不足时逐渐增加。可以通过show engine innodb statusG来查看目前查询处理情况，查找类似如下行：
9.SKIP_NAME_RESOLVE
这一项不得不提及，因为仍然有很多人没有添加这一项。你应该添加skip_name_resolve来避免连接时DNS解析。
大多数情况下你更改这个会没有什么感觉，因为大多数情况下DNS服务器解析会非常快。不过当DNS服务器失败时，它会出现在你服务器上出现“unauthenticated connections” ，而就是为什么所有的请求都突然开始慢下来了。
所以不要等到这种事情发生才更改。现在添加这个变量并且避免基于主机名的授权。
10.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX
* innodb_io_capacity：用来当刷新脏数据时，控制MySQL每秒执行的写IO量。
* innodb_io_capacity_max: 在压力下，控制当刷新脏数据时MySQL每秒执行的写IO量
首先，这与读取无关 – SELECT查询执行的操作。对于读操作，MySQL会尽最大可能处理并返回结果。至于写操作，MySQL在后台会循环刷新，在每一个循环会检查有多少数据需要刷新，并且不会用超过innodb_io_capacity指定的数来做刷新操作。这也包括更改缓冲区合并（在它们刷新到磁盘之前，更改缓冲区是辅助脏页存储的关键）。
第二，我需要解释一下什么叫“在压力下”，MySQL中称为”紧急情况”，是当MySQL在后台刷新时，它需要刷新一些数据为了让新的写操作进来。然后，MySQL会用到innodb_io_capacity_max。
那么，应该设置innodb_io_capacity和innodb_io_capacity_max为什么呢？
最好的方法是测量你的存储设置的随机写吞吐量，然后给innodb_io_capacity_max设置为你的设备能达到的最大IOPS。innodb_io_capacity就设置为它的50-75%，特别是你的系统主要是写操作时。
通常你可以预测你的系统的IOPS是多少。例如由8 15k硬盘组成的RAID10能做大约每秒1000随机写操作，所以你可以设置innodb_io_capacity=600和innodb_io_capacity_max=1000。许多廉价企业SSD可以做4,000-10,000 IOPS等。
这个值设置得不完美问题不大。但是，要注意默认的200和400会限制你的写吞吐量，因此你可能偶尔会捕捉到刷新进程。如果出现这种情况，可能是已经达到你硬盘的写IO吞吐量，或者这个值设置得太小限制了吞吐量。
11.INNODB_STATS_ON_METADATA
如果你跑的是MySQL 5.6或5.7，你不需要更改innodb_stats_on_metadata的默认值，因为它已经设置正确了。
不过在MySQL 5.5或5.1，强烈建议关闭这个变量 – 如果是开启，像命令show table status会立即查询INFORMATION_SCHEMA而不是等几秒再执行，这会使用到额外的IO操作。
从5.1.32版本开始，这个是动态变量，意味着你不需要重启MySQL服务器来关闭它。
12.INNODB_BUFFER_POOL_DUMP_AT_SHUTDOWN & INNODB_BUFFER_POOL_LOAD_AT_STARTUP
innodb_buffer_pool_mp_at_shutdown和innodb_buffer_pool_load_at_startup这两个变量与性能无关，不过如果你偶尔重启mysql服务器(如生效配置)，那么就有关。当两个都激活时，MySQL缓冲池的内容(更具体地说，是缓存页)在停止MySQL时存储到一个文件。当你下次启动MySQL时，它会在后台启动一个线程来加载缓冲池的内容以提高预热速度到3-5倍。
两件事：
第一，它实际上没有在关闭时复制缓冲池内容到文件，仅仅是复制表空间ID和页面ID – 足够的信息来定位硬盘上的页面了。然后它就能以大量的顺序读非常快速的加载那些页面，而不是需要成千上万的小随机读。
第二，启动时是在后台加载内容，因为MySQL不需要等到缓冲池内容加载完成再开始接受请求(所以看起来不会有什么影响)。
从MySQL 5.7.7开始，默认只有25%的缓冲池页面在mysql关闭时存储到文件，但是你可以控制这个值 – 使用innodb_buffer_pool_mp_pct，建议75-100。
这个特性从MySQL 5.6才开始支持。
13.INNODB_ADAPTIVE_HASH_INDEX_PARTS
如果你运行着一个大量SELECT查询的MySQL服务器(并且已经尽可能优化)，那么自适应哈希索引将下你的下一个瓶颈。自适应哈希索引是InnoDB内部维护的动态索引，可以提高最常用的查询模式的性能。这个特性可以重启服务器关闭，不过默认下在mysql的所有版本开启。
这个技术非常复杂，在大多数情况下它会对大多数类型的查询直到加速的作用。不过，当你有太多的查询往数据库，在某一个点上它会花过多的时间等待AHI锁和闩锁。
如果你的是MySQL 5.7，没有这个问题 – innodb_adaptive_hash_index_parts默认设置为8，所以自适应哈希索引被切割为8个分区，因为不存在全局互斥。
不过在mysql 5.7前的版本，没有AHI分区数量的控制。换句话说，有一个全局互斥锁来保护AHI，可能导致你的select查询经常撞墙。
所以如果你运行的是5.1或5.6，并且有大量的select查询，最简单的方案就是切换成同一版本的Percona Server来激活AHI分区。
14.QUERY_CACHE_TYPE
如果人认为查询缓存效果很好，肯定应该使用它。好吧，有时候是有用的。不过这个只在你在低负载时有用，特别是在低负载下大多数是读取，小量写或者没有。
如果是那样的情况，设置query_cache_type=ON和query_cache_size=256M就好了。不过记住不能把256M设置更高的值了，否则会由于查询缓存失效时，导致引起严重的服务器停顿。
如果你的MySQL服务器高负载动作，建议设置query_cache_size=0和query_cache_type=OFF，并重启服务器生效。那样Mysql就会停止在所有的查询使用查询缓存互斥锁。
15.TABLE_OPEN_CACHE_INSTANCES
从MySQL 5.6.6开始，表缓存能分割到多个分区。
表缓存用来存放目前已打开表的列表，当每一个表打开或关闭互斥体就被锁定 – 即使这是一个隐式临时表。使用多个分区绝对减少了潜在的争用。
从MySQL 5.7.8开始，table_open_cache_instances=16是默认的配置。
欢迎做Java的工程师朋友们私信我资料免费获取免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）
其中覆盖了互联网的方方面面，期间碰到各种产品各种场景下的各种问题，很值得大家借鉴和学习，扩展自己的技术广度和知识面。
❻ redis做mysql的缓存
redis缓存其实就是把经常访问的数据放到redis里面，用户查询的时候先去redis查询，没有查到就执行sql语句查询，同时把数据同步到redis里面。redis只做读操作，在内存中查询速度快。
使用redis做缓存必须解决两个问题，首先就是确定用何种数据结构存储来自mysql的数据；确定数据结构之后就是需要确定用什么标识来作为数据的key。
mysql是按照表存储数据的，这些表是由若干行组成。每一次执行select查询，mysql都会返回一个结果集，这个结果是由若干行组成的。redis有五种数据结构：列表list，哈希hash，字符串string，集合set，sorted set(有序集合)，对比几种数据结构，string和hash是比较适合存储行的数据结构，可以把数据转成json字符串存入redis。
全量遍历键： keys pattern keys *
有人说 KEYS 相当于关系性数据的库的 select * ，在生产环境几乎是要禁用的
不管上面说的对不对， keys 肯定是有风险的。那我们就换一种方案，在存数据的时候。把数据的键存一下，也存到redis里面选hash类型，那么取的时候就可以直接通过这个hash获取所有的值，自我感觉非常好用！
❼ mysql缓存如何使用
应用redis实现数据的读写，同时利用队列处理器定时将数据写入mysql。
同时要注意避免冲突，在redis启动时去mysql读取所有表键值存入redis中，往redis写数据时，对redis主键自增并进行读取，若mysql更新失败，则需要及时清除缓存及同步redis主键。
这样处理，主要是实时读写redis，而mysql数据则通过队列异步处理，缓解mysql压力，不过这种方法应用场景主要基于高并发，而且redis的高可用集群架构相对更复杂，一般不是很推荐。
❽ MySQL的缓存对象有什么
1）只缓存SELECT语句。SHOW命令和存储程序不会被缓存。
2）不能缓存预编译语句（prepared statement）和游标。查询缓存中保存的是查询语句和结果集，而预编译语句中存在替代符和额外的参数，游标从块中读取结果，因此上述两种情况不能被缓存。
3）查询语句不能包含动态内容。多次执行某SQL，必须能够返回相同的结果集，因此查询中不能包含像UUID(), RAND(), CONNECTION_ID()这样的函数。
4）SQL中包含定义函数和自定义变量不会被缓存。
Mysql> set @id=1;
Mysql> select * from test where id=@id 像这种语句也不会缓存
5）对系统表的查询不会被缓存。
Mysql> select * from mysql.user where user=’root’
6）非自动提交（显示使用BEGIN…END）事务中的SQL不会被缓存。
7）使用TEMPORARY表的SQL不会被缓存。
8）不使用任何表的SQL不会被缓存。
Mysql> select @id;
9）在下面的SELECT操作也不会被缓存：
SELECT ...IN SHARE MODE
SELECT ...FOR UPDATE
SELECT ...INTO OUTFILE ...
SELECT ...INTO DUMPFILE ...
SELECT * FROM ...WHERE autoincrement_col IS NULL
❾ mysql 一级缓存和二级缓存的区别
一、Session缓存（又称作事务缓存）：Hibernate内置的，不能卸除。
缓存范围：缓存只能被当前Session对象访问。缓存的生命周期依赖于Session的生命周期，当Session被关闭后，缓存也就结束生命周期。
Hibernate一些与一级缓存相关的操作（时间点）：
数据放入缓存：
1. save()。当session对象调用save()方法保存一个对象后，该对象会被放入到session的缓存中。
2. get()和load()。当session对象调用get()或load()方法从数据库取出一个对象后，该对象也会被放入到session的缓存中。
3. 使用HQL和QBC等从数据库中查询数据。
二、SessionFactory缓存（又称作应用缓存）：使用第三方插件，可插拔。
❿ 使用mysql怎么进行处理缓存的
如果数据库是安装在你机器上的 那么你可以暂时把MYSQL关闭 然后进入安装目录 找到data文件夹 这里面就是放置数据库文件的。。你会看到data里面每一个文件夹都对应你一个数据库名称 把他们删除就好了 就彻底没了 不过可别把mysql这个文件夹删了 还有别的文件 比如.err别乱删哦。
如果这个你不会 或者说文件在使用删除不了 那么你就用mysql的可视化工具 比如mysql-front 5.1 进去删除 效果都是一样。