用SQLYog进行数据导入的时候出错：MySql Error Code: 2006 – MySQL 服务器已离线 解决： 1.在mysql的配置文件最后添加：max_allowed_packet = 100M 2.如果还不行，就再添加以下两行： interactive_timeout=28800000 wait_timeout=28800000
View DetailsmySQL错误: The used table type doesn’t support FULLTEXT indexes 说明不支持全文索引 解决方法有两种，网上大多方法是： 1.打开my.ini，搜索default-storage-engine=，你搜索到的应该是 default-storage-engine=INNODB，把INNODB改成MyISAM，然后重新启动Mysql 这样所有的表都支持全文索引了。 2.如果你只想某张表具有全文索引，这只需要要把表的type改成MyISAM 具体做法如下： ALTER TABLE 表名 TYPE = MyISAM; 或者你和我一样用了navicat工具： 可以在选择-》设计表-》选项 在表类型中改成MyISAM即可。 如果大家用上述方法碰到问题，欢迎大家和我交流，我及时更正。 转自：http://www.cnblogs.com/liveandevil/archive/2012/08/10/2631601.html
View DetailsCase具有两种格式。简单Case函数和Case搜索函数。 –简单Case函数 CASE sex WHEN ’1′ THEN ’男’ WHEN ’2′ THEN ’女’ ELSE ’其他’ END –Case搜索函数 CASE WHEN sex = ’1′ THEN ’男’ WHEN sex = ’2′ THEN ’女’ ELSE ’其他’ END 这两种方式，可以实现相同的功能。简单Case函数的写法相对比较简洁，但是和Case搜索函数相比，功能方面会有些限制，比如写判断式。 还有一个需要注意的问题，Case函数只返回第一个符合条件的值，剩下的Case部分将会被自动忽略。 –比如说，下面这段SQL，你永远无法得到“第二类”这个结果 CASE WHEN col_1 IN ( ’a', ’b') THEN ’第一类’ WHEN col_1 IN (‘a’) THEN ’第二类’ ELSE’其他’ END 下面我们来看一下，使用Case函数都能做些什么事情。 一，已知数据按照另外一种方式进行分组，分析。 有如下数据:(为了看得更清楚，我并没有使用国家代码，而是直接用国家名作为Primary Key) 国家（country）人口（population） 中国600 美国100 加拿大100 英国200 法国300 日本250 德国200 墨西哥50 印度250 根据这个国家人口数据，统计亚洲和北美洲的人口数量。应该得到下面这个结果。 洲人口 亚洲1100 北美洲250 其他700 想要解决这个问题，你会怎么做？生成一个带有洲Code的View，是一个解决方法，但是这样很难动态的改变统计的方式。 如果使用Case函数，SQL代码如下: SELECT SUM(population), CASE country WHEN ’中国’ THEN ’亚洲’ WHEN ’印度’ THEN ’亚洲’ WHEN ’日本’ THEN ’亚洲’ WHEN ’美国’ THEN ’北美洲’ WHEN ’加拿大’ THEN ’北美洲’ WHEN ’墨西哥’ THEN ’北美洲’ ELSE ’其他’ END FROM Table_A GROUP BY CASE country WHEN ’中国’ THEN ’亚洲’ WHEN ’印度’ THEN ’亚洲’ WHEN ’日本’ THEN ’亚洲’ WHEN ’美国’ THEN ’北美洲’ WHEN ’加拿大’ THEN ’北美洲’ WHEN ’墨西哥’ THEN ’北美洲’ ELSE ’其他’ END; 同样的，我们也可以用这个方法来判断工资的等级，并统计每一等级的人数。SQL代码如下； SELECT CASE WHEN salary <= 500 THEN ’1′ WHEN salary > 500 AND salary <= 600 THEN ’2′ WHEN salary > 600 AND salary <= 800 THEN ’3′ WHEN salary > 800 AND salary <= 1000 THEN ’4′ ELSE NULL END salary_class, COUNT(*) FROM Table_A GROUP BY CASE WHEN salary <= 500 THEN ’1′ WHEN salary > 500 AND salary <= 600 THEN ’2′ WHEN salary > 600 AND salary <= 800 THEN ’3′ WHEN salary > 800 AND salary <= 1000 THEN ’4′ ELSE NULL END; 二，用一个SQL语句完成不同条件的分组。 有如下数据 国家（country）性别（sex）人口（population） 中国1 340 中国2 260 美国1 45 美国2 55 加拿大1 51 加拿大2 49 英国1 40 英国2 60 按照国家和性别进行分组，得出结果如下 国家男女 中国340 260 美国45 55 加拿大51 49 英国40 60 普通情况下，用UNION也可以实现用一条语句进行查询。但是那样增加消耗(两个Select部分)，而且SQL语句会比较长。 […]
View Details1、 首先要搞明白什么叫执行计划？ 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用“全表扫描”方式。 可见，执行计划并不是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要： (1) SQL语句是否清晰地告诉查询优化器它想干什么？ (2) 查询优化器得到的数据库统计信息是否是最新的、正确的？ 2、 统一SQL语句的写法 对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。 select * from dual select * From dual 其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划。所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！ 3、 不要把SQL语句写得太复杂 我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的。我拿着这2页长的SQL语句去请教原作者，结果他说时间太长，他一时也看不懂了。可想而知，连原作者都有可能看糊涂的SQL语句，数据库也一样会看糊涂。 一般，将一个Select语句的结果作为子集，然后从该子集中再进行查询，这种一层嵌套语句还是比较常见的，但是根据经验，超过3层嵌套，查询优化器就很容易给出错误的执行计划。因为它被绕晕了。像这种类似人工智能的东西，终究比人的分辨力要差些，如果人都看晕了，我可以保证数据库也会晕的。 另外，执行计划是可以被重用的，越简单的SQL语句被重用的可能性越高。而复杂的SQL语句只要有一个字符发生变化就必须重新解析，然后再把这一大堆垃圾塞在内存里。可想而知，数据库的效率会何等低下。 4、 使用“临时表”暂存中间结果 简化SQL语句的重要方法就是采用临时表暂存中间结果，但是，临时表的好处远远不止这些，将临时结果暂存在临时表，后面的查询就在tempdb中了，这可以避免程序中多次扫描主表，也大大减少了程序执行中“共享锁”阻塞“更新锁”，减少了阻塞，提高了并发性能。 5、 OLTP系统SQL语句必须采用绑定变量 select * from orderheader where changetime > ‘2010-10-20 00:00:01’ select * from orderheader where changetime > ‘2010-09-22 00:00:01’ 以上两句语句，查询优化器认为是不同的SQL语句，需要解析两次。如果采用绑定变量 select * from orderheader where changetime > @chgtime @chgtime变量可以传入任何值，这样大量的类似查询可以重用该执行计划了，这可以大大降低数据库解析SQL语句的负担。一次解析，多次重用，是提高数据库效率的原则。 6、 绑定变量窥测 事物都存在两面性，绑定变量对大多数OLTP处理是适用的，但是也有例外。比如在where条件中的字段是“倾斜字段”的时候。 “倾斜字段”指该列中的绝大多数的值都是相同的，比如一张人口调查表，其中“民族”这列，90%以上都是汉族。那么如果一个SQL语句要查询30岁的汉族人口有多少，那“民族”这列必然要被放在where条件中。这个时候如果采用绑定变量@nation会存在很大问题。 试想如果@nation传入的第一个值是“汉族”，那整个执行计划必然会选择表扫描。然后，第二个值传入的是“布依族”，按理说“布依族”占的比例可能只有万分之一，应该采用索引查找。但是，由于重用了第一次解析的“汉族”的那个执行计划，那么第二次也将采用表扫描方式。这个问题就是著名的“绑定变量窥测”，建议对于“倾斜字段”不要采用绑定变量。 7、 只在必要的情况下才使用begin tran SQL Server中一句SQL语句默认就是一个事务，在该语句执行完成后也是默认commit的。其实，这就是begin tran的一个最小化的形式，好比在每句语句开头隐含了一个begin tran，结束时隐含了一个commit。 有些情况下，我们需要显式声明begin tran，比如做“插、删、改”操作需要同时修改几个表，要求要么几个表都修改成功，要么都不成功。begin tran 可以起到这样的作用，它可以把若干SQL语句套在一起执行，最后再一起commit。好处是保证了数据的一致性，但任何事情都不是完美无缺的。Begin tran付出的代价是在提交之前，所有SQL语句锁住的资源都不能释放，直到commit掉。 可见，如果Begin tran套住的SQL语句太多，那数据库的性能就糟糕了。在该大事务提交之前，必然会阻塞别的语句，造成block很多。 Begin tran使用的原则是，在保证数据一致性的前提下，begin tran 套住的SQL语句越少越好！有些情况下可以采用触发器同步数据，不一定要用begin tran。 8、 一些SQL查询语句应加上nolock 在SQL语句中加nolock是提高SQL Server并发性能的重要手段，在oracle中并不需要这样做，因为oracle的结构更为合理，有undo表空间保存“数据前影”，该数据如果在修改中还未commit，那么你读到的是它修改之前的副本，该副本放在undo表空间中。这样，oracle的读、写可以做到互不影响，这也是oracle广受称赞的地方。SQL Server 的读、写是会相互阻塞的，为了提高并发性能，对于一些查询，可以加上nolock，这样读的时候可以允许写，但缺点是可能读到未提交的脏数据。使用nolock有3条原则。 (1) 查询的结果用于“插、删、改”的不能加nolock ！ (2) 查询的表属于频繁发生页分裂的，慎用nolock ！ (3) 使用临时表一样可以保存“数据前影”，起到类似oracle的undo表空间的功能， 能采用临时表提高并发性能的，不要用nolock 。 9、 聚集索引没有建在表的顺序字段上，该表容易发生页分裂 比如订单表，有订单编号orderid，也有客户编号contactid，那么聚集索引应该加在哪个字段上呢？对于该表，订单编号是顺序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，这样不容易经常产生页分裂。然而，由于大多数查询都是根据客户编号来查的，因此，将聚集索引加在contactid上才有意义。而contactid对于订单表而言，并非顺序字段。 比如“张三”的“contactid”是001，那么“张三”的订单信息必须都放在这张表的第一个数据页上，如果今天“张三”新下了一个订单，那该订单信息不能放在表的最后一页，而是第一页！如果第一页放满了呢？很抱歉，该表所有数据都要往后移动为这条记录腾地方。 SQL Server的索引和Oracle的索引是不同的，SQL Server的聚集索引实际上是对表按照聚集索引字段的顺序进行了排序，相当于oracle的索引组织表。SQL Server的聚集索引就是表本身的一种组织形式，所以它的效率是非常高的。也正因为此，插入一条记录，它的位置不是随便放的，而是要按照顺序放在该放的数据页，如果那个数据页没有空间了，就引起了页分裂。所以很显然，聚集索引没有建在表的顺序字段上，该表容易发生页分裂。 曾经碰到过一个情况，一位哥们的某张表重建索引后，插入的效率大幅下降了。估计情况大概是这样的。该表的聚集索引可能没有建在表的顺序字段上，该表经常被归档，所以该表的数据是以一种稀疏状态存在的。比如张三下过20张订单，而最近3个月的订单只有5张，归档策略是保留3个月数据，那么张三过去的15张订单已经被归档，留下15个空位，可以在insert发生时重新被利用。在这种情况下由于有空位可以利用，就不会发生页分裂。但是查询性能会比较低，因为查询时必须扫描那些没有数据的空位。 重建聚集索引后情况改变了，因为重建聚集索引就是把表中的数据重新排列一遍，原来的空位没有了，而页的填充率又很高，插入数据经常要发生页分裂，所以性能大幅下降。 对于聚集索引没有建在顺序字段上的表，是否要给与比较低的页填充率？是否要避免重建聚集索引？是一个值得考虑的问题！ 10、加nolock后查询经常发生页分裂的表，容易产生跳读或重复读 加nolock后可以在“插、删、改”的同时进行查询，但是由于同时发生“插、删、改”，在某些情况下，一旦该数据页满了，那么页分裂不可避免，而此时nolock的查询正在发生，比如在第100页已经读过的记录，可能会因为页分裂而分到第101页，这有可能使得nolock查询在读101页时重复读到该条数据，产生“重复读”。同理，如果在100页上的数据还没被读到就分到99页去了，那nolock查询有可能会漏过该记录，产生“跳读”。 上面提到的哥们，在加了nolock后一些操作出现报错，估计有可能因为nolock查询产生了重复读，2条相同的记录去插入别的表，当然会发生主键冲突。 11、使用like进行模糊查询时应注意 有的时候会需要进行一些模糊查询比如 select * from contact where username like ‘%yue%’ 关键词%yue%，由于yue前面用到了“%”，因此该查询必然走全表扫描，除非必要，否则不要在关键词前加%， 12、数据类型的隐式转换对查询效率的影响 sql server2000的数据库，我们的程序在提交sql语句的时候，没有使用强类型提交这个字段的值，由sql server 2000自动转换数据类型，会导致传入的参数与主键字段类型不一致，这个时候sql server 2000可能就会使用全表扫描。Sql2005上没有发现这种问题，但是还是应该注意一下。 13、SQL Server 表连接的三种方式 (1) Merge Join (2) Nested Loop Join (3) Hash Join SQL Server 2000只有一种join方式——Nested Loop Join，如果A结果集较小，那就默认作为外表，A中每条记录都要去B中扫描一遍，实际扫过的行数相当于A结果集行数x B结果集行数。所以如果两个结果集都很大，那Join的结果很糟糕。 SQL Server 2005新增了Merge Join，如果A表和B表的连接字段正好是聚集索引所在字段，那么表的顺序已经排好，只要两边拼上去就行了，这种join的开销相当于A表的结果集行数加上B表的结果集行数，一个是加，一个是乘，可见merge join 的效果要比Nested Loop Join好多了。 如果连接的字段上没有索引，那SQL2000的效率是相当低的，而SQL2005提供了Hash join，相当于临时给A，B表的结果集加上索引，因此SQL2005的效率比SQL2000有很大提高，我认为，这是一个重要的原因。 总结一下，在表连接时要注意以下几点： (1) 连接字段尽量选择聚集索引所在的字段 (2) 仔细考虑where条件，尽量减小A、B表的结果集 (3) 如果很多join的连接字段都缺少索引，而你还在用SQL Server 2000，赶紧升级吧。 原文链接：http://www.cnblogs.com/shuzhengyi/archive/2011/02/12/1952481.html
View Details最近看到一个SQL Server的小例子，发现完全可以作为SQL server的一道入门面试题。题目如下： 例：有一合同表Contract Id Name Total buget 1 合同名称 100 102,22 2 合同名称2 300 ,102,22, 3 合同名称3 200 103,23, 要求:用SQL语句更新表的buget字段，如果前后没有”,”要加上”,”（即一个英文逗号）。（10分） 创建表数据： View Code use Testdb2 go IF NOT OBJECT_ID(‘[Contract]‘) ISNULL DROPTABLE [Contract] GO Createtable [Contract] (ID intprimarykey identity(1,1) ,[Name] nvarchar(50) null ,Total floatnull ,buget Nvarchar(500) null ) go insertinto [Contract] select‘合同名称’, 100,’102,22′ unionall select‘合同名称2′, 300,‘,102,22,’ unionall select‘合同名称3′, 300,’101,23,’ 分析：这道题乍看很简单，由于肯定用到Replace，所以很自然的结合left,right,从而得到以下语句 方法一： update [Contract] set buget=‘,’+buget whereleft(buget,1)=‘,’ update [Contract] set buget=buget+‘,’whereright(buget,1)=‘,’ 如果能写成一个 SQL语句，可以加1分。 update [Contract] set buget=(casewhen (left(buget,1)!=‘,’andright (buget,1)!=‘,’) then‘,’+buget+‘,’ whenleft(buget,1)!=‘,’then‘,’+buget whenright(buget,1)!=‘,’then buget+‘,’ else buget end) 如果能从字符串的开关和结尾这个思路出发，结合Reverse，可以提到如下方法： 方法二： update [Contract] set buget=‘,’+buget where charindex(‘,’,buget)<>1 update [Contract] set buget=buget+‘,’where charindex(‘,’,reverse(buget))<>1 该方法，主要涉及charindex函数和reverse函数。 说实话，我当时就这两种思路，这也是SQL中常见的基本用法。但出人意料的第三种方法出现了。 方法三： UPDATE [contract] SET Buget = ‘,’+Buget+‘,’ UPDATE [contract] SET Buget = REPLACE(Buget,‘,,’,‘,’) 解析：该方法最主要的亮点不在于语法的精妙，而在于其思路的异于常规。先给两边补上逗号，再替换双逗号为单逗号。这在实际编程中确实难能可贵。换句话说，如果没有事先思考过的话，这反映了解题者反应敏捷，思路开放。因此，至少可以再加3分。 当然，此语句其实还是有bug,比如如果原bug字段中间有两个逗号，那么在Replace时就会更新掉不应该更新的内容。不过，稍加修正，限定replace的范围即可， 受此思路启发，可以引申得到以下类似方法： 方法四： UPDATE [contract] SET Buget = substring(BuGet,2,len(BuGet)-1) wherecharindex(‘,’,buget)=1 UPDATE [contract] SET Buget = substring(BuGet,1,len(BuGet)-1) wherecharindex(‘,’,reverse(buget))=1 UPDATE [contract] SET BuGet = ‘,’+BuGet+‘,’ 该方法是先去掉两边的逗号，再给每条记录加上逗号，比起方法三来，稍显繁琐，这也反衬了方法三的巧妙。 当然，也可以结合前面的思路稍作修正，这里就不再赘述，请读者自己思考。 感悟：释迦牟尼说过“人生需要经过六项修炼：布施、持戒、忍辱、精进、禅定、智慧。”，SQL编程，或C#、Java，甚至Javascrip的某个领域也是如此。技术是死的，思路是鲜活的，有时候，思路能轻易地突破技术很难实现的死角。到了一定程度时，会发现潜意识里已经被惯性思维塞满，而无法接受新鲜思维方式或思路，如果一段时间内持续如此，那么，我们应该警醒，把自己的头脑放空，把自己置于一个初学者的地位，重新开始“精进”的修炼！ 原文链接：http://www.cnblogs.com/downmoon/archive/2011/03/02/1968615.html
View Details启动SQL Server 2008 Management Studio 工具菜单—-选项—-Designers(设计器)—-阻止保存要求重新创建表的更改 取消勾选即可。 转自：http://www.cnblogs.com/EasyLive2006/archive/2009/01/13/1375182.html
View Details解决CPU100%的情况，首先需排除病毒的情况1、收缩数据库( 日志文件）2、重建索引3、数据库硬盘所在区域 db服务器性价比比较好的方式是搭建raid5 追求性能的话是raid0 使用perfmon观察disk queue，看是否一直高于1，如果长时间高于1说明磁盘性能有问题,意味着磁盘操作需要排队完成。考虑升级存储设备加入“Page Life Expectancy”如果这个值始终小于300秒，意味着你需要更大的内存（在Sql Server: Buffer Manager里）加入“Buffer Cache hit ratio” 如果这个值小于90%，意味着你需要更大的内存.（在Sql Server: Buffer Manager里） 4、数据库锁检查use master go declare @spid int,@bl int DECLARE s_cur CURSOR FOR select 0 ,blocked from (select * from sysprocesses where blocked>0 ) a where not exists(select * from (select * from sysprocesses where blocked>0 ) b where a.blocked=spid) union select spid,blocked from sysprocesses where blocked>0 OPEN s_cur FETCH NEXT FROM s_cur INTO @spid,@bl WHILE @@FETCH_STATUS = 0 begin if @spid =0 select ' 引起数据库死锁的是 : '+ CAST(@bl AS […]
View Details重建索引的方法：ALTER INDEX ALL ON daji_zhaozu REORGANIZE sp_who active --看看哪个引起的阻塞, blksp_lock --看看锁住了那个资源id, objid , select object_name(objid) 得到dbcc inputbuffer(@blk) — 看看是那个语句 —————————————————————————- 优化sqlserver的配置.sql %%******************************************************************************************************/go exec sp_configure "awe enabled","1"--内存可以支持64gexec sp_configure "lightweight pooling","0"--不使用nt纤程exec sp_configure "priority boost","1"--增加sqlserver优先级exec sp_configure "network packet size (b)","8192"--增加sqlserver网络包的大小 reconfigure with override go --优化数据库设置declare @currentdatabase sysnameselect @currentdatabase = db_name((select dbid from master.dbo.sysprocesses where spid = @@spid))exec sp_dboption @currentdatabase, 'select into/bulkcopy', 'true' --对大容量数据操作不记录日志exec sp_dboption @currentdatabase, 'trunc. log on chkpt.', 'true' --自动截断日志exec sp_dboption @currentdatabase, 'auto create statistics', 'true'--自动创建统计exec sp_dboption @currentdatabase, 'auto update statistics', 'true'--自动更新统 查看SQL版本号： 看SP补丁打全了没。 1、收缩数据库( 日志文件）2、重建索引3、数据库硬盘所在区域 db服务器性价比比较好的方式是搭建raid5 追求性能的话是raid0 […]
View DetailsCPU占用率高的原因 CPU占用率高是对物理硬盘的查询次数多；内存使用率高是物理磁盘—虚拟内存—内存三种之间数据交换次数多。 防杀毒软件造成故障或病毒、木马造成，特别是蠕虫病毒在系统内部或网络内部迅速复制，造成CPU占用资源率居高不下； 驱动没有经过认证或某些软件与系统不兼容，造成CPU资源占用100%； 服务器硬件问题：磁盘、内存/虚拟内存等等； 网络问题：网络带宽被大量占用，造成可用带宽较少，从而影响速度； 数据库设计的问题：触发器造成死锁、作业多且频繁、中间表的大量使用、游标的大量使用、索引的设计不合理、事务操作频繁； SQL语句设计不合理，造成查询效率低下、影响服务器性能的发挥； 二 CPU占用率高解决方法 针对上述原因及可能，有以下处理： 杀毒软件升级，对服务器系统和所在的局域网进行全面、严格的杀毒； 对服务器上已经安装的软件进行考证、整理，不装没有认证的驱动、尽量装兼容性强的必需软件、去掉不必需的软件；对服务器系统、端口进行监控，定时清理系统垃圾文件、关闭不使用和高危险端口； 定期周期性检查服务器硬件问题、整理系统磁盘，使服务器性能得到最大程度发挥；制定《电脑使用规范》，规范中明确使用范围和禁止范围，并依据规范定期查询各个部门的电脑使用情况；对网络结构、交换机定期检查、维护和调整；升级硬件； 使用sql server自带的性能分析追踪工具sql profiler分析数据库设计所产生问题的来源，进行有针对性处理； 使用sql server自带的查询性能分析工具sql query analyzer对可能影响性能且使用频繁的查询语句进行优化； 或升级sql server；重装sql server或服务器操作系统；使用cpu降温软件等辅助软件。 如果这些还解决不了问题的话，那就比较麻烦，需要专业人士对网站进行整体优化，更改错误不合理的程序，优化后cpu占用能降至百分之十左右 from url:http://www.e-digitalwave.com/faqview.asp?id=140
View Details郁闷，过年放假回来第二天，公司服务器scsi硬盘放屁啦，幸好数据库和图片昨天都备过份，但恢复的东东也让我头疼啊iis,sqlserver,生成100w的静态页，静态页我没备，55555555555 现上北京买个块硬盘来,原来系统是windows2000，手到也没有2000啦，从网上当了个win2003就装上啦，本以为会好用点，结果出了 很多小问题，我改，最头痛的问题让我遇上啦 cpu占用率100%,网站根本就打不开啦，恢复的前几天一直正常，过了10来天突然出现这个问题，把IIS站建了几个缓冲池，设置过期时间，不管用，重 建索引不用，sqlserver分给他1g多内存一开机就吃没啦，重起N便系统不管用，在网上搜了半天，也没什么实质性的解决方法，最后终于让我搜着一个 解决方法目前还管用 @echo off echo 正在清除服务器垃圾文件，请稍等…… del /f /s /q %systemdrive%/*.tmp del /f /s /q %systemdrive%/*._mp del /f /s /q %systemdrive%/*.log del /f /s /q %systemdrive%/*.gid del /f /s /q %systemdrive%/*.chk del /f /s /q %systemdrive%/*.old del /f /s /q %systemdrive%/recycled/*.* del /f /s /q %windir%/*.bak del /f /s /q %windir%/prefetch/*.* rd /s /q %windir%/temp & md %windir%/temp del /f /q %userprofile%/cookies/*.* del /f /q %userprofile%/recent/*.* del /f /s /q "%userprofile%/Local Settings/Temporary Internet Files/*.*" del /f /s /q "%userprofile%/Local Settings/Temp/*.*" del /f […]
View Details