SQL删除数据库中的所有数据

Sql Server中清空所有数据表中的记录

清空所有数据表中的记录：

复制代码 代码如下:

exec sp_msforeachtable @Command1 ='truncate table ?'

删除所有数据表：

复制代码 代码如下:

exec sp_msforeachtable 'delete N''?'''

清空SQL Server数据库中所有表数据的方法（有约束的情况）

其实删除数据库中数据的方法并不复杂，为什么我还要多此一举呢，一是我这里介绍的是删除数据库的所有数据，因为数据之间可能形成相互约束关系，删除 *** 作可能陷入死循环，二是这里使用了微软未正式公开的sp_MSForEachTable存储过程。

也许很多读者朋友都经历过这样的事情：要在开发数据库基础上清理一个空库，但由于对数据库结构缺乏整体了解，在删除一个表的记录时，删除不了，因为可能有外键约束，一个常见的数据库结构是一个主表，一个子表，这种情况下一般都得先删除子表记录，再删除主表记录。

说道删除数据记录，往往马上会想到的是delete和truncate语句，但在遇到在两个或多个表之间存在约束的话，这两个语句可能都会失效，而且最要命的是这两个命令都只能一次 *** 作一个表。那么真正遇到要删除SQL Server数据库中所有记录时，该怎么办呢?有两个选择：

1.按照先后顺序逐个删除，这个方法在表非常多的情况下显得很不现实，即便是表数量不多，但约束比较多时，你还是要花费大量的时间和精力去研究其间的约束关系，然后找出先删哪个表，再删哪个表，最后又删哪个表。

2.禁用所有约束，删除所有数据，最后再启用约束，这样就不用花时间和精力去研究什么约束了，只需要编写一个简单的存储过程就可以自动完成这个任务。

复制代码 代码如下:

CREATE PROCEDURE sp_DeleteAllData

AS

EXEC sp_MSForEachTable 'ALTER TABLE ? NOCHECK CONSTRAINT ALL'

EXEC sp_MSForEachTable 'ALTER TABLE ? DISABLE TRIGGER ALL'

EXEC sp_MSForEachTable 'DELETE FROM ?'

EXEC sp_MSForEachTable 'ALTER TABLE ? CHECK CONSTRAINT ALL'

EXEC sp_MSForEachTable 'ALTER TABLE ? ENABLE TRIGGER ALL'

EXEC sp_MSFOREACHTABLE 'SELECT * FROM ?'

GO

从这两个选择中不难看出第二个选择是最简单有效的了，那么在使用第二个选择时，具体该怎么实施呢?

首先得编写代码循环检查所有的表，这里我推荐一个存储过程sp_MSForEachTable，因为在微软的官方文档中没有对这个存储过程有描述，很多开发人员也许都还未曾听说，所以你在互联网上搜索得到的解决办法大多很复杂，也许有的人会认为，既然没有官方文档，这个存储过程可能会不稳定，打心理上会排斥它，但事实并非如此。下面来先看一个完整的脚本：

这个脚本创建了一个命名为sp_DeleteAllData的存储过程，前面两行语句分别禁用约束和触发器，第三条语句才是真正地删除所有数据，接下里的语句分别还原约束和触发器，最后一条语句是显示每个表中的记录，当然这条语句也可以不要，我只是想确认一下是否清空了所有表而已。

你可以在任何数据库上运行这个存储过程，当然不要在生成数据库上运行，可别怪我没告诉你!不管怎样，还是先备份一下数据库，使用备份数据库还原，然后再运行该存储过程，呵呵，即使是一个大型数据库，也要不多长时间，你的数据库就成一个空库了

第三种方法：TRUNCATE TABLE

在sql server数据库中快速删除记录，清空表若要删除表中的所有行，则 TRUNCATE TABLE 语句是一种快速、无日志记录的方法。TRUNCATE TABLE 与不含有 WHERE 子句的 DELETE 语句在功能上相同。但是，TRUNCATE TABLE 速度更快，并且使用更少的系统资源和事务日志资源。

与 DELETE 语句相比，TRUNCATE TABLE 具有以下优点：

所用的事务日志空间较少。

DELETE 语句每次删除一行，并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 通过释放用于存储表数据的数据页来删除数据，并且在事务日志中只记录页释放。

使用的锁通常较少。

当使用行锁执行 DELETE 语句时，将锁定表中各行以便删除。TRUNCATE TABLE 始终锁定表和页，而不是锁定各行。

如无例外，在表中不会留有任何页。

执行 DELETE 语句后，表仍会包含空页。例如，必须至少使用一个排他 (LCK_M_X) 表锁，才能释放堆中的空表。如果执行删除 *** 作时没有使用表锁，表（堆）中将包含许多空页。对于索引，删除 *** 作会留下一些空页，尽管这些页会通过后台清除进程迅速释放。

与 DELETE 语句相同，使用 TRUNCATE TABLE 清空的表的定义与其索引和其他关联对象一起保留在数据库中。

在程序员的职业生涯中，总会遇到数据库表被锁的情况，前些天就又撞见一次。由于业务突发需求，各个部门都在批量 *** 作、导出数据，而数据库又未做读写分离，结果就是：数据库的某张表被锁了！

用户反馈系统部分功能无法使用，紧急排查，定位是数据库表被锁，然后进行紧急处理。这篇文章给大家讲讲遇到类似紧急状况的排查及解决过程，建议点赞收藏，以备不时之需。

用户反馈某功能页面报502错误，于是第一时间看服务是否正常，数据库是否正常。在控制台看到数据库CPU飙升，堆积大量未提交事务，部分事务已经阻塞了很长时间，基本定位是数据库层出现问题了。

查看阻塞事务列表，发现其中有锁表现象，本想利用控制台直接结束掉阻塞的事务，但控制台账号权限有限，于是通过客户端登录对应账号将锁表事务kill掉，才避免了情况恶化。

下面就聊聊，如果当突然面对类似的情况，我们该如何紧急响应？

想象一个场景，当然也是软件工程师职业生涯中会遇到的一种场景：原本运行正常的程序，某一天突然数据库的表被锁了，业务无法正常运转，那么我们该如何快速定位是哪个事务锁了表，如何结束对应的事物？

首先最简单粗暴的方式就是：重启MySQL。对的，网管解决问题的神器——“重启”。至于后果如何，你能不能跑了，要你自己三思而后行了！

重启是可以解决表被锁的问题的，但针对线上业务很显然不太具有可行性。

下面来看看不用跑路的解决方案：

遇到数据库阻塞问题，首先要查询一下表是否在使用。

如果查询结果为空，那么说明表没在使用，说明不是锁表的问题。

如果查询结果不为空，比如出现如下结果：

则说明表（test）正在被使用，此时需要进一步排查。

查看数据库当前的进程，看看是否有慢SQL或被阻塞的线程。

执行命令：

该命令只显示当前用户正在运行的线程，当然，如果是root用户是能看到所有的。

在上述实践中，阿里云控制台之所以能够查看到所有的线程，猜测应该使用的就是root用户，而笔者去kill的时候，无法kill掉，是因为登录的用户非root的数据库账号，无法 *** 作另外一个用户的线程。

如果情况紧急，此步骤可以跳过，主要用来查看核对：

如果情况紧急，此步骤可以跳过，主要用来查看核对：

看事务表INNODB_TRX中是否有正在锁定的事务线程，看看ID是否在show processlist的sleep线程中。如果在，说明这个sleep的线程事务一直没有commit或者rollback，而是卡住了，需要手动kill掉。

搜索的结果中，如果在事务表发现了很多任务，最好都kill掉。

执行kill命令：

对应的线程都执行完kill命令之后，后续事务便可正常处理。

针对紧急情况，通常也会直接 *** 作第一、第二、第六步。

这里再补充一些MySQL锁相关的知识点：数据库锁设计的初衷是处理并发问题，作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则，而锁就是用来实现这些访问规则的重要数据结构。

根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。MySQL中表级别的锁有两种：一种是表锁，一种是元数据锁（metadata lock，MDL)。

表锁是在Server层实现的，ALTER TABLE之类的语句会使用表锁，忽略存储引擎的锁机制。表锁通过lock tables… read/write来实现，而对于InnoDB来说，一般会采用行级锁。毕竟锁住整张表影响范围太大了。

另外一个表级锁是MDL（metadata lock），用于并发情况下维护数据的一致性，保证读写的正确性，不需要显式的使用，在访问一张表时会被自动加上。

常见的一种锁表场景就是有事务 *** 作处于：Waiting for table metadata lock状态。

MySQL在进行alter table等DDL *** 作时，有时会出现Waiting for table metadata lock的等待场景。

一旦alter table TableA的 *** 作停滞在Waiting for table metadata lock状态，后续对该表的任何 *** 作（包括读）都无法进行，因为它们也会在Opening tables的阶段进入到Waiting for table metadata lock的锁等待队列。如果核心表出现了锁等待队列，就会造成灾难性的后果。

通过show processlist可以看到表上有正在进行的 *** 作（包括读），此时alter table语句无法获取到metadata 独占锁，会进行等待。

通过show processlist看不到表上有任何 *** 作，但实际上存在有未提交的事务，可以在information_schema.innodb_trx中查看到。在事务没有完成之前，表上的锁不会释放，alter table同样获取不到metadata的独占锁。

处理方法：通过 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然后kill掉，让其回滚。

通过show processlist看不到表上有任何 *** 作，在information_schema.innodb_trx中也没有任何进行中的事务。很可能是因为在一个显式的事务中，对表进行了一个失败的 *** 作（比如查询了一个不存在的字段），这时事务没有开始，但是失败语句获取到的锁依然有效，没有释放。从performance_schema.events_statements_current表中可以查到失败的语句。

处理方法：通过performance_schema.events_statements_current找到其sid，kill 掉该session，也可以kill掉DDL所在的session。

总之，alter table的语句是很危险的（核心是未提交事务或者长事务导致的），在 *** 作之前要确认对要 *** 作的表没有任何进行中的 *** 作、没有未提交事务、也没有显式事务中的报错语句。

如果有alter table的维护任务，在无人监管的时候运行，最好通过lock_wait_timeout设置好超时时间，避免长时间的metedata锁等待。

关于MySQL的锁表其实还有很多其他场景，我们在实践的过程中尽量避免锁表情况的发生，当然这需要一定经验的支撑。但更重要的是，如果发现锁表我们要能够快速的响应，快速的解决问题，避免影响正常业务，避免情况进一步恶化。所以，本文中的解决思路大家一定要收藏或记忆一下，做到有备无患，避免突然状况下抓瞎。

一些ORACLE中的进程被杀掉后，状态被置为"killed"，但是锁定的资源很长时间不释放，有时实在没办法，只好重启数据库。现在提供一种方法解决这种问题，那就是在ORACLE中杀不掉的，在OS一级再杀。

1.下面的语句用来查询哪些对象被锁：

select object_name,machine,s.sid,s.serial#

from v$locked_object l,dba_objects o ,v$session s

where l.object_id　=　o.object_id and l.session_id=s.sid

2.下面的语句用来杀死一个进程：

alter system kill session '24,111'(其中24,111分别是上面查询出的sid,serial#)

【注】以上两步，可以通过Oracle的管理控制台来执行。

3.如果利用上面的命令杀死一个进程后，进程状态被置为"killed"，但是锁定的资源很长时间没有被释放，那么可以在os一级再杀死相应的进程（线程），首先执行下面的语句获得进程（线程）号：

select spid, osuser, s.program

from v$session s,v$process p

where s.paddr=p.addr and s.sid=24 （24是上面的sid）

4.在OS上杀死这个进程（线程）：

1)在unix上，用root身份执行命令:

#kill -9 12345（即第3步查询出的spid）

2)在windows（unix也适用）用orakill杀死线程，orakill是oracle提供的一个可执行命令，语法为：

orakill sid thread

其中：

sid：表示要杀死的进程属于的实例名

thread：是要杀掉的线程号，即第3步查询出的spid。

例：c:>orakill orcl 12345

---