数据库删除表中数据
数据库删除表中数据，如果直接清空数据，id自增长的话，再添加的数据会从清除之前的id继续自增长，想要删除数据，id 自增长仍然从1开始，如下操作：
show create TABLE Analysis.ORDER_SUMM

执行以上语句结果如下：



其实就是表结构 全选后是这样的：
CREATE TABLE `order_detail` (
  `ID` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',
  `SOURCE_ID` varchar(255) DEFAULT NULL COMMENT '源数据来源',
  `ACCOUNT_ID` varchar(255) DEFAULT NULL COMMENT '账户ID',
  `ORDER_ID` varchar(255) DEFAULT NULL COMMENT '订单ID',
  `DATE` datetime DEFAULT NULL COMMENT '日期',
  `CUSTOMER_ID` varchar(255) DEFAULT NULL COMMENT '顾客',
  `POS_ID` varchar(32) DEFAULT NULL COMMENT '网点',
  `DEVICE_ID` varchar(32) DEFAULT NULL COMMENT '设备',
  `GOODS_ID` varchar(32) DEFAULT NULL COMMENT '产品',
  `PRICE` decimal(10,2) DEFAULT NULL COMMENT '单价',
  `COUNT` int(11) DEFAULT NULL COMMENT '订单本种商品数量',
  `PAYMENT` varchar(255) DEFAULT NULL COMMENT '支付方式',
  `STATE` int(11) DEFAULT NULL COMMENT '订单状态，1-完成，2-未完成',
  `SYNC_TIME` datetime DEFAULT NULL COMMENT '同步时间',
  PRIMARY KEY (`ID`),
  KEY `POS` (`POS_ID`),
  KEY `DEVICE` (`DEVICE_ID`),
  KEY `PRODUCT` (`GOODS_ID`),
  KEY `CUSTOMER` (`CUSTOMER_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='订单详情表'

一般我会先drop 数据表 ，然后再create ，但是发现这样操作，对自增长的id有影响，id会从删除表之前的数据开始（跟直接清空表是一样的），我不想要这样，想要id 从1开始，于是执行下面这句话
TRUNCATE TABLE Analysis.ORDER_SUMMARY

这句话是关键  TRUNCATE TABLE用于删除表中的所有行，而不记录单个行删除操作

这样，id 就会从头开始啦  笔芯

数据库删除表中多列语法总结



Oracle:
alter table table_name drop (column1,column2);


MS SQL:
alter table table_name drop column column_name1,column_name2;


MySQL:
alter table table_name drop column_name1,drop column_name2;


PostgreSQL:
alter table table_name drop column column_name1,drop column_name2;

当数据量较大时，删除数据库中的表会很慢，可以先清空表再删除

  删除表操作对于使用者来说很简单，但是对于数据库却可能需要做一番复杂的处理，因为表中可能会有大量的数据需要处理，一些商业数据库还会考虑表被误删除需要恢复的问题。

  删除表时清理数据不可能像delete操作那样逐条去删除，通常是基于数据库的体系结构去清理的。例如基于页，块去清理，如果数据库表与文件对应，那么清理数据时可直接删除文件。

  不过，我们似乎忽略了一个问题，相应的表在内存中可能还有数据，这些信息也应当被清理。某些数据库在内存中基于表名称Hash分布数据，这样就可以通过表名称快速定位到该表在内存中的数据，那么清理动作应该会很快。不过某些开源数据库的存储方式并非这样，它在内存中可能是基于一种线性机构来存储的，此时就可能发生问题了。即使在一个数据库中删除一个“空表“，也可能会导致延迟很大。为何？请看下面解释。

  所有的数据库都存在内存命中率的问题，如果内存命中自然就不用访问效率低上百倍的磁盘了，因此对于数据库来说，我们通常会给它配置较大的内存来达到很高的命中率，例如24GB，48GB甚至更大。这意味着如果要找到一个表在内存中Cache的数据有可能需要扫描整个数据区域，在某些时候还不止扫描一个，例如MySQL的InnoDB Buffer若设置非常大，那么在连续删除表时就可能会导致数据库系统性能下降，即使删除整个空表也会导致系统的延迟飙高。

  删除某些数据库的表，为了防止误删除，会在默认的处理删除动作时，只是修改一个名字并将修改后的表名与原来的表名做一个简单的映射，同时也改变其元数据的状态，在默认情况下我们看不见它（就像回收站一样）。但是它依然占用磁盘空间，数据一点不少存在。这样的删除操作自然时瞬间完成的，如果发现删错表了，通过一个简单的语句就可以瞬间恢复。如果想要直接物理删除表或清空回收站，就需要数据库提供特定的操作语法来完成。