关系型数据库组成
关系型数据库是由一组相关联的表组成的，每个表由一组行和列组成。其中，行代表一个实体，例如一条订单或一个用户；列代表实体的属性，例如订单号、用户姓名等。每个表都有一个唯一的标识符（表名），并与其他表之间建立关系。关系型数据库的组成包括以下几个方面：
数据表：数据表是关系型数据库的核心，它由一组行和列组成，用于存储数据。每个数据表都有一个唯一的表名，以及一组列，每列代表数据表中的一个属性。
数据行：数据行代表数据表中的一个实例，它包含了一组数据列的值，每行都有一个唯一的标识符，通常称为主键。
数据列：数据列代表数据表中的一个属性，它定义了数据的类型和大小，以及数据的约束条件，例如唯一性约束、非空约束等。
约束：约束是关系型数据库中的重要概念，它用于限制数据表中的数据，以确保数据的正确性和完整性。常见的约束包括唯一性约束、非空约束、主键约束、外键约束等。
索引：索引是用于加速数据检索的数据结构，它通过提前对数据进行排序和分类，可以大大提高数据检索的效率。
视图：视图是一个虚拟的数据表，它由一个或多个实际数据表组成，并根据某些条件筛选、组合和排序数据，提供了一种方便的方式来访问和处理数据。
存储过程和函数：存储过程和函数是一组预定义的程序代码，它们可以被存储在数据库中，用于执行一些常见的数据处理任务，例如计算、转换、验证等。它们可以提高应用程序的性能和可维护性，减少数据库访问的频率。
事务：事务是一组相关的数据库操作，它们被视为一个原子操作，并且要么全部执行成功，要么全部回滚，以确保数据的一致性和完整性。
总之，关系型数据库由表、行、列、约束、索引、视图、存储过程和函数等组成，它们共同构成了一个可靠、高效、可扩展的数据存储和处理系统。
执行过程
SQL执行过程可以大致分为以下几个步骤：
语法分析：在执行SQL语句之前，数据库系统需要对SQL语句进行语法分析，以确定语句的正确性和有效性。
语义分析：语义分析是对SQL语句进行语义检查的过程，它用于确定SQL语句是否符合数据库的逻辑结构和语义规范，例如表是否存在、列是否匹配等。
权限检查：权限检查是指对用户对数据库的访问权限进行检查，以确定用户是否有执行该SQL语句的权限。
查询优化：在执行查询操作时，数据库系统需要对查询进行优化，以提高查询的性能和效率。这个过程包括选择最佳的查询算法、选择最佳的索引等。
执行计划生成：在查询优化的过程中，数据库系统会生成一份执行计划，用于指导数据库引擎执行查询操作。
数据访问：在执行查询操作时，数据库引擎需要访问数据表，并对数据进行读取或更新操作。
结果集返回：当数据库引擎执行完查询操作后，会将结果集返回给客户端，供客户端进行进一步的处理和显示。
总之，SQL执行过程是一个复杂的过程，它需要数据库系统对SQL语句进行多个层次的处理和优化，以保证查询的正确性、高效性和安全性。
** 存储引擎（MYSQL）**
MySQL存储引擎是指用来存储和操作数据的底层软件组件，它可以影响到MySQL的性能、可靠性、可扩展性等方面。MySQL支持多种存储引擎，每种存储引擎都有其独特的优点和适用场景。以下是MySQL常见的几种存储引擎：
InnoDB：InnoDB是MySQL默认的存储引擎，它支持事务、行级锁、外键等特性，适用于需要强一致性和高并发读写的应用场景。
MyISAM：MyISAM是MySQL的另一种常用的存储引擎，它不支持事务、行级锁和外键，但具有快速的读写性能和高效的全文搜索功能，适用于读写分离的应用场景。
Memory：Memory存储引擎将数据存储在内存中，具有非常高的读写性能和快速的索引操作，但数据不支持持久化，适用于数据量较小且需要频繁读写的应用场景。
NDB：NDB存储引擎是MySQL Cluster的一部分，支持分布式架构和高可用性，适用于海量数据和高并发读写的应用场景。
Archive：Archive存储引擎适用于归档或历史数据存储，它具有压缩和快速插入的特点，但不支持索引和更新操作。
总之，在选择MySQL存储引擎时，需要根据应用场景的不同，综合考虑数据一致性、读写性能、可靠性、可扩展性等方面，选择最适合的存储引擎。
优化（MYSQL）
MySQL 的优化可以从多个方面入手，包括：
硬件层面的优化：例如升级 CPU、增加内存、使用 SSD 等方式来提高服务器性能。
数据库架构设计优化：例如合理设计表结构、建立索引、优化查询语句、使用分表等方式来提高数据库的读写效率。
MySQL 配置优化：例如修改 MySQL 的配置参数，调整缓存大小、连接池大小、最大连接数等参数，以提高 MySQL 的性能表现。
应用层面的优化：例如使用缓存、优化代码逻辑、减少数据库访问等方式来减轻数据库负载，提高应用的性能。
需要注意的是，每个应用场景和数据库环境都不同，优化方法也会有所差异。因此，在进行 MySQL 优化时，需要根据实际情况进行分析和优化。同时，需要注意在优化的过程中避免牺牲数据的一致性和安全性。
SQL优化是指对数据库查询语句进行分析和优化，以提高查询性能和效率的过程。以下是一些SQL优化的技巧和方法：
使用索引：通过为查询语句中涉及的列创建索引来加速查询，尤其是在大表中查询。
避免使用SELECT *：仅查询需要的列，而不是所有的列。
避免在WHERE子句中使用函数：函数的使用可能会导致索引失效，从而影响查询性能。
使用JOIN语句时，选择性能更高的连接方式：INNER JOIN比LEFT JOIN和RIGHT JOIN更快。
避免使用子查询：子查询可能会导致性能问题，可以使用JOIN语句代替。
分页查询时，使用LIMIT关键字：使用LIMIT来限制结果集的大小，而不是查询所有结果。
使用连接池：连接池可以帮助管理数据库连接，避免频繁的创建和销毁连接。
对表进行分区：通过将表分成多个部分来提高查询性能，这样可以减少I/O和锁定冲突。
优化查询语句的结构：避免在一个查询语句中同时使用多个AND或OR操作符，这样会导致查询效率下降。
定期维护数据库：删除不需要的数据、重建索引、分析表等，以保证数据库的健康运行
分库分表、读写分离
分库分表和读写分离都是常用的数据库优化手段。
分库分表是指将一个大型数据库拆分成多个小型数据库，每个小型数据库负责处理一部分数据，从而达到提高数据库性能和扩展性的目的。
读写分离是指将数据库的读和写分开处理，读请求和写请求分别由不同的服务器来处理。这样可以减轻主库的读写压力，提高数据库的并发能力和吞吐量，同时也提高了系统的可用性。
在实际应用中，分库分表和读写分离通常是同时使用的。将一个大型数据库拆分成多个小型数据库后，再使用读写分离来提高数据库的性能和可用性。
读写分离是指在数据库架构设计中，将读操作和写操作分别分配到不同的数据库服务器上进行处理。这样可以将读操作分担到多台服务器上，从而提高系统的并发处理能力和读取性能。
一般来说，读操作的频率远高于写操作，因此采用读写分离可以有效地提高数据库的处理性能。在实际应用中，通常会采用主从复制的方式实现读写分离。主数据库负责写操作，从数据库负责读操作，主从数据库之间通过二进制日志进行数据同步。
实现读写分离的步骤如下：
配置主从数据库：在主数据库上开启二进制日志，并将从数据库配置为主数据库的从服务器。
读写分离应用程序：在应用程序中，通过配置连接字符串来实现读写分离。一般来说，写操作需要连接主数据库，而读操作需要连接从数据库。
数据同步策略：主数据库和从数据库之间的数据同步策略可以通过配置来实现。例如，可以设置从数据库每隔一段时间从主数据库进行数据同步，或者在主数据库发生写操作时，立即将数据同步到从数据库等。
需要注意的是，读写分离只是一种数据库性能优化的策略之一，具体的实现方式需要根据实际情况进行调整和优化，以确保系统的性能和稳定性。
**执行计划 ** 执行计划（Execution Plan）是指数据库在执行 SQL 查询时，生成的一份详细的查询计划，包含了执行 SQL 查询所需要的所有步骤，包括连接方式、操作方式、数据访问路径、索引使用情况等。执行计划的主要作用是帮助开发者和 DBA 分析 SQL 查询性能问题，优化查询，提高数据库查询效率。
执行计划可以通过 SQL 语句前加上 explain 命令来获取，这样可以让数据库解释器解释 SQL 语句的执行计划，而不会执行该 SQL 语句本身。
执行计划通常包含以下几个重要的信息：
执行查询所需要的表（包括临时表）
数据库在执行查询时所使用的索引
数据库在执行查询时所采用的连接方式（如全表扫描、索引扫描、聚合等）
每个执行步骤所耗费的时间、操作记录数等信息
通过分析执行计划，可以找出查询中存在的性能问题和瓶颈，以此进行优化和改进，提高查询效率
跟进慢查询sql
慢查询定位
Show status like ‘uptime’
统计sql执行次数
语句：Show [session|global] status like 默认session级别统计，全局带参数global
Show status like ‘com_update’
Show status like ‘com_insert’
--- delete ,connection
Show status like ‘query_queries’ 显示慢查询统计
Show variables like ‘long_query_time’ 查看慢查询默认时间，默认10秒为慢查询
Set long_query_time =1 修改慢查询时间
慢查询优化：索引
查看索引：show index from 表名
增加 ：alter table 表名 add primary key(列名)/create unique index 索引名 on （列表）
删除：alter table 表名 drop index 索引名
修改：删除后创建
在数据库事务中，传播属性指的是事务方法调用时如何处理事务的范围和行为，而隔离级别则指的是在多个事务同时访问相同数据时，每个事务所看到的数据状态的隔离程度。
常见的传播属性包括：
PROPAGATION_REQUIRED：如果当前有事务存在，则加入到当前事务中执行，否则新建一个事务。应用场景：需要保证多个操作在同一事务中进行，如果有任何一个操作失败，则回滚所有操作
PROPAGATION_REQUIRES_NEW：无论当前是否有事务存在，都将创建一个新的事务执行。应用场景：需要保证某些操作在一个新的事务中执行，不受当前事务的影响。
PROPAGATION_SUPPORTS：如果当前有事务存在，则加入到当前事务中执行，否则以非事务方式执行。应用场景：需要在有事务的情况下执行某些操作，但不要求这些操作必须在同一事务中进行。
PROPAGATION_NOT_SUPPORTED：以非事务方式执行，如果当前有事务存在，则挂起该事务。应用场景：某些操作不需要在事务中执行，或者不希望当前事务对该操作产生影响。
PROPAGATION_MANDATORY：当前必须存在一个事务，否则抛出异常。应用场景：某些操作必须在事务中执行，否则抛出异常。
PROPAGATION_NEVER：当前不能存在事务，否则抛出异常。应用场景：某些操作不允许在事务中执行，否则抛出异常。
PROPAGATION_NESTED
在当前事务中嵌套一个新的事务执行，如果存在事务，则在该事务中嵌套子事务；如果不存在事务，则创建新事务执行。
应用场景：需要将某些操作作为一个整体来处理，但是又需要保证某些操作在子事务中执行。
常见的隔离级别包括：
READ UNCOMMITTED（读未提交）：一个事务可以读取另一个事务未提交的数据，可能导致脏读、不可重复读、幻读等问题。
READ COMMITTED（读已提交）：一个事务只能读取另一个事务已提交的数据，可以避免脏读问题，但仍可能出现不可重复读、幻读等问题。
REPEATABLE READ（可重复读）：在同一个事务中，多次读取同一个数据时，结果是一致的，可以避免脏读和不可重复读问题，但仍可能出现幻读问题。
SERIALIZABLE（串行化）：事务串行执行，避免了脏读、不可重复读、幻读等问题，但性能较差。
在实际应用中，需要根据业务场景和数据安全性要求选择适当的传播属性和隔离级别。