本文详细介绍了MySQL数据库的各个方面，包括事务特性、MVCC机制、持久化存储、Undo和Redo日志、不同存储引擎的特点、锁定机制、查询优化技巧、读写分离、主从复制配置、数据库规范化过程、SQL注入防范措施以及分库分表实践等内容。同时，还提供了常用的SQL语句示例，帮助读者更好地理解和应用MySQL数据库。
MySQL-知识详解
MySQL 事务 的基本特征
MySQL 事务具有以下基本特征:
| 特征 | 描述 |
|---|---|
原子性 | 事务是原子的单位，要么全部执行成功，要么全部执行失败。如果事务中的任何一步失败，则整个事务将回滚到初始状态，保持数据的一致性。 |
一致性 | 事务执行前后，数据库从一个一致的状态转移到另一个一致的状态。这意味着事务在执行过程中对数据的修改不会破坏数据库的完整性约束，例如唯一性约束、外键约束等。 |
隔离性 | 事务的隔离性指的是多个事务并发执行时，每个事务都应该感觉不到其他事务的存在。MySQL 使用事务隔离级别来控制事务之间的相互影响，包括读未提交、读提交、可重复读和串行化。 |
持久性 | 事务提交后，对数据库的修改应该永久保存，即使系统发生故障也不会丢失。 |
MySQL 事务 隔离机制
MySQL 的事务隔离机制指的是多个事务并发执行时，各个事务之间的隔离程度，即一个事务在执行过程中能否感知到其他事务对数据的修改。MySQL 提供了四种事务隔离级别,分别是 未读提交、 已读提交、可重复读、 可串行化。
| 隔离级别 | 描述 |
|---|---|
| 未读提交 | 允许一个事务读取另一个事务尚未提交的数据，可能导致脏读问题。 |
| 已读提交 | 确保一个事务只能读取到已经提交的数据，避免了脏读问题，但可能会出现不可重复读问题。 |
| 可重复读 | 保证一个事务在执行过程中多次读取同一数据时得到的结果始终一致，其他事务对数据的修改只有在当前事务提交后才可见，避免了不可重复读问题，但可能出现幻读问题。 |
| 可串行化 | 最高级别的隔离级别，确保每个事务按顺序依次执行，避免了脏读、不可重复读和幻读问题，但性能损失较大。 |
脏读与幻读
脏读和幻读都是数据库中常见的问题，它们涉及到事务并发执行时可能出现的数据不一致情况，但具体表现和原因略有不同：
1、脏读
定义：脏读指的是一个事务在读取另一个事务未提交的数据时发生的现象。
例子：事务A修改了某行数据但尚未提交，此时事务B读取了这行未提交的数据。
影响：如果事务A后续回滚了，那么事务B读取的数据就是不正确的，导致数据的不一致性。
2、幻读
定义：幻读指的是在一个事务中多次查询同一数据集合时，由于其他事务的插入或删除操作，导致第二次查询结果与第一次不一致的现象。
例子：事务A在查询某个范围的数据，此时事务B插入了新的数据，然后事务A再次查询该范围的数据，发现结果集合发生了变化。
影响：幻读会导致同一事务内部的查询结果不一致，可能影响业务逻辑的正确性。
3、如何解决脏读与幻读
解决脏读和幻读问题通常需要综合考虑事务隔离级别、锁机制和业务逻辑等因素。尽可能选择合适的事务隔离级别，例如将隔离级别设置为可重复读，可以避免大部分脏读和幻读问题。
使用锁机制来限制对数据的访问，例如悲观锁或乐观锁，以确保在操作数据时不会被其他事务干扰。悲观锁适用于频繁写入的情况，通过在事务开始时锁定数据来避免并发写入问题。
合理设计表结构和索引，以减少查询时的锁定范围，降低发生幻读的可能性。避免长时间持有锁或事务，尽量缩短事务执行的时间，减少锁冲突的发生。
什么是ＭＶCC
MVCC（Multi-Version Concurrency Control）是一种数据库并发控制机制，用于解决多个事务同时访问数据库时可能出现的并发冲突和一致性问题。MVCC主要通过版本管理来实现并发控制，常见于支持事务的数据库系统，如MySQL、PostgreSQL等。
MVCC 只在 已提交读 和 可重复读 两个隔离级别下工作。其他两个隔离级别和mvcc不兼容。因为未读提交 总是读取最新的数据行，而不是符合当前事务版本的数据行。而 序列化 则会对所有的行都加锁。
MVCC的基本原理
MVCC的基本原理是在事务对数据进行修改时，不直接覆盖原始数据，而是创建新的数据版本（或称为快照），并通过版本号或时间戳来区分不同的数据版本。这样可以实现事务之间的隔离，各个事务看到的数据版本是自己操作的一致性视图，而不会受到其他事务的影响。
MySQL的MVCC机制
MySQL的MVCC机制主要包括以下几个方面：
- 版本号：每个事务在开始时会被分配一个唯一的版本号，用于标识该事务所读取的记录版本。
- Read View：每个事务在开始时会创建一个Read View，该视图包含了该事务所能够看到的所有记录版本信息。
- Undo Log：当一个事务修改一条记录时，会在Undo Log中记录该修改操作，以便事务回滚时可以恢复到之前的状态。
- Rollback Segment：用于保存所有未提交的事务所做的修改操作，以便在事务回滚时可以撤销这些操作。
- Purge：当一个事务提交时，所有早于该事务开始时间的版本将不再需要，这时MVCC会删除这些版本。
- Gap Lock：在MVCC中，为了防止幻读（Phantom Read）的问题，引入了Gap Lock机制，用于防止其他事务在当前事务对某些记录进行修改时，对这些记录进行插入操作。
总之，MySQL的MVCC机制为并发控制提供了一种高效而可靠的实现方式，它可以通过创建“快照”版本来实现并发读写操作，从而提高数据库的性能和可靠性。
MySQl的持久化机制
MySQL 的持久化机制主要是通过日志和数据文件来实现数据的持久化和恢复，确保数据在数据库关闭或发生故障时不会丢失。主要有Undo Log 和 Redo Log。
Undo Log
Undo log（事务回滚）是 MySQL 数据库中的一种事务日志，用于记录事务对数据的修改前的原始数据，以便在事务回滚时可以撤销对数据的修改，保持数据的一致性。
Undo Log作用
- 记录事务对数据的修改前的原始数据，即事务执行修改操作之前的数据状态。
- 在事务回滚时，通过 undo log 中的记录，可以撤销对数据的修改操作，将数据恢复到事务开始之前的状态，保持数据的一致性。
Undo Log组成
Undo log 主要由两个部分组成：物理 undo log 和逻辑 undo log。
- 物理 undo log：记录数据页的修改前的原始数据，是对数据库物理结构的撤销记录。
- 逻辑 undo log：记录逻辑操作的撤销操作，如 SQL 语句的执行顺序、事务的提交、回滚等。
Undo Log工作原理
1、当事务对数据进行修改时，MySQL 将修改前的原始数据记录为 undo log 的日志项，存储在内存中的 undo log 缓冲区中。
2、在事务提交时，MySQL 将 undo log 缓冲区中的日志项刷新到磁盘上的 undo log 文件中，保证数据的持久化。
3、在事务回滚时，通过读取 undo log 文件中的日志项，可以撤销事务对数据的修改操作，将数据恢复到事务开始之前的状态。
Undo Log底层实现
MySQL 的 Undo Log是 InnoDB 存储引擎用于实现事务的一致性和回滚机制的重要组成部分。
1、InnoDB 将 Undo Log 分为多个 Undo Log Segments，每个 Segment 包含多个 Undo Log Page。每个 Undo Log Page 大小通常为 16KB，用于存储 Undo Log Entry。
2、Undo Log Entry 是 Undo Log 的基本单位，用于记录事务对数据的修改前的原始数据。每个 Undo Log Entry 包含了修改前的数据、事务 ID、回滚指针等信息。
3、每个事务在开始时会分配一个唯一的事务 ID，用于标识该事务的 Undo Log Entry。当事务对数据进行修改时，InnoDB 将修改前的原始数据记录为 Undo Log Entry，并与事务 ID 关联。
4、Undo Log Purge 是 InnoDB 的后台任务，用于回收已经不再需要的 Undo Log Entry。当一个事务提交或回滚后，其对应的 Undo Log Entry 可以被回收，释放对应的 Undo Log Page。
Redo Log
Redo log（数据恢复）是 MySQL 数据库中的一种事务日志，用于记录事务对数据的修改操作。它是数据库的持久化机制之一，主要用于保证数据在数据库崩溃或断电等异常情况下的恢复性。
Redo Log作用
- 记录事务对数据的修改操作，包括插入、更新、删除等操作。
- 保证在数据库异常关闭或断电时，通过重放 redo log 中的日志项，可以重新执行事务的修改操作，从而恢复数据到一致性状态。
Redo Log组成
Redo log 主要由两个部分组成：物理日志（Physical Log）和逻辑日志（Logical Log）。
- 物理日志：记录数据页的修改操作，如数据块的插入、更新、删除等，是对数据库物理结构的改变。
- 逻辑日志：记录逻辑操作，如 SQL 语句的执行顺序、事务的提交、回滚等，是对数据库逻辑操作的记录。
Redo Log工作原理
1、当事务对数据进行修改时，MySQL 将修改操作记录为 redo log 的日志项，存储在内存中的 redo log 缓冲区中。
2、定期将 redo log 缓冲区中的日志项刷新到磁盘上的 redo log 文件中，保证数据的持久化。
3、在数据库崩溃或断电时，通过重放 redo log 文件中的日志项，可以重新执行事务的修改操作，恢复数据的一致性。
Redo Log底层实现
MySQL 的 redo log 是通过 InnoDB 存储引擎来实现的。
1、MySQL 使用一个称为日志缓冲区（Log Buffer）的内存区域来暂存事务对数据的修改操作，这些操作被称为日志记录（Log Record）。日志记录包括对数据页的修改、事务的提交、回滚等操作。
2、在日志缓冲区中的日志记录会定期（或事务提交时）刷新到磁盘上的重做日志文件（Redo Log File）中。重做日志文件通常是一个循环写入的日志文件，当文件写满时会重新开始写入，保证了日志的持久性和高效性。
3、每个重做日志文件都有一个唯一的日志序列号（Log Sequence Number，LSN），用于标识日志记录的顺序。当事务提交时，会将事务的提交LSN记录到内存中的磁盘检查点（Checkpoint）中，用于数据库恢复时的定位。
4、在数据库异常关闭或断电后，MySQL 会通过重做日志文件中的日志记录来恢复数据库的数据。恢复过程中会根据事务的提交LSN来确定需要恢复的日志记录范围，然后重放这些日志记录，将数据库恢复到一致性状态。
Undo Log与 Redo Log 对比
| 特点 | Undo Log | Redo Log |
|---|---|---|
| 目的 | 记录事务对数据的修改前的原始数据 | 记录事务对数据的修改操作后的数据 |
| 内容 | 修改前的原始数据 | 修改后的数据 |
| 存储位置 | Undo Log Segments | Redo Log Files |
| 触发时机 | 在事务对数据进行修改前触发记录 | 在事务对数据进行修改后触发记录 |
| 记录方式 | 记录修改前的数据 | 记录修改后的数据 |
| 应用场景 | 事务回滚和撤销操作 | 数据库的恢复和故障恢复操作 |
数据库存储引擎
数据库底层结构通常是由存储引擎来实现的，MySQL的存储引擎有InnoDB、MyISAM。
InnoDB 存储引擎
事务支持
InnoDB 是 MySQL 的事务性存储引擎，支持事务的 ACID 特性（原子性、一致性、隔离性、持久性）。
可以使用 BEGIN TRANSACTION、COMMIT 和 ROLLBACK 等语句来管理事务。
锁机制
InnoDB 使用行级锁（Row-Level Locking），可以最大程度地减少锁定冲突，提高并发性能。
通过 MVCC（Multi-Version Concurrency Control）实现事务的隔离性，读写之间不会相互阻塞。
外键约束：
支持外键约束，可以定义和管理表之间的关联关系，保证数据的完整性和一致性。
崩溃恢复：
InnoDB 支持崩溃恢复和自动恢复功能，可以保证数据的可靠性和完整性。
在数据库异常关闭或崩溃后，可以通过日志文件和 redo log 来进行崩溃恢复。
ACID 特性：
支持事务的原子性（Atomicity），保证事务的全部操作要么全部执行成功，要么全部回滚。
支持事务的一致性（Consistency），事务执行前后数据库的状态保持一致。
支持事务的隔离性（Isolation），事务之间相互隔离，避免并发问题。
支持事务的持久性（Durability），事务提交后数据持久保存在数据库中，不会因为系统故障而丢失。
索引类型：
使用 B+ 树索引，适合大规模数据查询和高并发的应用场景。
支持主键索引、唯一索引、普通索引等多种索引类型。
表锁定：
不会锁定整个表，可以实现并发的读写操作，提高系统的并发性能。
容灾能力：
支持数据的备份和恢复，可以应对数据库的灾难性故障。
可以通过主从复制、集群等方式实现数据的容灾和高可用性。
适用场景：
适合需要支持事务、外键约束、并发控制和高可靠性的应用场景，如电商平台、金融系统等。
MyISAM存储引擎
事务支持：
MyISAM 不支持事务，不具备 ACID 特性（原子性、一致性、隔离性、持久性），不支持回滚和事务的原子性保证。
锁机制：
MyISAM 使用表级锁（Table-Level Locking），对整个表进行锁定，容易出现并发性能问题和锁定冲突。
外键约束：
不支持外键约束，无法定义和管理表之间的关联关系，数据完整性需要应用层面来保证。
崩溃恢复：
不支持崩溃恢复和自动恢复功能，对数据的可靠性和完整性保护较弱。
ACID 特性：
不支持事务的原子性、一致性、隔离性和持久性，不适合处理复杂的数据操作和事务处理。
索引类型：
使用 B+ 树索引，但不支持主键索引的自动增长功能，只支持基本的索引类型。
MyISAM 索引的维护相对简单，适合对读操作频繁的场景。
表锁定：
可以锁定整个表，在高并发环境下容易造成性能瓶颈和锁定等待。
容灾能力：
不支持数据备份和恢复功能，对于故障恢复能力较差。
无法通过主从复制或集群等方式实现数据的容灾和高可用性。
适用场景：
适合只读的数据或者对事务和并发性能要求不高的应用场景，如静态网站、报表系统等。
innodb和myisam的区别？
| 特点 | InnoDB | MyISAM |
|---|---|---|
| 事务支持 | 支持 | 不支持 |
| 锁机制 | 行级锁 | 表级锁 |
| 外键约束 | 支持 | 不支持 |
| 崩溃恢复 | 支持 | 不支持 |
| ACID 特性 | 支持 | 不支持 |
| 数据缓存 | 支持 | 不支持 |
| 索引类型 | B+ 树索引 | B+ 树索引 |
| 表锁定 | 不会锁定整个表 | 可以锁定整个表 |
| 容灾能力 | 支持 | 不支持 |
Mysql锁有哪些
按粒度划分：
行锁（Row Lock）：
锁定某一行数据，锁粒度最小，允许其他事务并发访问其他行。
提高并发度，但需要注意死锁和性能损耗问题。
表锁（Table Lock）：
锁定整张表，锁粒度最大，阻塞其他事务对整个表的读写操作。
并发度较低，适用于需要对整个表进行操作的场景。
间隙锁（Gap Lock）：
锁定一个区间，防止其他事务在该区间内插入新数据，保证数据唯一性和完整性。
通常与 Next-Key Locks 结合使用，用于索引范围的控制。
按锁类型划分：
共享锁（Shared Lock）：
也称为读锁，允许多个事务同时读取数据，但不允许写入操作。
提高读取数据的并发性，适用于读多写少的场景。
排他锁（Exclusive Lock）：
也称为写锁，只允许一个事务对数据进行写入操作，其他事务不能读取或写入。
保证写操作的原子性和一致性，适用于需要修改数据的场景。
按锁的实现方式划分：
乐观锁（Optimistic Lock）：
不会真正去锁定数据行，而是通过版本号或时间戳等方式实现的并发控制。
提高并发性能，但需要处理并发冲突和版本管理问题。
悲观锁（Pessimistic Lock）：
包括行锁、表锁等，通过实际锁定数据行或表来控制并发访问。
确保数据的一致性和完整性，但可能造成性能瓶颈和资源竞争。
Mysql查询慢该如何优化？
索引优化：
使用合适的索引可以大大提高查询性能，尤其是针对经常用于查询条件的列进行索引。避免过多的索引，过多的索引会增加写操作的成本和数据库空间占用。
查询语句优化：
确保查询语句简洁明了，避免不必要的联表查询和复杂的子查询。使用合适的查询条件，避免全表扫描和大量数据的排序和分组操作。
缓存优化：
使用数据库查询缓存（Query Cache）可以缓存查询结果，减少对数据库的实际查询次数。注意缓存的命中率和缓存的更新策略，避免缓存失效和频繁的缓存更新。
数据库结构调优：
定期进行数据库结构的调优和优化，包括表的分区、分表、归档等操作。根据业务需求和数据量变化调整数据库结构。
mysql如何进行数据库调优
MySQL 数据库的调优涉及多个方面，包括服务器配置、查询优化、索引优化、缓存优化等。
服务器配置优化：
调整 MySQL 服务器的配置参数，包括缓冲区大小、连接数、并发线程数、查询缓存大小等。根据服务器的硬件配置和实际负载情况进行调整，避免资源浪费和性能瓶颈。
查询优化：
编写简洁高效的查询语句，避免不必要的联表查询、复杂的子查询和全表扫描。使用合适的查询条件、避免大量数据的排序和分组操作，减少数据库的压力。
索引优化：
对经常用于查询条件的列进行索引优化，提高查询性能。避免过多的索引，选择合适的索引类型和长度，避免索引失效和冗余。
缓存优化：
使用数据库查询缓存（Query Cache）缓存查询结果，减少数据库的实际查询次数。注意缓存的命中率和缓存的更新策略，避免缓存失效和频繁的缓存更新。
表结构优化：
合理设计表结构，避免过度冗余和不必要的字段。使用合适的数据类型，避免使用过长的 VARCHAR 和不必要的 TEXT/BLOB 类型。
分区和分表：
对大型数据表进行分区和分表，减少单表数据量，提高查询和写入性能。根据业务需求和数据量变化进行合理的分区和分表策略。
读写分离
读写分离是一种数据库优化策略，通过将读操作和写操作分别分配到不同的数据库服务器上，来提高数据库的读取性能和并发处理能力。通常情况下，读操作的频率远远高于写操作，因此将读操作分配到多个服务器上可以有效减轻主服务器的负载，提高系统的整体性能和稳定性。
在读写分离中，通常会有以下几个角色：
主服务器（Master）：
主服务器负责处理所有的写操作（INSERT、UPDATE、DELETE）。主服务器拥有完整的数据集，是系统的核心数据源。
从服务器（Slave）：
从服务器负责处理读操作（SELECT）。从服务器通过主服务器的数据复制功能，定期同步主服务器上的数据，保持数据一致性。
如何实现读写分离？
- 准备主从数据库：
首先需要准备主数据库（Master）和至少一个从数据库（Slave）。主数据库负责处理写操作，从数据库负责处理读操作。 - 配置主数据库：
在主数据库上开启二进制日志（Binary Logging），用于记录主数据库上的所有写操作（INSERT、UPDATE、DELETE）。配置主数据库允许从数据库进行复制，并设置复制账号和权限。 - 配置从数据库：
在从数据库上配置主数据库的连接信息，包括主数据库的地址、端口、复制账号和权限。启动从数据库的复制功能，从主数据库同步数据。 - 测试数据同步：
在主数据库上进行写操作，如插入新数据或更新已有数据。在从数据库上查询写操作的数据，验证数据同步是否正常。 - 应用程序配置：
在应用程序中配置读写分离的连接信息，如主数据库连接用于写操作，从数据库连接用于读操作。根据业务需求和访问模式，合理分配读写操作到不同的数据库连接。 - 监控和维护：
设置监控系统，实时监控主从数据库的状态和数据同步情况，及时发现并处理 - 同步延迟或异常。
定期进行数据库维护和优化，确保系统的稳定性和性能优化。
主从复制
主从复制（Master-Slave Replication）是指在数据库系统中，将一个数据库服务器作为主服务器（Master），负责处理写操作（INSERT、UPDATE、DELETE），同时将数据实时或定时复制到一个或多个从服务器（Slave），从服务器主要用于处理读操作（SELECT）。主从复制是一种常见的数据库架构，用于提高系统的性能、可用性和数据备份。
主从复制步骤
- 配置主服务器
- 配置从服务器
- 初始化数据
- 启动复制
- 监控和维护
主从复制的优点
- 提高读取性能：将读操作分散到多个从服务器上，减轻主服务器的负载，提高读取性能和并发处理能力。
- 提高系统稳定性：主从复制可以降低系统单点故障的风险，提高系统的可用性和稳定性。
- 数据备份和恢复：从服务器可以作为数据备份，用于灾难恢复和数据保护。
数据库 三 范式
数据库的三范式（Third Normal Form，3NF）是关系数据库设计中的重要原则，用于规范化数据库表结构，提高数据存储的效率和数据的一致性。
第一范式（1NF）：
数据表中的每一列都是不可再分的原子值，即每个字段不再包含多个值或重复的值。数据表中的每一行都包含唯一的主键，确保数据的唯一性和识别性。
第二范式（2NF）：
数据表必须符合第一范式，并且所有非主键列都完全依赖于主键，而不是部分依赖。换句话说，表中的每一列数据都与主键相关，而不是与主键的一部分相关。
第三范式（3NF）：
数据表必须符合第二范式，并且不存在传递依赖，即非主键列之间不应该存在依赖关系。换句话说，非主键列之间的关系应该是直接的，而不是通过其他非主键列间接关联的。
示例说明
考虑一个简单的图书馆管理系统，包括以下两个实体：书籍（Books）和作者（Authors）。
1NF：
将书籍表（Books）中的作者名字段移动到作者表（Authors）中，确保每个字段都是原子值。每个表都有主键来唯一标识每个记录。
Books 表：
| BookID | Title | AuthorID | AuthorName |
|---|---|---|---|
| 1 | Database Systems | 101 | John Smith |
| 2 | Algorithms | 102 | Jane Doe |
| 3 | Programming Basics | 101 | John Smith |
| 4 | Data Structures | 103 | Mark Johnson |
Authors 表：
| AuthorID | AuthorName |
|---|---|
| 101 | John Smith |
| 102 | Jane Doe |
| 103 | Mark Johnson |
2NF
每个表都符合第一范式，且非主键列完全依赖于主键。书籍表中的作者名与作者ID直接关联，没有部分依赖。
Books 表：
| BookID | Title | AuthorID |
|---|---|---|
| 1 | Database Systems | 101 |
| 2 | Algorithms | 102 |
| 3 | Programming Basics | 101 |
| 4 | Data Structures | 103 |
Authors 表：
| AuthorID | AuthorName |
|---|---|
| 101 | John Smith |
| 102 | Jane Doe |
| 103 | Mark Johnson |
3NF
每个表都符合第二范式，且不存在传递依赖。书籍表中的作者名移除，因为可以通过作者ID从作者表中获取。
在第三范式下，书籍表（Books）中的作者名已经移除，因为这是一个非主键列，可以从作者表（Authors）中获取。这样设计避免了数据冗余，同时也保证了数据的一致性。
Books 表：
| BookID | Title | AuthorID |
|---|---|---|
| 1 | Database Systems | 101 |
| 2 | Algorithms | 102 |
| 3 | Programming Basics | 101 |
| 4 | Data Structures | 103 |
Authors 表：
| AuthorID | AuthorName |
|---|---|
| 101 | John Smith |
| 102 | Jane Doe |
| 103 | Mark Johnson |
创建数据库时自动建立的tablespace名称
MYSQL默认不创建表空间。，MySQL将数据存储在数据目录中，这通常是在MySQL安装时指定的目录。MySQL使用存储引擎来管理数据，每个存储引擎都有其自己的文件和目录结构来存储数据。
Oracle ：在创建数据库时，通常会默认创建两个tablespace：SYSTEM和SYSAUX。其中SYSTEM tablespace是用于存储系统数据和对象的表空间，例如数据字典、系统表等；SYSAUX tablespace是用于存储其他系统数据和对象的表空间，例如一些需要占用大量空间的内部数据库组件等。当然，也可以在创建数据库时手动指定其他的tablespace名称。
SQL注入
SQL注入是一种常见的网络安全漏洞，攻击者利用此漏洞向应用程序的数据库发出恶意的SQL查询或指令。这可能导致数据库泄露敏感信息、数据损坏、甚至服务器被攻击。
SQL注入形式：
基于用户输入的注入：
攻击者通过应用程序的用户输入字段（如表单、URL参数等）注入恶意SQL代码，例如在登录表单中输入 ’ OR 1=1; --。
盲注注入：
攻击者不知道具体数据库结构，但尝试通过逻辑推断进行注入，例如使用布尔盲注或时间盲注。
二次注入：
攻击者在已经存在的注入漏洞上进一步注入代码，例如在管理员登录成功后执行的操作中注入代码。
防范措施：
参数化查询：
使用参数化查询或预编译语句（Prepared Statements）可以防止SQL注入，因为参数化查询会将用户输入作为参数，而不是直接拼接到SQL语句中。
输入验证和过滤：
对用户输入进行验证和过滤，确保输入符合预期格式和范围。例如，只接受数字、字母等合法字符，并对特殊字符进行转义或过滤。
最小权限原则：
为数据库用户分配最小权限，限制其对数据库的访问和操作权限，减少攻击面。
错误处理：
不要将详细的错误信息返回给用户，尤其是包含数据库结构和SQL语句的错误信息，应该统一返回一般性错误提示。
分库分表
分库分表是指将一个大型数据库中的数据按照一定规则分散存储到多个数据库实例或表中，用于解决数据库性能瓶颈和扩展性问题。
什么是分库？
分库是指将一个大型数据库中的数据按照一定规则分散存储到多个独立的数据库实例中。分库的主要目的是提高数据库系统的性能、可扩展性和并发处理能力，同时减轻单个数据库实例的负载压力，降低系统出现性能瓶颈的风险。
分库可以采用水平分库和垂直分库两种方式：
水平分库：
按照某种规则将数据分散存储到多个数据库实例中，每个数据库实例存储部分数据，例如按照用户ID范围、时间范围、地理位置等进行分库。水平分库可以提高系统的并发处理能力，减轻单个数据库实例的负载压力，同时也便于数据扩容和水平扩展。
垂直分库
将数据库中的不同业务模块或功能模块分散存储到不同的数据库实例中，例如将用户信息、订单信息、商品信息等分散存储到不同的数据库中。垂直分库可以隔离业务数据，提高系统的可维护性和扩展性，但需要注意不同数据库之间的数据一致性和关联问题。
什么是分表
分表是指将一个大型数据库中的数据表按照一定规则分散存储到多个独立的数据表中。分表的主要目的是降低单个数据表的数据量，提高数据库系统的读写性能、查询效率和并发处理能力。
分表可以采用水平分表和垂直分表两种方式：
水平分表：
按照某种规则将数据表中的数据分散存储到多个独立的数据表中，例如按照时间范围、数据量、业务逻辑等进行分表。水平分表可以降低单表数据量，提高查询性能和数据处理效率，同时便于数据分布式存储和扩容。
垂直分表：
将数据表中的不同列或字段分散存储到不同的数据表中，例如将常用字段和不常用字段分开存储，或将经常一起查询的字段放在同一个数据表中。垂直分表可以降低单表的列数和数据冗余，提高系统的可维护性和查询效率。
什么情况下需要分库分表？
1、数据量大：当单个数据表中的数据量非常大时，可能导致查询性能下降、响应时间延长，甚至影响系统的稳定性。这时可以考虑分表来降低单表的数据量。
2、并发访问量大：当系统面临大量并发访问请求时，单个数据表的读写操作可能会成为瓶颈，导致响应速度下降或请求堆积。分库分表可以提高并发处理能力。
3、业务拓展需求：随着业务的发展，可能需要增加新的业务模块或功能，如果单个数据表无法满足新业务的存储和查询需求，可以考虑分库分表来分隔不同业务数据。
4、数据访问频率不均衡：某些数据访问频率非常高，而另一些数据访问频率较低，如果将它们存储在同一个数据表中，可能会导致资源浪费或性能不均衡。分库分表可以根据数据访问频率进行合理分配。
5、数据隔离和安全性：某些敏感数据需要进行隔离存储，避免与其他数据混合存储而导致安全风险。分库分表可以实现数据隔离和安全管理。
MySQL常用的SQL语句
-- 查询所有数据
SELECT * FROM table_name;
-- 查询特定列
SELECT column1, column2 FROM table_name;
-- 条件查询
SELECT * FROM table_name WHERE condition;
-- 排序查询
SELECT * FROM table_name ORDER BY column_name DESC;
-- 聚合函数查询
SELECT AVG(column_name) FROM table_name;
-- 插入数据
INSERT INTO table_name (column1, column2) VALUES (value1, value2);
-- 更新数据
UPDATE table_name SET column1 = value1 WHERE condition;
-- 删除数据
DELETE FROM table_name WHERE condition;
-- 创建表
CREATE TABLE table_name (
column1 datatype,
column2 datatype
);
-- 修改表结构
ALTER TABLE table_name ADD column_name datatype;
-- 创建索引
CREATE INDEX index_name ON table_name (column_name);
-- 删除索引
DROP INDEX index_name ON table_name;
-- 创建用户
CREATE USER 'username'@'localhost' IDENTIFIED BY 'password';
-- 授权用户
GRANT SELECT, INSERT ON database_name.* TO 'username'@'localhost';
-- 撤销权限
REVOKE SELECT ON database_name.* FROM 'username'@'localhost';
-- 备份数据库
mysqldump -u username -p database_name > backup_file.sql;
495
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
