Mysql从删库到跑路
从删库到跑路 -b站视频学习笔记
数据库听课笔记——从删库到跑路（bilibili）第3讲1、显示所有数据库：show databases;2、创建数据库：create database 数据库名3、删除数据库：drop database 数据库名第4讲1、表是数据可存储数据的基本单位，一个表包含若干个字段或记录。
2、创建表的语法：create table 表名（属性名数据类型[完整性约束条件],属性名数据类型[完整性约束条件],…）；3、完整性约束条件：primary key 主键；foreign key 外键；not null 该属性不能为空；unique 该属性值唯一；auto_increment 该属性的值自动增加；default 为该属性设置默认值。
例子：创建图书类别表mysql> use db_book;Database changedmysql> CREATE TABLE t_bookType(-> id int primary key auto_increment,-> bookTypeName varchar(20),-> bookTypeDesc varchar(200)-> );创建图书表：CREATE TABLE t_book(-> Id int primary key auto_increment,-> bookName varchar(20),-> price decimal(6,2),-> bookTypeId int,-> constraint `fk` foreign key (`bookTypeId`) references `t_bookType`(`id`)-> );4、查看表结构（1）查看基本表结构DESCRIBE(DESC) 表名；（2）查看表详细结构SHOW CREATE TABLE 表名。
5、修改表（1）修改表名ALTER TABLE 旧表名RENAME 新表名；（2）修改字段ALTER TABLE 表名CHANGE 旧属性名新属性名新数据类型；（3）增加字段ALTER TABEL 表名ADD 属性名1 数据类型[完整性约束条件][FIRST|AFTER 属性名2]；（4）删除字段ALTER TABLE 表名DROP 属性名；6、删除表的语法：DROP TABLE 表名；第5讲查询数据（单表查询）1、查询所有字段（1）SELECT 字段1，字段2，字段3… FROM 表名；（2）SELECT * FROM 表名；2、查询指定字段：SELECT 字段1，字段2，字段3… FROM 表名；3、where条件查询：SELECT 字段1，字段2，字段3…FROM 表名WHERE 条件表达式；4、带IN关键字查询：SELECT 字段1，字段2…FROM 表名WHERE 字段[NOT] IN （元素1，元素2，元素3）；5、带BETWEEN AND 的范围查询：SELECT 字段1，字段2…FROM 表名WHERE 字段[NOT] BETWEEN 取值1 AND 取值2；6、带LIKE的模糊查询：SELECT 字段1，字段2，字段3… FROM 表名WHERE 字段IS [NOT] LIKE `字符串`；其中“%”代表任意字符，“_”代表单个字符。
预防删库跑路的方法
预防删库跑路的方法随着互联网的发展，越来越多的网站和应用程序存储着大量的用户数据。
然而，有时候开发者或网站运营者会出现删库跑路的情况，导致用户的数据丢失或泄露，给用户带来极大的损失和不便。
为了保障用户的权益，我们需要采取一些预防措施来避免删库跑路事件的发生。
1. 数据备份数据备份是防止删库跑路的关键措施之一。
开发者或网站运营者应该定期备份用户数据，并将备份数据保存在安全可靠的地方，如云存储或离线存储设备中。
同时，备份数据的访问权限也要进行合理的控制，只有授权人员才能访问备份数据，以防止数据泄露。
2. 数据冗余为了避免因为硬件故障或自然灾害等原因导致数据丢失，开发者或网站运营者可以采用数据冗余的方式来保障数据的安全性。
数据冗余是指将数据存储在多个地点或多个设备上，以确保即使某个地点或设备发生故障，数据仍然可以恢复。
这样一来，即使出现删库跑路的情况，用户的数据也能得到保护。
3. 访问权限控制为了防止非授权人员恶意篡改或删除用户数据，开发者或网站运营者应该对数据的访问权限进行严格的控制。
只有经过授权的人员才能访问、修改或删除用户数据。
同时，对于敏感数据，可以采用加密的方式来存储，提高数据的安全性。
4. 审核机制建立健全的审核机制是预防删库跑路的重要手段之一。
开发者或网站运营者应该对用户数据的操作行为进行监控和审计，及时发现异常操作或风险行为，并采取相应的措施进行处理。
例如，当发现有人大量删除用户数据时，可以立即进行报警并暂停该账号的操作权限，以保护用户的数据安全。
5. 法律法规合规开发者或网站运营者在收集、存储和使用用户数据时，必须遵守相关的法律法规，确保用户数据的合法性和安全性。
例如，应该事先告知用户数据的收集目的和使用方式，并获得用户的同意。
同时，还应该建立健全的数据保护制度，加强对用户数据的保护和管理。
6. 社会监督和舆论监管社会监督和舆论监管是预防删库跑路的重要手段之一。
开发者或网站运营者应该建立良好的声誉，并及时回应用户的反馈和投诉。
MySQL的增删改查操作详解
MySQL的增删改查操作详解MySQL是一种常用的关系型数据库管理系统，广泛应用于各种规模的应用程序中。
在开发和管理数据库时，最常用的操作就是增删改查（CRUD）操作。
本文将详细介绍MySQL中的增删改查操作，包括其语法和用法。
一、增加数据（Insert）在MySQL中，插入数据可通过INSERT INTO语句来实现。
INSERT INTO语句的基本语法如下：```sqlINSERT INTO table_name (column1, column2, ...)VALUES (value1, value2, ...);```其中，table_name为要插入数据的表名，column1、column2为要插入数据的列名，value1、value2为要插入的具体数值。
实际应用中，我们可以插入一行或多行数据。
例如，要向名为"users"的表中插入一行数据，列名为"name"和"age"，具体数值为"John Doe"和"25"，可以采用以下语句：```sqlINSERT INTO users (name, age)VALUES ('John Doe', 25);```如果要插入多行数据，只需像插入一行数据那样写多个INSERT INTO语句即可。
二、删除数据（Delete）在MySQL中，删除数据可通过DELETE FROM语句来实现。
DELETE FROM 语句的基本语法如下：```sqlDELETE FROM table_nameWHERE condition;```其中，table_name为要删除数据的表名，condition为要删除数据的条件。
例如，要从名为"users"的表中删除所有年龄小于等于30的数据，可以采用以下语句：```sqlDELETE FROM usersWHERE age <= 30;```如果不指定任何条件，则会删除该表中所有数据。
MySQL数据库的更新与删除操作
MySQL数据库的更新与删除操作随着互联网和大数据的快速发展，数据库成为了许多公司和机构的核心应用之一。
MySQL作为一种开源的关系型数据库管理系统，具有成熟稳定、性能强劲以及易于使用的特点，被广泛地应用于各种应用场景中。
在MySQL数据库中，更新和删除操作是常见的数据操作方式，本文将从不同角度和层面，探讨MySQL数据库中的更新与删除操作，以及其相关的注意事项。
一、简介MySQL是一个开源的关系型数据库管理系统，由瑞典的MySQL AB公司开发，目前由Oracle公司维护和支持。
MySQL以其高性能、高可靠性、易于使用和灵活性而在全球范围内得到广泛应用。
在MySQL数据库中，更新和删除操作是对数据库中已存在的数据进行修改或删除操作的常见方式，可以根据具体需求进行灵活应用。
二、MySQL的更新操作在MySQL数据库中，更新操作是指对已存在的数据进行修改或更新的操作方式。
通过UPDATE语句可以实现对表中数据的修改。
UPDATE语句的一般语法如下：UPDATE table_nameSET column1 = value1, column2 = value2, ...WHERE condition;其中，table_name表示要更新的表名，column1、column2表示要更新的列名，value1、value2表示要更新的值，condition表示更新的条件。
在进行更新操作时，需要注意以下几点：1. 使用合适的WHERE条件：WHERE条件用于指定更新操作的目标数据，如果不指定WHERE条件，UPDATE语句将会更新表中的所有数据。
因此，使用合适的WHERE条件是保证更新操作精确性的关键。
2. 谨慎使用全表更新：全表更新意味着将表中的所有数据进行更新，对于大表来说，这将导致数据库性能下降以及对系统资源的浪费。
因此，在进行更新操作时，应尽量避免全表更新。
3. 编写高效的更新语句：对于复杂的更新操作，可以使用JOIN语句将多个表进行关联，从而实现更加灵活和高效的更新操作。
Mysql从删库到跑路
mysql从删库到跑路那年公司ERP系统刚进行升级因为公司陆续上了MES和PDM系统。
为了加快整个公司信息化平台的统一，请了个第三方公司来做中间接口。
然后故事开始了。
某一个晚上，第三方人员问我要ERP的SA密码。
我很警惕：“你要干嘛？”“我测试一下中间表。
”“有没有写表的操作？”“没有，只有读表的操作。
”于是我放心的给了SA密码。
给了VPN权限通道。
放她进来了。
十分钟后…..她带着哭腔打电话来（是的，对方做测试的是个93年的萌妹子。
）“吴哥哥，服务器中毒了。
”我当时还在逛果壳呢，一听她说我服务器中毒了，我表示无比淡定。
还以大哥的经验教训了一顿她。
“叫你不要往我服务器传插件嘛，这次帮你解决一下，下次不准了哟。
”我认为是小case呢，不就中毒了嘛，系统往回滚一天就好了。
然后悲剧的事情就出现了。
远程进不去。
于是我就去机房本地登录，居然也进不去。
我不死心，强制重启。
居然还是进不去。
我的服务器系统就这样崩了。
好在那几天在做开发，系统没有启用。
于是我和我的老板汇报了这个情况：“老大，我们服务器系统崩了。
”“哦，那就搞好它让它别崩。
”果然是霸道总裁啊。
当时数据和应用服务器我都是分开跑的，所以应用服务器奔溃了，我觉得也没多大事，就重新做系统吧。
于是我重新做了个系统，然后喊萌妹子上来搭平台。
“小刘啊，你可害惨我了。
一个下午给你重做服务器系统了，我基础环境都配置好了，你上来搭平台吧。
”萌妹子那是无比的歉意啊，又是答应请我吃饭又是答应请我看电影的。
我都想系统再崩溃一次了。
按理说这样应该是没问题了，就在我走出机房，在外面抽了根烟，45度仰望了一下天空，联想了一下和萌妹子点个9分熟的牛排，在喝一口二锅头这样浪漫的晚餐的时候。
电话来了。
来电话的是萌妹子的老板。
“小吴，我想找一下information.db和mfmedia.db这两个总表，没找到。
你给我找一下。
”我都蒙了，从来没人问过我这样的问题，难道她老板不是IT行业的。
MySQL中的数据删除和恢复操作
MySQL中的数据删除和恢复操作概述：MySQL是一种常见的关系型数据库管理系统，在数据处理过程中，数据的删除和恢复操作是非常重要的。
本文将探讨MySQL中的数据删除和恢复操作的相关知识点，旨在帮助读者更好地管理和维护其数据库。
数据删除：在MySQL中，数据删除是指从数据库中永久移除某个或某些记录的操作。
常见的删除操作有以下几种方式：1. DELETE语句：DELETE语句是MySQL中用于删除数据的标准语句。
通过指定表名和WHERE条件，可以删除符合条件的记录。
例如，DELETE FROM table_name WHERE condition; 可以删除表table_name中满足特定条件的记录。
2. TRUNCATE TABLE语句：TRUNCATE TABLE语句可以快速删除表中的所有数据，类似于DELETE语句删除所有记录时的效果。
它的执行速度要比DELETE语句快得多，因为它不会记录删除的每一行数据，而是直接释放表空间。
但要注意，使用TRUNCATE语句后，表的结构依然保留。
3. DROP TABLE语句：DROP TABLE语句可以删除整个表，包括表的结构和所有数据。
使用这个语句要谨慎，因为删除后无法恢复。
数据恢复：在操作数据库时，不可避免地会遇到误删数据的情况。
针对这种情况，MySQL提供了多种恢复数据的方法。
1. 使用备份文件：定期备份是保证数据安全的重要措施。
如果有备份文件，可以通过将备份文件还原到数据库中来恢复数据。
这是最常见也是最可靠的数据恢复方法之一。
通过将备份文件导入到数据库中，可以还原删除前的数据。
2. 使用事务回滚：如果在删除数据时，处于一个事务中，可以使用事务回滚来撤销对数据库的修改。
在开始事务前，使用START TRANSACTION语句，然后执行删除操作，如果发现错误，可以通过执行ROLLBACK语句来回滚到事务开始前的状态。
3. 使用日志文件：MySQL的二进制日志（binary log）记录了数据库的所有修改操作。
MySQL数据库崩溃修复案例，再也无需删库跑路！
MySQL数据库崩溃修复案例，再也⽆需删库跑路！前⾔互联⽹⾏业是个⾼危⾏业，动不动就删库跑路！⼏天前⼀朋友在测试服务器上执⾏⼀条错误的命令，导致MySQL数据库崩溃，纠结了好⼏天也没解决问题。
深⼊研究MySQL源码！从根源上找出了MySQL崩溃原因。
问题描述研究MySQL源代码，调试并压测MySQL源代码时，MySQL崩溃！问题是崩溃！⽽且还损坏了InnoDB⽂件！还好是在调试环境下发⽣的，赶紧看看如何解决这个问题，经过⼀系列的查阅资料、验证、对⽐、MySQL源码调试跟踪、修复损坏的InnoDB⽂件、总结等流程，整理成此⽂，如果以后真的发⽣在线上的⽣产坏境，也不⽤担⼼是不是要跑路的问题，可以分分钟搞定MySQL的崩溃问题！查看错误⽇志，如下：-----------------------------------------161108 23:36:45 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/var2020-05-01 23:36:46 0[Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).2020-05-01 23:36:46 5497[Note] Plugin 'FEDERATED' is disabled.2020-05-01 23:36:467f11c48e1720 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may beremoved in future releases, together with the option innodb_use_sys_malloc and with the InnoDB'sinternal memory allocator.2020-05-01 23:36:46 5497[Note] InnoDB: Using atomics to ref count buffer pool pages2020-05-01 23:36:46 5497[Note] InnoDB: The InnoDB memory heap is disabled2020-05-01 23:36:46 5497[Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins2020-05-01 23:36:46 5497[Note] InnoDB: Memory barrier is not used2020-05-01 23:36:46 5497[Note] InnoDB: Compressed tables use zlib 1.2.32020-05-01 23:36:46 5497[Note] InnoDB: Using CPU crc32 instructions2020-05-01 23:36:46 5497[Note] InnoDB: Initializing buffer pool, size = 16.0M2020-05-01 23:36:46 5497[Note] InnoDB: Completed initialization of buffer poolInnoDB: Database page corruption on disk or a failedInnoDB:file read of page 5.InnoDB: You may have to recover from a backup.2020-05-01 23:36:46 7f11c48e1720InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex7478d078000000050000000000000000000000000f271f4d000700000000000000000000000000000000001b4000000000000000000200f20000000000000006000000000000002d000000000000002e000000000000002f0000000000000030000000000（省略很多类似代码）InnoDB: End of page dump2020-05-01 23:36:46 7f11c48e1720 InnoDB: uncompressed page,stored checksum in field1 1954074744, calculated checksums for field1: crc32 993334256, innodb2046145943, none 3735928559, stored checksum in field2 1139795846, calculated checksums for field2:crc32 993334256, innodb 1606613742, none 3735928559, page LSN 0 254222157, low 4 bytes of LSN at page end 254221236, page number (if stored to page already) 5,space id (if created with >= MySQL-4.1.1and stored already) 0InnoDB: Page may be a transaction system pageInnoDB: Database page corruption on disk or a failedInnoDB: file read of page 5.InnoDB: You may haveto recover from a backup.InnoDB: Itis also possible that your operatingInnoDB: system has corrupted its own file cacheInnoDB: andrebooting your computer removes theInnoDB: error.InnoDB: If the corrupt page is an index pageInnoDB:you can also try to fix the corruptionInnoDB: by dumping, dropping, and reimportingInnoDB: thecorrupt table. You can use CHECKInnoDB: TABLE to scan your table for corruption.InnoDB: See also/doc/refman/5.6/en/forcing-innodb-recovery.htmlInnoDB: about forcingrecovery.InnoDB: Ending processing because of a corrupt database page.2020-05-01 23:36:467f11c48e1720 InnoDB: Assertion failure in thread 139714288817952 in file line 4201InnoDB: We intentionally generate a memory trap.InnoDB: Submit a detailedbug report to.InnoDB: If you get repeated assertion failures or crashes, evenInnoDB:immediately after the mysqld startup, there may beInnoDB: corruption in the InnoDB tablespace. Please refer toInnoDB: /doc/refman/5.6/en/forcing-innodb-recovery.htmlInnoDB: aboutforcing recovery.03:36:46 UTC - mysqld got signal 6 ;This could be because you hit a bug. It is also possible that this binaryor one of the libraries it was linked against is corrupt,improperlybuilt,or misconfigured. This error can also be caused by malfunctioning hardware.We will try our bestto scrape up some info that will hopefully helpdiagnose the problem, but since we have alreadycrashed,something is definitely wrong and this mayfail.key_buffer_size=16777216read_buffer_size=262144max_used_connections=0max_threads=1000thread_count=0connection_count=0It is possible that mysqld could use up tokey_buffer_size + (read_buffer_size +sort_buffer_size)*max_threads = 798063 K bytes of memoryHope that's ok; if not, decrease somevariables in the equation.Thread pointer: 0x0Attempting backtrace. You can use the followinginformation to find outwhere mysqld died. If you see no messages after this, something wentterriblywrong...stack_bottom = 0 thread_stack 0x40000/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x8e64b5]/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x41b)[0x652fbb]/lib64/libpthread.so.0(+0xf7e0)[0x7f11c44c77e0]/lib64/libc.so.6(gsignal+0x35)[0x7f11c315d625]/lib64/libc.so.6(abort+0x175)[0x7f11c315ee05]/usr/local/mysql/bin/mysqld[0xa585c5]/usr/local/mysql/bin/mysqld[0xa6c7b4]/usr/local/mysql/bin/mysqld[0xa6cbc7]/usr/local/mysql/bin/mysqld[0xa5bce2]/usr/local/mysql/bin/mysqld[0xa1e2ba]/usr/local/mysql/bin/mysqld[0xa0bf60]/usr/local/mysql/bin/mysqld[0x95a427]/usr/local/mysql/bin/ [0x58f788]/usr/local/mysql/bin/mysqld[0x6e4a36]/usr/local/mysql/bin/mysqld(_Z11plugin_initPiPPci+0xb3e)[0x6e826e]/usr/local/mysql/bin/mysqld[0x582d85]/usr/local/mysql/bin/mysqld(_Z11mysqld_mainiPPc+0x4d8)[0x587d18]/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f11c3149d5d]/usr/local/mysql/bin/mysqld[0x57a019]The manual page at/doc/mysql/en/crashing.html containsinformation that should help you find outwhat is causing the crash.161108 23:36:46 mysqld_safe mysqld from pid file/usr/local/mysql/var/VM_241_49_centos.pidended------------------------------------------------------------------------------问题分析从⽇志中可以看出是InnoDB引擎出了问题。
如何排查和解决MySQL数据丢失问题
如何排查和解决MySQL数据丢失问题MySQL是一种常用的关系型数据库管理系统，广泛应用于各类应用程序和网站。
然而，有时候我们会遇到MySQL数据丢失的问题，这可能对我们的业务产生重大影响。
本文将探讨如何排查和解决这些问题。
1. 数据丢失的原因在解决问题之前，我们首先要了解数据丢失的原因。
数据丢失可能有多种原因，包括但不限于以下几种：1.1 操作失误：人为误操作是导致数据丢失的常见原因之一。
比如，不小心执行了错误的DELETE或UPDATE语句，或者不小心删除了整个数据库。
1.2 软件问题：MySQL本身可能存在一些软件问题，导致数据丢失。
这可能包括错误的配置、版本兼容性问题、磁盘故障等。
1.3 硬件故障：硬件故障是导致数据丢失的另外一个常见原因。
例如，磁盘损坏、电源故障等都可能导致数据库无法正常工作。
2. 排查数据丢失问题在遇到数据丢失问题时，我们需要进行一系列的排查工作，以确定具体的原因和解决方案。
2.1 检查日志：MySQL的日志记录功能非常重要，通过查看日志可以了解到数据库的操作记录、错误信息等。
我们可以通过查看错误日志（error log）和慢查询日志（slow query log）来获取更多的信息。
2.2 检查备份：如果您有定期备份数据库的策略，可以尝试从备份中恢复数据。
如果备份是完整的，并且与数据丢失发生之前的时间点相对应，那么您可以通过恢复备份来解决问题。
2.3 检查数据库状态：使用MySQL的一些命令行工具，如mysqladmin或mysqldump，可以查看数据库的状态信息。
例如，使用mysqladmin命令的status选项可以提供数据库连接状态、运行时间等信息。
2.4 检查数据库配置：检查MySQL的配置文件（通常是f或my.ini）中的参数设置是否正确。
确保各项配置参数与您的应用程序的需求相匹配，避免由于配置问题导致数据丢失。
2.5 使用诊断工具：MySQL提供了一些内置的诊断工具，如mysqlcheck和mysqldump。
MySQL中的数据删除和归档方法
MySQL中的数据删除和归档方法MySQL 中的数据删除和归档方法在数据库管理中，数据删除和归档是非常重要的环节。
在使用 MySQL 数据库时，我们常常需要通过删除不再使用的数据来提升查询性能，并且，对于那些历史数据，我们也需要将其归档到一个备份或者存档表中。
本文将介绍 MySQL 中的数据删除和归档方法，帮助你更好地管理你的数据库。
一、数据删除1. 删除单条数据在 MySQL 中，我们可以使用 DELETE FROM 语句来删除单条数据。
例如，下面的语句将删除名为 "customers" 数据表中 ID 为 1 的记录：```DELETE FROM customers WHERE ID = 1;```2. 删除多条数据如果我们需要删除多条数据，可以使用 DELETE FROM 语句结合 IN 关键字。
例如，下面的语句将删除名为 "customers" 数据表中 ID 在 1、2、3 范围内的记录：```DELETE FROM customers WHERE ID IN (1, 2, 3);```3. 删除表中的全部数据如果我们需要删除表中的全部数据而不是删除整个表，可以使用 TRUNCATE TABLE 语句。
注意，这个操作是不可逆的，所有的数据都将被一次性删除。
例如，下面的语句将删除名为 "customers" 数据表中的全部数据：```TRUNCATE TABLE customers;```二、数据归档1. 归档到备份表当我们需要将历史数据归档到一个备份或存档表中时，可以通过创建一个新的表，并将数据从原始表中复制到备份表中来实现。
以下是一个示例：```CREATE TABLE customers_backup LIKE customers;INSERT INTO customers_backup SELECT * FROM customers WHERE created_at <= '2021-01-01';```在上面的示例中，我们首先通过 CREATE TABLE 语句创建了一个名为"customers_backup" 的备份表，该表的结构与原始表 "customers" 相同。
删库跑路技巧删库跑路命令
删库跑路技巧删库跑路命令1. Linux操作系统上的删库跑路# 删除根⽬录下所有⽂件，杀伤⼒极⼤，请谨慎使⽤# 此命令⼀出，Linux根⽬录下很多⽂件,可以能彻底从这个星球上彻底消失了rm -rf /*# 指定路径删除，菜⼑可以⽤来做菜亦可以⽤来s⼈rm -rf /home/fileName2. sql上的删库跑路此部分杀伤⼒就没有第⼀部分⼗⾜了，当时依然需要跑路# 删除数据库# 删除后可能会遗留⽇志，⼀些数据还是可以通过⽇志恢复的，所以索性把⽇志也⼀起删了吧drop database databasenamepurge binary logs to '⽇志名字';# 觉得还是太⿇烦，那就直接删除mysql的服务和数据吧find / -name mysql# 删除找到的关于mysql的⼀切rm -rf /var/lib/mysqlrm -rf /var/lib/mysqlrm -rf /usr/lib64/mysqlrm -rf /etc/f3. Redis缓存数据库删库跑路# 删除数据库中内容flushall# 删除指定执⾏环境下db的数据flushdb# 当然如果设置过持久化内存你可以需要找到aof⽂件将他删除rm -rf appendonly.aof4.MongoDB的删库跑路# 删除当前数据库use databaseName;db.dropDatabase()5. 删⽂档# 此⼤法适⽤于删除公司的备份⽂件，因为⽂档备份很多，你⼿⾥的可以微不⾜道，但是你可以⽤删⽂档的⽅法删服务器上的⽂件啊此法的奥义在与把⽂件删了再写⼊乱七⼋糟的数据，导致硬盘上的东西也⽆法恢复。
""0_0"".6. git⼤法众所周知git是⼀个版本控制⼯具，很多开发公司都拿他来做版本控制，⽤于协同开发# 此法最⼤的功效在于让你的队友可以愉快的加班，虽然你不⼀定需要跑路当是不敢保证你的队友不打你。
mysql语句的使用清库数据转移
mysql语句的使⽤清库数据转移mysql清空数据库表⽅法1：重建库和表⽤mysqldump --no-data把建表SQL导出来，然后drop database再create database，执⾏⼀下导出的SQL⽂件；⽅法2：⽣成清空所有表的SQLselect CONCAT('TRUNCATE TABLE ',table_name,';') from information_schema.tables where TABLE_SCHEMA = 'db1'导出到⽂件select CONCAT('TRUNCATE TABLE ',table_name,';') into outfile '/website/truncatetable.sql' from information_schema.tables where TABLE_SCHEMA = 'db1'清空数据库表并且重置⾃动增长列的值为0:TRUNCATE TABLE TableName仅仅清空数据库表:DELETＥ FROM TableNamemysql中把⼀个表的数据批量转移到另⼀个表中类别⼀、如果两张张表（导出表和⽬标表）的字段⼀致，并且希望插⼊全部数据，可以⽤这种⽅法：（此⽅法只适合导出两表在同⼀database）INSERT INTO ⽬标表 SELECT * FROM 来源表;例如，要将 articles 表插⼊到 newArticles 表中，则可以通过如下SQL语句实现：INSERT INTO newArticles SELECT * FROM articles;类别⼆、如果只希望导⼊指定字段，可以⽤这种⽅法：INSERT INTO ⽬标表 (字段1, 字段2, ...) SELECT 字段1, 字段2, ... FROM 来源表;请注意以上两表的字段必须⼀致（字段类型），否则会出现数据转换错误。
MySQL数据删除与回滚的最佳实践
MySQL数据删除与回滚的最佳实践在数据库管理中，数据删除是一个非常常见的操作。
但是，删除数据不仅仅是简单地执行DELETE语句，还需要考虑到数据的备份、回滚以及数据的完整性。
本文将讨论MySQL数据删除的最佳实践，并介绍如何使用事务和日志来实现数据的回滚操作。
1. 数据删除前的准备工作在执行数据删除之前，我们需要做一些准备工作来确保数据的完整性和备份。
首先，我们应该备份要删除的数据表，以防意外发生。
其次，在删除之前，我们应该对要删除的数据进行一次全面的检查，确保没有误删的数据或者错误的删除条件。
2. 使用事务进行数据删除事务是一种用于管理和控制数据库操作的机制。
在数据删除中，使用事务可以确保数据的一致性，并提供回滚的能力。
在MySQL中，可以使用BEGIN、ROLLBACK和COMMIT语句来实现事务的控制。
在执行数据删除前，我们可以使用BEGIN语句开启一个事务。
接下来，执行DELETE语句来删除数据。
如果删除过程中发生了错误或者需要回滚操作，可以使用ROLLBACK语句撤销事务。
如果删除操作执行成功，我们可以使用COMMIT语句提交事务，将删除操作永久保存到数据库中。
使用事务进行数据删除的好处是，可以确保删除过程中的数据完整性和一致性。
如果在删除过程中发生了错误，可以通过回滚操作恢复到原始的数据状态，避免造成数据的丢失或者损坏。
3. 利用日志进行数据删除的回滚除了使用事务，我们还可以使用MySQL的日志功能来实现数据删除的回滚。
MySQL的日志功能包括二进制日志(Binary Log)和错误日志(Error Log)。
二进制日志记录了对数据库的修改操作，包括数据的删除、插入和更新等。
当启用二进制日志功能后，可以通过回放二进制日志的方式来还原删除的数据。
要实现数据删除的回滚，我们可以按照以下步骤进行操作：- 首先，打开MySQL的二进制日志功能。
- 执行DELETE语句删除数据。
- 查找并记录删除操作在二进制日志中的位置信息。
预防删库跑路的方法
预防删库跑路的方法1. 定期备份：定期进行数据备份是防止删库跑路的关键措施之一。
可以选择在每天或每周的固定时间自动备份数据库。
确保备份的数据是完整且可恢复的。
2. 备份数据存储在安全的地方：备份数据应存储在安全的地方，远离主数据库。
可以将数据备份存储在云服务提供商的服务器上，也可以使用外部硬盘、网络存储设备等。
3. 设置权限控制：合理设置数据库的权限控制是防止删库跑路的重要手段。
只授权给必要的人员访问和修改数据库的权限，将管理员权限限制在少数几个人手中。
4. 定期检查数据库日志：定期检查数据库的操作日志，查看是否有异常的操作记录。
如果发现有可疑的操作，及时进行调查和处理。
5. 强化密码策略：设置强密码策略，要求用户使用复杂的密码，并定期更换密码。
使用加密算法保护密码，避免密码被破解。
6. 检查并修复安全漏洞：及时检查数据库系统中的安全漏洞，并及时修复。
安全补丁的及时应用可以减少黑客入侵的风险。
7. 监控数据库活动：使用数据库活动监控工具来监测数据库的活动情况，包括用户登录、操作记录等。
及时发现异常活动，并采取相应的应对措施。
8. 定期更新数据库软件：定期更新数据库软件是保持数据库安全的重要措施之一。
随着技术的不断进步，数据库软件会更新修复一些已知的安全漏洞，需要及时升级。
9. 社交工程防范：加强对员工的安全意识培训，提高对于社交工程攻击的警惕性。
员工应该避免向陌生人透露数据库的敏感信息。
10. 准入控制：对于外部访问数据库的设备，应该进行准入控制，只允许授权访问的设备连接数据库。
通过IP过滤、VPN等方式，限制非授权设备的访问。
mysql回滚机制的原理
mysql回滚机制的原理
MySQL回滚机制是MySQL事务机制的一个重要组成部分，唯有熟悉它，我们才能熟练掌握事务的运用，同时有助于提升数据库的稳定性和实用性。
MySQL回滚机制的核心原理是靠事务的特性来保证事务中的操作都是原子性的，可以对某一次操作进行回溯，让这次操作失败并且不会破坏表中原有数据。
这是通过两个关键词实现的，即COMMIT和ROLLBACK，COMMIT用来确定事务完成时生效，而ROLLBACK则用于将事务撤回到事务开始之前的状态，这就是MySQL回滚机制实现原理。
MySQL回滚机制在保证实体数据稳定性上起着非常关键的作用。
如果一项操作不能够保证稳定性，就会导致数据修改后不一致的情况。
当用户在回滚的时候使用ROLLBACK来取消当前事务中的所有操作，系统会暂时将数据库先安全保存，然后回滚，而ROLLBACK后也不会更改原有数据，这样保证了MySQL回滚机制可以保证当前操作的稳定性和准确度。
在实际的数据库应用开发中，使用MySQL回滚机制能让我们无论是在进行更新操作，还是在进行回退的时候都更加的安全可靠。
因为无论是OMMIT或者ROLLBACK，都能够保证过程中的安全性，从而向使用者提供更加可靠可信的数据库应用结果。
以上就是MySQL回滚机制的原理，它是一种以保证数据安全和实体数据一致性，提升数据库实用性和稳定性的重要技术手段，在一些重要数据库项目中最为常用。
所以，理解MySQL回滚机制，不仅有助于掌握事务的运用，也可以为我们提供一个更加安全可靠的数据库操作环境。
mysql删除数据原理
mysql删除数据原理MySQL是一个非常流行的关系型数据库管理系统，它允许用户在数据库中存储和操作大量数据。
删除数据是MySQL数据库管理的一个非常重要的任务，因为它可以帮助用户在数据库中清除不需要的数据，并释放空间以提高数据库的性能。
在本文中，我们将探讨MySQL删除数据的原理。
MySQL删除数据的原理非常简单：当用户执行删除数据操作时，MySQL将根据用户指定的条件查找要删除的记录，并将这些记录标记为“已删除”。
被标记为“已删除”的记录将不再在查询结果中返回，并且将在MySQL需要释放空间时被物理删除。
这个过程称为数据的逻辑删除。
逻辑删除的好处在于，它可以让用户恢复意外删除的数据。
当用户意识到删除了错误的数据时，他们可以通过将被标记为“已删除”的记录恢复到原始状态来恢复数据。
这个过程称为数据的回滚。
然而，逻辑删除也有一些缺点。
首先，被标记为“已删除”的记录仍然存在于数据库中，占用空间资源。
其次，当被标记为“已删除”的记录太多时，查询性能会受到影响，因为MySQL需要在查询结果中过滤这些记录。
最后，逻辑删除并不是完全安全的，因为它不能防止恶意或有意的破坏数据。
为了解决逻辑删除的一些问题，MySQL还提供了物理删除的功能。
当用户执行物理删除操作时，MySQL将直接从数据库中删除指定的记录，而不是将其标记为“已删除”。
这意味着被删除的记录将不再占用任何空间资源，并且查询性能将不会受到被删除的记录的影响。
然而，物理删除也是有风险的，因为它不能恢复已经被删除的数据。
在实际使用MySQL时，用户需要根据具体情况选择逻辑删除或物理删除。
如果数据比较重要，并且需要保证数据的完整性和安全性，那么最好使用逻辑删除。
如果空间和性能是更关键的因素，那么最好使用物理删除。
无论使用哪种删除方式，用户都需要谨慎操作，以避免无法恢复的数据丢失。
mysql的drop和 truncate 原理
mysql的drop和 truncate 原理MySQL是一个持久化存储数据的关系型数据库管理系统，它是Web应用程序特别是具有高并发、高数据负载需求的Web应用程序的首选之一。
在MySQL中，我们可以使用DROP 和TRUNCATE命令来删除数据表，这两个操作虽然都可以删除表格，但是它们的操作逻辑却有所不同。
本文将详细介绍MySQL中DROP和TRUNCATE的原理。
1. DROP操作的原理DROP操作是将整个表都进行删除。
执行DROP操作时，MySQL会启动调度器，去寻找和所要删除表相关的所有对象，如索引、约束和外键等，在这些对象中，所有触发器也会被禁用，然后将它们全部删除。
MySQL会将表的定义从DATA DIRECTORY中的ibdata文件删除，并且从mysql.innodb_table_stats表和mysql.innodb_index_stats表中删除表的元数据，这样MySQL就成功将整个表都删除。
DROP操作是非常危险的，因为该操作会将数据表全部清空，而且无法进行回滚。
一旦执行该操作，所有数据和表结构都将关闭。
在执行DROP操作之前，需要非常谨慎地考虑，以防不必要的损失和风险误判。
DROP操作的基本语法如下：```DROP TABLE table_name;```table_name是要删除的表名。
2. TRUNCATE操作的原理TRUNCATE操作仅删除数据表中的所有数据，而不删除表的结构。
在执行TRUNCATE操作之前，MySQL会先关闭表并获取表的Exclusive排它锁。
在获取锁后，MySQL会将表的定义从DATA DIRECTORY中的ibdata文件删除，并从mysql.innodb_table_stats表和mysql.innodb_index_stats表中删除表的元数据，以及与该表相关的所有约束和外键、索引等对象。
TRUNCATE操作的执行速度非常快，比DELETE操作要快得多，因为TRUNCATE操作不需要记录日志信息。
mysql常用sql与命令之从入门到删库跑路
mysql常⽤sql与命令之从⼊门到删库跑路⽬录启动与停⽌数据库相关操作数据库表相关操作约束相关默认约束数据库查询进阶SQL的四种连接查询内连接外连接要点梳理mysql的事务关于事务事务控制数据库的三⼤范式第⼀范式第⼆范式第三范式启动与停⽌启动mysql服务sudo /usr/local/mysql/support-files/mysql.server start停⽌mysql服务sudo /usr/local/mysql/support-files/mysql.server stop重启mysql服务sudo /usr/local/mysql/support-files/mysql.server restart进⼊mysql⽬录⽂件cd /usr/local/mysql/support-files进⼊mysql命令⾏/usr/local/MySQL/bin/mysql -uroot -p1*******退出数据库exit;数据库相关操作查询所有数据库show databases;选择(使⽤)数据库use mybatis;查询当前正在使⽤的数据库名称select database();创建数据库create database 数据库名称;创建数据库,判断不存在,再创建: create database if not exists 数据库名;删除数据库drop database 数据库名称;判断数据库存在，存在再删除:drop database if exists 数据库名称;数据库表相关操作创建数据库表create table 表名(列名1 数据类型1,列名2 数据类型2,....列名n 数据类型n);复制表create table 表名 like 被复制的表名;查看某个数据库中的所有的数据表show tables;查看数据表的结构desc pet;或describe pet;修改表名alter table 表名 rename to 新的表名;修改表的字符集alter table 表名 character set 字符集名称;添加⼀列alter table 表名 add 列名数据类型;删除列alter table 表名 drop 列名;删除表drop table 表名;或drop table if exists 表名 ;添加数据insert into 表名(列名1,列名2,...列名n) values(值1,值2,...值n);其中列名和值要⼀⼀对应。
深入浅析MySQL从删库到跑路_高级（一）——数据完整性
深⼊浅析MySQL从删库到跑路_⾼级（⼀）——数据完整性⼀、数据完整性简介1、数据完整性简介数据冗余是指数据库中存在⼀些重复的数据，数据完整性是指数据库中的数据能够正确反应实际情况。
数据完整性是指数据的可靠性和准确性，数据完整性类型有四种：A、实体完整性：实体的完整性强制表的标识符列或主键的完整性（通过唯⼀约束，主键约束或标识列属性）。
B、域完整性：限制类型（数据类型），格式（通过检查约束和规则），可能值范围（通过外键约束，检查约束，默认值定义，⾮空约束和规则）。
C、引⽤完整性：在删除和输⼊记录时，引⽤完整性保持表之间已定义的关系。
引⽤完整性确保键值在所有表中⼀致，不能引⽤不存在的值。
如果⼀个键。
D、定义完整性：⽤户⾃⼰定义的业务规则，⽐如使⽤触发器实现⾃定义业务规则。
2、数据完整性实现⽅式MySQL不⽀持Check约束，虽然可以在列上添加check约束，但不起作⽤。
⼆、实体完整性实现1、实体完整性的实现简介实体完整性的实现有两种⽅式：A、主键约束：⼀张表只能有⼀列设置主键，值必须唯⼀，不允许为空，innoDB存储引擎，主键就是索引。
B、唯⼀值约束：⼀张表可以有多个列添加唯⼀值约束，⼀直允许⼀条记录为空值。
实体完整性，由主键和唯⼀性约束来实现，确保表中记录有⼀列唯⼀标识。
主键⼜分为Primary key和AUTO_INCREMENT PRIMARY KEY两种。
2、主键MySQL的主键名总是PRIMARY，当创建主键约束时，如果表的存储引擎是innoDB，系统默认会在所在的列和列组合上建⽴对应的唯⼀索引，主键约束相当于唯⼀约束与⾮空约束的组合，主键约束列不允许重复，也不允许出现空值；多列组合的主键约束，列都不允许为空值，并且组合的值不允许重复。
每个表最多只允许⼀个主键，建⽴主键约束可以在列级别创建，也可以在表级别上创建。
A、创建表时指定主键创建表时指定主键的⽅式⼀：create table product(productID int PRIMARY KEY,pName VARCHAR(10),price DOUBLE)ENGINE=MyISAM default CHARSET=utf8;创建表时指定主键的⽅式⼆：create table product(productID int,pName VARCHAR(10),price DOUBLE, CONSTRAINT pk_s_productID PRIMARY KEY(productID))ENGINE=MyISAM default CHARSET=utf8;在指定主键的表中插⼊记录时，不允许插⼊重复ID，如果不指定主键的值，默认为0。
误删mysql了自带库，解决办法：mysql重新初始化
பைடு நூலகம்
登录后才能查看或发表评论立即登录或者逛逛博客园首页
误删 mysql了自带库，解决办法： mysql重新初始化
新装的mysql默认会自带4个库
误删mysql了自带库，把sys删掉了，真是让人头大。。 网上找了一些功课，总结了一下 解决办法就是对 mysql重新初始化 本人安装的是mysql5.7版本 1、将mysql数据库目录中文件清空 # rm -rf * 2、执行初始化 # mysqld --initialize --user=mysql 3、查看root帐号的随机密码 # cat /var/log/mysqld.log
MySQL创建数据库简单命令
MySQL创 建 数 据 库 简 单 命 令
1.创建数据库 CREATE DATABASE db_student;
2.删除数据库，删库跑路 drop database <数据库名>Hale Waihona Puke 3.查看MySQL中有那些数据库
SHOW DATABASES; 3.选择数据库 use <数据库名>; 4.创建数据库表，比如我们要创建一个user表 CREATE TABLE USER(
id INT NOT NULL AUTO_INCREMENT, NAME VARCHAR(30) NOT NULL, PASSWORD VARCHAR(32) NOT NULL, age INT(11) NOT NULL, sex VARCHAR(2) DEFAULT '男' CHECK (性别 IN ('男','女')), birthday DATE, PRIMARY KEY ( id ) )ENGINE=INNODB DEFAULT CHARSET=utf8; 5.查看数据库中有哪些表，和选择数据库操作一起用比较好，先选择数据库，再查看表。 SHOW TABLES;
6.查看表，这两句一个意思，都可以查看表。 SHOW COLUMNS FROM USER; DESCRIBE USER;
OK，先写到这里，不对的欢迎交流指正，我要写作业了QAQ！
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
mysql从删库到跑路
那年公司ERP系统刚进行升级
因为公司陆续上了MES和PDM系统。
为了加快整个公司信息化平台的统一，请了个第三方公司来做中间接口。
然后故事开始了。
某一个晚上，第三方人员问我要ERP的SA密码。
我很警惕：“你要干嘛？”
“我测试一下中间表。
”
“有没有写表的操作？”
“没有，只有读表的操作。
”
于是我放心的给了SA密码。
给了VPN权限通道。
放她进来了。
十分钟后…..
她带着哭腔打电话来（是的，对方做测试的是个93年的萌妹子。
）
“吴哥哥，服务器中毒了。
”
我当时还在逛果壳呢，一听她说我服务器中毒了，我表示无比淡定。
还以大哥的经验教训了一顿她。
“叫你不要往我服务器传插件嘛，这次帮你解决一下，下次不准了哟。
”
我认为是小case呢，不就中毒了嘛，系统往回滚一天就好了。
然后悲剧的事情就出现了。
远程进不去。
于是我就去机房本地登录，居然也进不去。
我不死心，强制重启。
居然还是进不去。
我的服务器系统就这样崩了。
好在那几天在做开发，系统没有启用。
于是我和我的老板汇报了这个情况：
“老大，我们服务器系统崩了。
”
“哦，那就搞好它让它别崩。
”果然是霸道总裁啊。
当时数据和应用服务器我都是分开跑的，所以应用服务器奔溃了，我觉得也没多大事，就重新做系统吧。
于是我重新做了个系统，然后喊萌妹子上来搭平台。
“小刘啊，你可害惨我了。
一个下午给你重做服务器系统了，我基础环境都配置好了，你上来搭平台吧。
”萌妹子那是无比的歉意啊，又是答应请我吃饭又是答应请我看电影的。
我都想系统再崩溃一次了。
按理说这样应该是没问题了，就在我走出机房，在外面抽了根烟，45度仰望了一下天空，联想了一下和萌妹子点个9分熟的牛排，在喝一口二锅头这样浪漫的晚餐的时候。
电话来了。
来电话的是萌妹子的老板。
“小吴，我想找一下information.db 和mfmedia.db 这两个总表，没找到。
你给我找一下。
”
我都蒙了，从来没人问过我这样的问题，难道她老板不是IT行业的。
“数据库文件都在目录树里啊，自己去找啊。
”
“没有。
”
于是我登上服务器一看，我傻了。
所有的表都空了。
所有的表都静静的躺在那，但是里面都空了。
不可能啊，我数据库是放在另外一台服务器上的，怎么可能会没有了。
于是我问萌妹子
“XXX，你到底做了什么操作啊，为毛我数据库都没了。
”
萌妹子说我啥也没干啊，只是按照步骤一路点YES,
我才想起来，在第一次配置基础环境的时候，建账套会提示是否初始环境，如果点是了，数据库就会被初始化。
然后这位萌妹子傻傻的点了是。
“你知道不知道你干了什么，公司06年到现在所有的数据，财务的，供应链的，进销存的全部都在这台服务器里。
200多个G数据，因为你一个是，全没了。
”
萌妹子也吓蒙了，话都说不出来了。
没办法，我再给我老板打电话。
“老板，有个好消息，有个坏消息。
”
“直接说坏的。
”我就喜欢我们老板这么直接。
“恩。
恩。
那个。
就是那个。
ERP的数据没了。
”
“哦，那就找回来。
”老板还是那么的霸气。
我特么都要爱上他了。
“老板，我想你没明白这个的严重性。
ERP数据没了，从06年开始的都没了，这意味着就算找回来，整理所有的表，排错也需要3天左右时间，到时候所有的生产都要暂时停止。
如果找不回来，我们可能就要倒闭了。
”我忽然有种掌握天下苍生的感觉。
对面沉默了5秒后，爆吼了一句：“吴XX，你给我滚到我办公室来!!”
中间和老板手握手谈心，被老板亲切慰问的细节跳过不表。
当时公司高层对数据安全还没有那么重视，之前预算做的项目，我已经做了备份的计划书，一直没被审批下来。
现在估计悔得肠子都清了。
于是我开始漫长的数据恢复之旅。
我之前已经做了个本地备份的计划，每天晚上会备份一次。
我把希望都放在了它身上。
等我把备份的数据库附件上去，发现时间居然都是两个星期之前的。
而且还有一些新表都没有。
我联系对方，对方告知研发人员两个星期前做测试的时候把备份计划关了。
我心里万头草泥马奔腾而过。
最后没有办法，把老服务器又翻了出来，翻出之前的老数据，开始转换。
期间老板给我短信：
“数据恢复进行的怎么样了呢。
”
“报告，正在稳步进行中，按照目前的状况，可恢复的可能性超过90%。
”别问我90%怎么算出来的，我就是哄他才这样说的。
“诶，真是心急呀，睡都睡不着。
小吴呀，当初要是听你的，上了备份该多好呀。
”现在知道后悔了，哼哼。
“老大别担心，我会搞定的。
”是的，作为一位负责的员工，我就是这么让老大心安。
“恩，那就交给你了哦，熬夜少抽点烟哦。
”哎呀，瞬间觉得我老大萌萌哒有没有。
这里花了我一个晚上加一个白天。
数据转换好了，还有一些时间差的数据没法找到。
于是通知各个部门，找单据，开始往里面补单子。
一条一条的按照业务流程补进去。
为了协同更方便，在会议室加设了几十台电脑集体办公。
在大家一片怨声载道中，三天时间，终于把数据恢复了过来。
三天内我没离开机房超过10米，吃喝拉撒都在机房，不对，拉撒不在。
这件事情造成的后果：
1. 大部分员工放假三天，我加班三天三夜。
2. 本来很爱我的大部分员工因为单据事件，集体转为黑我恨我了。
3. 公司立马批了我的计划，冷备，热备，异地容灾。
全部上全了。
4. 我挥刀自宫，自己罚了自己，扣除了自己一个月工资。
5. 老板到现在还是在怀疑请的那家公司已经被我们竞争对手收买，是故意来破坏我们的。
6. 萌妹子拉黑了我。
这真是个悲伤的故事。