新来个技术总监:发现谁再用 delete 删数据直接开除!
源于一个读者实际工作中遇到的问题,老大一直强调线上不允许用 delete 来删除 Mysql 数据库的数据(有一次发飚了,说如果再发现谁这样操作直接开除)。为什么 MySQL 不建议使用 delete 删除数据呢?
这就得从以下几方面说起!!!
MySQL 是一种关系型数据库管理系统,它的数据存储是基于磁盘上的文件系统实现的。MySQL 将数据存储在表中,每个表由一系列的行和列组成。每一行表示一个记录,每一列表示一个字段。表的结构由其列名、数据类型、索引等信息组成。
MySQL 的数据存储采用了多种技术来优化性能和存储效率。以下是 MySQL 数据存储的一些关键特性。
存储引擎
MySQL 支持多种不同的存储引擎,每种引擎都有不同的性能和存储特性。常见的存储引擎有 InnoDB、MyISAM、Memory 等。不同的存储引擎支持不同的数据存储方式,如 B 树索引、哈希索引、全文索引等。
数据页
MySQL 使用数据页来管理存储在磁盘上的数据。数据页是 MySQL 存储引擎中最基本的存储单元,通常情况下每个数据页的大小为 16KB。数据页包含多个记录,每个记录对应一行数据。
索引
MySQL 使用索引来优化数据的检索效率。索引是一种特殊的数据结构,它能够快速地查找表中的数据。MySQL 支持多种类型的索引,如 B 树索引、哈希索引、全文索引等。B 树索引是 MySQL 中最常用的索引类型,它能够快速地查找表中的数据。
事务
MySQL 支持事务,事务可以保证数据的一致性、可靠性和安全性。MySQL 的事务是基于 ACID 模型实现的,它能够确保数据在事务中的操作要么全部成功,要么全部回滚。事务的支持使得 MySQL 在多用户并发访问时能够保证数据的完整性和一致性。
总之,MySQL 的数据存储基于磁盘上的文件系统实现,采用多种技术来优化性能和存储效率,如存储引擎、数据页、索引、事务等。这些特性使得 MySQL 成为一种高性能、可靠和安全的关系型数据库管理系统。
MySQL 删除数据的方式都有哪些?
咱们常用的三种删除方式:通过 delete、truncate、drop 关键字进行删除;这三种都可以用来删除数据,但场景不同。
执行速度:drop > truncate >> DELETE
从原理上理解
DELETE
DELETE 属于数据库 DML 操作语言,只删除数据不删除表的结构,会走事务,执行时会触发 trigger;
在 InnoDB 中,DELETE 其实并不会真的把数据删除,mysql 实际上只是给删除的数据打了个标记为已删除,因此 delete 删除表中的数据时,表文件在磁盘上所占空间不会变小,存储空间不会被释放,只是把删除的数据行设置为不可见。**虽然未释放磁盘空间,但是下次插入数据的时候,仍然可以重用这部分空间(重用 → 覆盖)。
DELETE 执行时,会先将所删除数据缓存到 rollback segement 中,事务 commit 之后生效;
delete from table_name 删除表的全部数据,对于 MyISAM 会立刻释放磁盘空间,InnoDB 不会释放磁盘空间;
对于 delete from table_name where xxx 带条件的删除, 不管是 InnoDB 还是 MyISAM 都不会释放磁盘空间;
delete 操作以后使用 optimize table table_name 会立刻释放磁盘空间。不管是 InnoDB 还是 MyISAM 。所以要想达到释放磁盘空间的目的,delete 以后执行 optimize table 操作。
示例:查看表占用硬盘空间大小的 SQL 语句如下:(用 M 做展示单位,数据库名:csjdemo,表名:demo2)
然后执行空间优化语句,以及执行后的表 Size 变化:
再看看这张表的大小,就只剩下表结构 size 了。
delete 操作是一行一行执行删除的,并且同时将该行的的删除操作日志记录在 redo 和 undo 表空间中以便进行回滚(rollback)和重做操作,生成的大量日志也会占用磁盘空间。
drop
属于数据库 DDL 定义语言,同 Truncate,执行后立即生效,无法找回。
drop table table_name 立刻释放磁盘空间 ,不管是 InnoDB 和 MyISAM; drop 语句将删除表的结构被依赖的约束(constrain)、触发器(trigger)、索引(index); 依赖于该表的存储过程/函数将保留,但是变为 invalid 状态。
小心使用 drop ,要删表跑路的兄弟,请在订票成功后在执行操作!
可以这么理解,一本书,delete 是把目录撕了,truncate 是把书的内容撕下来烧了,drop 是把书烧了
truncate
属于数据库 DDL 定义语言,不走事务,原数据不放到 rollback segment 中,操作不触发 trigger。执行后立即生效,无法找回!
truncate table table_name 立刻释放磁盘空间 ,不管是 InnoDB 和 MyISAM 。truncate table 其实有点类似于 drop table 然后 creat,只不过这个 create table 的过程做了优化,比如表结构文件之前已经有了等等。所以速度上应该是接近 drop table 的速度;
truncate 能够快速清空一个表。并且重置 auto_increment 的值。
但对于不同的类型存储引擎需要注意的地方是:
对于 MyISAM,truncate 会重置 auto_increment(自增序列)的值为 1。而 delete 后表仍然保持 auto_increment。
对于 InnoDB,truncate 会重置 auto_increment 的值为 1。delete 后表仍然保持 auto_increment。但是在做 delete 整个表之后重启 MySQL 的话,则重启后的 auto_increment 会被置为 1。
也就是说,InnoDB 的表本身是无法持久保存 auto_increment。delete 表之后 auto_increment 仍然保存在内存,但是重启后就丢失了,只能从 1 开始。实质上重启后的 auto_increment 会从 SELECT 1+MAX(ai_col) FROM t 开始。
小心使用 truncate,尤其没有备份的时候,如果误删除线上的表,记得及时跑路。
为什么不建议使用 DELETE 删除数据
了解上面的一些原理之后,可以知道!
无法恢复数据
在使用 DELETE 操作删除数据时,如果没有事先备份数据,一旦误操作就会导致数据无法恢复。因此,在进行任何数据操作之前,最好先备份数据,以便在出现错误时可以轻松地恢复数据。
删除数据会导致索引失效,影响查询性能。
删除数据会导致表空间的浪费,因为删除的数据并不会立即释放,而是留在表中,只是被标记为“已删除”。
数据不一致
如果在删除数据时表中存在外键关联,使用 DELETE 操作可能会导致其他表中的数据不一致。例如,如果一个表有一个外键,指向另一个表中的一行,如果从主表中删除行而不更新外键引用,则外键引用将成为无效引用。这可能会导致查询时出现错误,或者在更新时导致数据不一致。
总结
在工作当中执行数据库删除的时候一定要慎重再慎重,建议每次进行数据删除的使用最好数据表的备份工作,这样就会大大减少你删除跑路的几率。很多时候不要过于相信自己的动手能力,老虎还有打盹的时候,万一手滑了呢。尽可能养成好的数据库运维习惯,这样会让自己少跌跟头,你的事业才会更加顺利。
评论