首页 > 数据库 >MySQL面试相关精选

MySQL面试相关精选

时间：2024-08-19 18:26:30浏览次数：11  
标签：事务 索引 精选 查询 面试 MySQL 数据 节点

一、数据库三大范式

  1. 第一范式：1NF 原子性
    列或者字段不能再分，要求属性具有原子性，不可再分解；单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
  2. 第二范式：2NF 唯一性
    一张表只说一件事，是对记录的惟一性约束，要求记录有惟一标识。
  3. 第三范式：3NF 直接性
    数据不能存在传递关系，即每个属性都跟主键有直接关系，而不是间接关系。

二、数据库 ACID 特性

  1. 原子性
    事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用。
  2. 一致性
    执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的。
  3. 隔离性
    并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的。
  4. 持久性
    一个事务被提交之后，它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

三、MYSQL 内连接和外连接的区别

内连接会取出连接表中匹配到的数据，匹配不到的不保留；
外连接会取出连接表中匹配到的数据，匹配不到的也会保留，其值为 NULL。

  • 左外连接，以左边的表为主表
  • 右外连接，以右边的表为主表

以某一个表为主表后，进行关联查询，不管能不能关联的上，主表的数据都会保留，关联不上的以 NULL 显示

四、CHAR 和 VARCHAR 的区别

  1. 最大长度：char 最大长度是 255 字符，varchar 最大长度是 65535 个字节。
  2. 定长：char 是定长的，不足的部分用隐藏空格填充，varchar 是不定长的。
  3. 空间使用：char 会浪费空间，varchar 会更加节省空间。
  4. 查找效率：char 查找效率会很高，varchar 查找效率会更低。varchar 需要计算内容占用的长度，而 char 不会，所以 char 的效率稍高一些

在项目中的使用，这两种方式都会用到，比如像一些枚举值可以选择使用 char，像一些描述信息或名字类可以选择使用 varchar

五、并发事务带来的问题

  1. 脏读（Dirty read）
    当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。
  2. 丢失修改（Lost to modify）
    指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务 1 读取某表中的数据 A=20，事务 2 也读取 A=20，事务 1 修改 A=A-1，事务 2 也修改 A=A-1，最终结果 A=19，事务 1 的修改被丢失。
  3. 不可重复读（Unrepeatable read）
    指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。
  4. 幻读（Phantom read）
    幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

六、数据库事务隔离级别

  1. READ-UNCOMMITTED(读取未提交)：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
  2. READ-COMMITTED(读取已提交)：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
  3. REPEATABLE-READ(可重复读)：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
  4. SERIALIZABLE(可串行化)：最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

事务隔离级别越严格，数据库效率越低。MySQL 默认的事务隔离级别是：REPEATABLE-READ级别，简称 RR 级别。

七、查询语句执行流程

执行 SQL 语句 select * from user where id = 1 时发生了以下过程：

  1. 连接器：负责建立连接、检查权限、连接超时时间由 wait_timeout 控制，默认 8 小时。
  2. 查询缓存：会将 SQL 和查询结果以键值对方式进行缓存，修改操作会以表单位导致缓存失效。
  3. 分析器：进行词法、语法分析。
  4. 优化器：决定用哪个索引，决定表的连接顺序等。
  5. 执行器：根据存储引擎类型，调用存储引擎接口。
  6. 存储引擎：数据的读写接口，索引、表都在此层实现。

八、UNION 与 UNION ALL 的区别

UNION 用于把来自多个 SELECT 语句的结果组合到一个结果集合中，MySQL 会把结果集中重复的记录删掉。

而使用 UNION ALL，MySQL 会把所有的记录返回，且效率高于 UNION 。

九、MySQL 索引

（一）MySQL 存储引擎对比

常用的存储引擎：

  1. MyISAM 存储引擎
    • 事务安全：不支持
    • 锁机制：表锁
    • 外键：不支持
    • 特性：访问快，不支持事务和外键。表结构保存在 .frm 文件中，表数据保存在 .MYD 文件中，索引保存在 .MYI 文件中。
  2. InnoDB 存储引擎（MySQL 5.5 版本后默认的存储引擎）
    • 事务安全：支持
    • 锁机制：表锁/行锁
    • 外键：支持
    • 特性：支持事务，占用磁盘空间大，支持并发控制。表结构保存在 .frm 文件中，如果是共享表空间，数据和索引保存在 innodb_data_home_dir 和 innodb_data_file_path 定义的表空间中，可以是多个文件。如果是多表空间存储，每个表的数据和索引单独保存在 .ibd 中。
  3. MEMORY 存储引擎
    • 事务安全：不支持
    • 锁机制：不支持
    • 外键：不支持
    • 特性：内存存储，速度快，不安全，适合小量快速访问的数据。表结构保存在 .frm 中。
特性MyISAMInnoDBMEMORY
事务安全不支持支持不支持
锁机制表锁表锁/行锁表锁
外键不支持支持不支持

（二）索引的类型

  1. 从数据结构角度
    • 树索引（O(log(n))）
    • Hash 索引
  2. 从物理存储角度
    • 聚集索引（clustered index）
    • 非聚集索引（non-clustered index）
  3. 从逻辑角度
    • 普通索引
    • 唯一索引
    • 主键索引
    • 联合索引

十、MySQL 索引失效的原因

在 MySQL 中，索引失效可能由以下原因导致：

  1. 使用 LIKE 没有遵循左前缀匹配规则，使用 != 、 <> 、 not in 等关键字。
    • 例如：SELECT * from user_1 where username like '%ack10%'
  2. 使用 != 、 <> 、 not in 等关键字。
    • 例如：EXPLAIN SELECT * from user_1 where username!= 'jack10'
  3. 在索引列上进行计算。
  4. 在索引列上进行隐式的类型转换（如使用雪花算法生成 18 位的字符串存储，查询时使用数值来查询）。
    • 例如：SELECT * from user_1 where username!= 'jack10' ，SELECT * from user_1 where id + 1 = 2;
  5. 使用 is null 或 is not null 等关键字。
    • 例如：EXPLAIN SELECT * from user_1 where identity is not null;
  6. 使用 or 或者 in 关键字（会导致在索引列上进行多次查找）。
    • 例如：EXPLAIN SELECT * from user_1 WHERE username = 'jack10' or identity = '11'
  7. 联合索引的左匹配原则。在 MySQL 建立联合索引时遵循左前缀匹配原则，即最左优先。在检索数据时从联合索引的最左边开始匹配，组合索引的第一个字段必须出现在查询组句中，这个索引才会被用到。
    • 例如：create index index_age_name_sex on tb_user(age, name, sex) ，实际上建立了 (age) 、 (age, name) 、 (age, name, sex) 三个索引。

十一、B 树

B-Tree，B 树是一种多叉路衡查找树，相对于二叉树，B 树每个节点可以有多个分支，即多叉。

以一颗最大度数（max-degree）为 5（5 阶）的 B-Tree 为例，这个 B 树每个节点最多存储 4 个 key，5 个指针。

知识小贴士：树的度数指的是一个节点的子节点个数。

插入一组数据：100 65 169 368 900 556 780 35 215 1200 234 888 158 90 1000 88 120 268 250 。然后观察一些数据插入过程中，节点的变化情况。

特点：

5 阶的 B 树，每一个节点最多存储 4 个 key，对应 5 个指针。

一旦节点存储的 key 数量到达 5，就会裂变，中间元素向上分裂。

在 B 树中，非叶子节点和叶子节点都会存放数据。

十二、B+树

B+Tree 是 B-Tree 的变种，以一颗最大度数（max-degree）为 4（4 阶）的 B+Tree 为例，来看其结构示意图：

我们可以看到，分为两部分：

绿色框框起来的部分，是索引部分，仅仅起到索引数据的作用，不存储数据。

红色框框起来的部分，是数据存储部分，在其叶子节点中要存储具体的数据。

最终我们看到，B+Tree 与 B-Tree 相比，主要有以下三点区别：

  1. 所有的数据都会出现在叶子节点。
  2. 叶子节点形成一个单向链表。
  3. 非叶子节点仅仅起到索引数据作用，具体的数据都是在叶子节点存放的。

上述我们所看到的结构是标准的 B+Tree 的数据结构，接下来，我们再来看看 MySQL 中优化之后的 B+Tree。

MySQL 索引数据结构对经典的 B+Tree 进行了优化。在原 B+Tree 的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的 B+Tree，提高区间访问的性能，利于排序。

十三、为什么 InnoDB 存储引擎选用 B+树而不是 B 树

B+树是基于 B 树和叶子节点顺序访问指针进行实现，它具有 B 树的平衡性，并且通过顺序访问指针来提高区间查询的性能。

在 B+树中，一个节点中的 key 从左到右非递减排列，如果某个指针的左右相邻 key 分别是 key i 和 key i+1，且不为 null，则该指针指向节点的所有 key 大于等于 key i 且小于等于 key i+1。

进行查找操作时，首先在根节点进行二分查找，找到一个 key 所在的指针，然后递归地在指针所指向的节点进行查找。直到查找到叶子节点，然后在叶子节点上进行二分查找，找出 key 所对应的 data。

插入、删除操作会破坏平衡树的平衡性，因此在插入删除操作之后，需要对树进行一个分裂、合并、旋转等操作来维护平衡性。

用 B+树不用 B 树考虑的是 IO 对性能的影响，B 树的每个节点都存储数据，而 B+树只有叶子节点才存储数据，所以查找相同数据量的情况下，B 树的高度更高，IO 更频繁。数据库索引是存储在磁盘上的，当数据量大时，就不能把整个索引全部加载到内存了，只能逐一加载每一个磁盘页（对应索引树的节点）。

十四、索引创建原则

  1. 针对于数据量较大，且查询比较频繁的表建立索引。
  2. 针对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引。
  3. 尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。
  4. 如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引。
  5. 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率。
  6. 要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率。
  7. 如果索引列不能存储 NULL 值，请在创建表时使用 NOT NULL 约束它。当优化器知道每列是否包含 NULL 值时，它可以更好地确定哪个索引最有效地用于查询。

十五、什么是聚簇索引什么是非聚簇索引

在InnoDB存储引擎中，根据索引的存储形式，又可以分为以下两种：

分类含义特点
聚集索引（Clustered Index）将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据必须有，而且只有一个
二级索引（Secondary Index）将数据与索引分开存储，索引结构的叶子节点关联的是对应的主键可以存在多个

聚集索引选取规则:

  1. 如果存在主键，主键索引就是聚集索引。
  2. 如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引。
  3. 如果表没有主键，或没有合适的唯一索引，则 InnoDB 会自动生成一个 rowid 作为隐藏的聚集索引。

聚集索引的叶子节点下挂的是这一行的数据，二级索引的叶子节点下挂的是该字段值对应的主键值。

十六、MySQL 锁

（一）MySQL 中的锁分类

MySQL 中的锁，按照锁的粒度分，分为以下三类：

  1. 全局锁：锁定数据库中的所有表。
  2. 表级锁：每次操作锁住整张表。
  3. 行级锁：每次操作锁住对应的行数据。

（二）MySQL 的行锁和表锁

  1. MyISAM 只支持表锁，InnoDB 支持表锁和行锁，默认为行锁。
  2. 表级锁：开销小，加锁快，不会出现死锁。锁定粒度大，发生锁冲突的概率最高，并发量最低。
  3. 行级锁：开销大，加锁慢，会出现死锁。锁力度小，发生锁冲突的概率小，并发度最高。

（三）共享锁和排他锁

InnoDB 实现了以下两种类型的行锁：

  1. 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
  2. 排他锁（X）：允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁。

常见的 SQL 语句，在执行时，所加的行锁如下：

SQL行锁类型说明
INSERT…排他锁自动加锁
UPDATE…排他锁自动加锁
DELETE…排他锁自动加锁
SELECT（正常）不加任何锁自动加锁
SELECT… LOCK IN SHARE MODE共享锁需要手动在 SELECT 之后加
SELECT… FOR UPDATE排他锁需要手动在 SELECT 之后加

十七、MySQL 的 redo log、undo log、binlog

  1. binlog（归档日志 - 二进制日志）
    • 用于复制，在主从复制中，从库利用主库上的 binlog 进行重播，实现主从同步。用于数据库的基于时间点的还原。
    • 内容：逻辑格式的日志，可以简单认为就是执行过的事务中的 sql 语句。但又不完全是 sql 语句这么简单，而是包括了执行的 sql 语句（增删改）反向的信息，也就意味着 delete 对应着 delete 本身和其反向的 insert；update 对应着 update 执行前后的版本的信息；insert 对应着 delete 和 insert 本身的信息。
    • binlog 有三种模式：Statement（基于 SQL 语句的复制）、Row（基于行的复制）以及 Mixed（混合模式）
  2. redo log（重做日志）
    • 作用：确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启 mysql 服务的时候，根据 redo log 进行重做，从而达到事务的持久性这一特性。
    • 内容：物理格式的日志，记录的是物理数据页面的修改的信息，其 redo log 是顺序写入 redo log file 的物理文件中去的。
  3. undo log（回滚日志）
    • 作用：保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。
    • 内容：逻辑格式的日志，在执行 undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于 redo log 的。

十八、主从同步

（一）主从同步原理

MySQL 主从复制的核心就是二进制日志，二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。

具体的主从同步过程如下：

  1. Master 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。
  2. 从库读取主库的二进制日志文件 Binlog，写入到从库的中继日志 Relay Log 。
  3. slave 重做中继日志中的事件，将改变反映它自己的数据。

（二）主从同步延时及解决方法

主从同步延时的原因：

  1. MySQL 的主从复制都是单线程的操作，主库对所有 DDL 和 DML 产生的日志写进 binlog，由于 binlog 是顺序写，所以效率很高。Slave 的 SQL Thread 线程将主库的 DDL 和 DML 操作事件在 slave 中重放。DML 和 DDL 的 IO 操作是随机的，不是顺序的，成本高很多。所以 SQL Thread 线程的速度赶不上主库写 binlog 的速度，就会产生主从延迟。
  2. 另一方面，由于 SQL Thread 也是单线程的，当主库的并发较高时，产生的 DML 数量超过 slave 的 SQL Thread 所能处理的速度，或者当 slave 中有大型 query 语句产生了锁等待，那么延时就产生了。

解决方案：

  1. 强制读主库：如果是类似支付这种对实时性要求非常高的业务，最直接的方法就是直接读主库，当然这种方法相当于从库做一个备份的功能了。
  2. 延迟读：在写入之后，等一段时间再读。比如写入后同步的时间是 0.5s，读取的时候可以设置 1s 后再读，但是这个方案主要存在的问题就是，不知道主从同步完成所需要的时间。
  3. 降低并发：控制主库写入的速度，主从延迟发生的概率自然就小了。
  4. 并行复制（推荐）：MySQL 5.6 版本后，提供了一种并行复制的方式，通过将 SQL 线程转换为多个 work 线程来进行重放，这样就解决了主从延迟的问题。

十九、MySQL 读写分离的实现方案

MySQL 读写分离的实现方式主要基于主从复制，通过路由的方式使应用对数据库的写请求只在 Master 上进行，读请求在 Slave 上进行。

具体地，有以下四种实现方案：

  1. 基于 MySQL proxy 代理：在应用和数据库之间增加代理层，代理层接收应用对数据库的请求，根据不同请求类型（即是读 read 还是写 write）转发到不同的实例，在实现读写分离的同时可以实现负载均衡。MySQL 的代理最常见的是 mysql-proxy、cobar、mycat、Atlas 等。
  2. 基于应用内路由：基于应用内路由的方式即为在应用程序中实现，针对不同的请求类型去不同的实例执行 SQL。具体实现可基于 spring 的 aop：用 aop 来拦截 spring 项目的 dao 层方法，根据方法名称就可以判断要执行的类型，进而动态切换主从数据源。
  3. 基于 MySQL-Connector-Java 的 JDBC 驱动方式：Java 程序通过在连接 MySQL 的 JDBC 中配置主库与从库等地址，JDBC 会自动将读请求发送给从库，将写请求发送给主库，此外，MySQL 的 JDBC 驱动还能够实现多个从库的负载均衡。
  4. 基于 sharding-jdbc 的方式：sharding-sphere 是强大的读写分离、分表分库中间件，sharding-jdbc 是 sharding-sphere 的核心模块。

二十、MySQL 优化

（一）MySQL 数据库 CPU 飙升到 500%的处理方法

当 CPU 飙升到 500%时，先用操作系统命令 top 命令观察是不是 mysqld 占用导致的，如果不是，找出占用高的进程，并进行相关处理。如果是 mysqld 造成的，show processlist，看看里面跑的 session 情况，是不是有消耗资源的 sql 在运行。找出消耗高的 sql，看看执行计划是否准确，index 是否缺失，或者实在是数据量太大造成。

一般来说，肯定要 kill 掉这些线程（同时观察 cpu 使用率是否下降），等进行相应的调整（比如说加索引、改 sql、改内存参数）之后，再重新跑这些 SQL。也有可能是每个 sql 消耗资源并不多，但是突然之间，有大量的 session 连进来导致 cpu 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等。

MySQL 性能优化：SQL 语句执行慢的分析与处理

一、开启 MySQL 的慢查询日志

慢查询日志记录了所有执行时间超过指定参数（long_query_time，单位：秒，默认 10 秒）的所有 SQL 语句的日志。

如果要开启慢查询日志，需要在 MySQL 的配置文件（/etc/my.cnf）中配置如下信息：

# 开启 MySQL 慢日志查询开关
slow_query_log=1
# 设置慢日志的时间为 2 秒，SQL 语句执行时间超过 2 秒，就会视为慢查询，记录慢查询日志
long_query_time=2

配置完毕之后，通过以下指令重新启动 MySQL 服务器进行测试，查看慢日志文件中记录的信息 /var/lib/mysql/localhost-slow.log。如果这个时候有一条 SQL 执行的时间超过 2 秒，则会记录到慢日志文件中。

二、使用 Explain 命令查询 SQL 语句执行计划

采用 EXPLAIN 或者 DESC 命令获取 MySQL 如何执行 SELECT 语句的信息，包括在 SELECT 语句执行过程中表如何连接和连接的顺序。

语法：

-- 直接在 select 语句之前加上关键字 explain / desc
EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件;

Explain 执行计划中各个字段的含义：

字段含义
select_typeselect 查询的序列号，表示查询中执行 select 子句或者是操作表的顺序（id 相同，执行顺序从上到下；id 不同，值越大，越先执行）。
type表示 SELECT 的类型，常见的取值有 SIMPLE（简单表，即不使用表连接或者子查询）、PRIMARY（主查询，即外层的查询）、UNION（UNION 中的第二个或者后面的查询语句）、SUBQUERY （SELECT/WHERE 之后包含了子查询）等
key实际使用的索引，如果为 NULL，则没有使用索引。
rowsMySQL 认为必须要执行查询的行数，在 InnoDB 引擎的表中，是一个估计值，可能并不总是准确的。
filtered表示返回结果的行数占需读取行数的百分比，filtered 的值越大越好。
Extra额外的建议

主要可以根据以下字段，判断 sql 是否需要优化，特别是是否能命中索引或命中索引的情况：

  • type：通过 sql 的连接的类型进行优化。
  • possible_key：通过它查看是否可能会命中索引。
  • key：当前 sql 实际命中的索引。
  • key_len：索引占用的大小。
  • Extra：额外的优化建议。

三、MySQL 超大分页的处理

在数据量比较大时，如果进行 limit 分页查询，在查询时，越往后，分页查询效率越低。

通过测试我们会看到，越往后，分页查询效率越低，这就是分页查询的问题所在。因为，当在进行分页查询时，如果执行 limit 2000000,10 ，此时需要 MySQL 排序前 2000010 记录，仅仅返回 2000000 - 2000010 的记录，其他记录丢弃，查询排序的代价非常大 。

优化思路：一般分页查询时，通过创建覆盖索引能够比较好地提高性能，可以通过覆盖索引加子查询形式进行优化。

explain select * from tb_sku t, (select id from tb_sku order by id limit 2000000,10) a where t.id = a.id;

四、对 SQL 优化的经验

（一）表的设计优化

  1. 选择表合适存储引擎：
    • myisam：应用时以读和插入操作为主，只有少量的更新和删除，并且对事务的完整性，并发性要求不是很高的。
    • Innodb：事务处理，以及并发条件下要求数据的一致性。除了插入和查询外，包括很多的更新和删除。尽量设计所有字段都得有默认值，尽量避免 null。
  2. 选择合适的数据类型
    • 数据库表设计时候更小的占磁盘空间尽可能使用更小的整数类型，一般来说，数据库中的表越小，在它上面执行的查询也就会越快。
    • 比如设置合适的数值（tinyint 、int 、bigint），要根据实际情况选择。
    • 比如设置合适的字符串类型（char 和 varchar），char 定长效率高，varchar 可变长度，效率稍低。

（二）索引优化

  1. 表的主键、外键必须有索引。
  2. 数据量大的表应该有索引。
  3. 经常与其他表进行连接的表，在连接字段上应该建立索引。
  4. 经常出现在 Where 子句中的字段，特别是大表的字段，应该建立索引。
  5. 索引应该建在选择性高的字段上（sex 性别这种就不适合）。
  6. 索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引。
  7. 频繁进行数据操作的表，不要建立太多的索引。
  8. 删除无用的索引，避免对执行计划造成负面影响。

（三）SQL 语句优化

  1. SELECT 语句务必指明字段名称（避免直接使用 select * ） 。
  2. SQL 语句要避免造成索引失效的写法。
  3. SQL 语句中 IN 包含的值不应过多。
  4. 当只需要一条数据的时候，使用 limit 1 。
  5. 如果排序字段没有用到索引，就尽量少排序。
  6. 如果限制条件中其他字段没有索引，尽量少用 or 。
  7. 尽量用 union all 代替 union 。
  8. 避免在 where 子句中对字段进行 null 值判断。
  9. 不建议使用 % 前缀模糊查询。
  10. 避免在 where 子句中对字段进行表达式操作。

（四）Join 优化

能用 inner join 就不用 left join 、right join ，如必须使用，一定要以小表为驱动。

（五）主从复制、读写分离

如果数据库的使用场景读的操作比较多的时候，为了避免写的操作所造成的性能影响，可以采用读写分离的架构，读写分离，解决的是，数据库的写入，影响了查询的效率。读写分离的基本原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理 SELECT 查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。

标签：事务,索引,精选,查询,面试,MySQL,数据,节点
From： https://blog.csdn.net/Founder_Xiao_Xin/article/details/141331959

相关文章

  • 【面试】事务的ACID特性有哪些？是如何保证的？
    面试模拟场景面试官:你能解释一下事务的ACID特性有哪些？是如何保证的？参考回答示例候选人:当然可以。事务的ACID特性是数据库系统中保证数据一致性和可靠性的关键特性。ACID是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）的缩写。以下是每个......
  • Linux 安装Mysql详细教程
    前言本文主要介绍在Linux环境下安装MySQL的过程。1:下载MySQL5.7的rpm安装包选择合适的版本，这里我们使用的是MySQL5.7.20；下载完成后发送到自己的CentOS7服务器里，这里可以通过Xftp上传MySQLhttps://www.mysql.com/1.在根目录下创建一个mysqlpackage目录mkdirmysqlpa......
  • 【面试】介绍几种常见的进程调度算法及其流程
    面试模拟场景面试官:你能介绍一下几种常见的进程调度算法及其流程吗？参考回答示例进程调度是操作系统管理进程的核心功能，负责在多任务环境中分配CPU时间给各个进程。常见的进程调度算法包括先来先服务（FCFS）、短作业优先（SJF）、优先级调度、轮转调度（RR）以及多级反馈队列调度等......
  • 【面试】阐述TCP和UDP的区别
    面试模拟场景面试官:你能阐述一下TCP和UDP的区别吗？###参考回答示例1.连接性TCP:面向连接（Connection-Oriented）:TCP是一种面向连接的协议，在传输数据之前需要建立连接。在TCP通信过程中，客户端和服务器之间通过“三次握手”来建立连接，然后再进行数据传输，确保两者之间的......
  • 国产操作系统 离线部署MYSQL、NGINX、redis、JDK1.8
    目录1.1、龙蜥操作系统8.4【AnolisOS8.4GA】1.2、安装关键步骤说明2.1、安装必要的系统组件2.2、配置JDK2.3、安装redis2.4、安装nginx2.5、安装mysql3.1、启用防火墙3.2、开放业务端口3.3、修改SSH端口号为100223.4、配置特定端口指定IP访问4.1、网络设置4.2......
  • docker 创建MySQL
    dockerrun\      --restart=always\  #这个参数是mysql在docker启动的时候，也会跟着自动启动--namemysql8.0\   #这个参数是mysql容器的名字-p3306:3306\    #这个参数是端口号映射-eMYSQL_ROOT_PASSWORD=root\  #这个参数是是设......
  • MySQL中处理JSON数据：大数据分析的新方向
    1.简介1.1.概述在MySQL中处理JSON数据的能力是在MySQL5.7版本中引入的，并在后续的版本中不断得到增强。这使得MySQL能够直接操作和查询JSON格式的数据，极大地扩展了其处理复杂数据结构的能力。1.2.主要特点灵活性与可扩展性：JSON允许开发者存储不规则和嵌套的数据结......
  • 测试环境治理之MYSQL索引优化篇
    1治理背景测试环境这个话题对于开发和测试同学一定不陌生，大家几乎每天都会接触。但是说到对测试环境的印象，却鲜有好评:•环境不稳定，测试五分钟，排查两小时•基础建设不全，导致验证不充分，遗漏缺陷•多人共用，节点堵塞这些问题在行业内其实屡见不鲜，针对测试环境的治理，不得不引起......
  • MYSQL排它锁获取机制
    在数据库系统中，排他锁（ExclusiveLock）用于确保在一个事务对数据进行修改时，其他事务无法访问或修改相同的数据。这种机制确保了数据的完整性和一致性。获取排他锁的方式包括自动获取和手动获取，下面我将详细整理这两种方式的机制。自动获取排他锁行级别的排他锁（自动）场景：当你执......
  • MySQL 排他锁之表级锁：使用与实例详解
    在数据库系统中，锁机制是确保数据一致性、完整性的重要手段。MySQL中的排他锁（ExclusiveLock）是防止数据在修改过程中被其他事务访问或修改的关键工具。排他锁不仅可以作用于单行数据，还可以作用于整个表。当排他锁用于表级别时，它可以阻止其他事务对表的任何操作，从而确保数据的一致性......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99