本文深入剖析了MySQL数据库在面试中的热点问题，包括索引（B+树原理、聚集与非聚集索引、自增主键选择）、事务（ACID特性、并发问题与隔离级别）、InnoDB与MyISAM引擎对比，以及主从复制机制。同时，探讨了日志在服务层与引擎层的应用，并分析了数据库锁类型及其在性能优化中的角色。
大厂面试---Redis面试题（含答案，相关知识点，面试考察次数统计）_安吉_lh1029的博客-CSDN博客
大厂面试问答题汇总分析---数据库（索引-聚集/非聚集，事务，mySql, 锁）_安吉_lh1029的博客-CSDN博客
大厂面试问答题汇总分析---网络安全类问题_安吉_lh1029的博客-CSDN博客
大厂面试问答题汇总分析--- 秒杀 / 限流 / 高并发_安吉_lh1029的博客-CSDN博客
【锁】的相关概念汇总_安吉_lh1029的博客-CSDN博客
大厂面试问答题汇总分析--- 多线程问题_安吉_lh1029的博客-CSDN博客
概目录
1-2、mysql为什么使用B+树？与B树的比较，为什么使用B+树不用B树？
1-3、其他数据结构（二叉查找树，平衡二叉树，红黑树，hash）的区别？其他数据结构不选用索引的原因
1-4、聚集索引 VS 非聚集索引 的区别？MyisAM和innodb引擎相关问题
2-2-4、Myql中的事务回滚机制,持久性，隔离级别的实现
【数据库】相关面试题及知识点答案
【超高频】一、索引相关问题
1-1、mysql索引数据结构？
索引结构：排好序的快速查找数据结构。索引会影响where后面的查找，和order by 后面的排序。
B+Tree索引（平衡多路查找树）:数据都在叶子节点上，并且增加了顺序访问指针，每个叶子节点都指向相邻的叶子节点的地址。
1-2、mysql为什么使用B+树？与B树的比较，为什么使用B+树不用B树？
1】B+树【访问磁盘IO次数少】的特点：非叶子节点上是不存储数据的，仅存储键值 ｜B树区别：每个节点存储了 键值 和 数据，因此B+树更矮，磁盘IO次数少
2】B+树【更适合范围查询】的特点：所有数据均存储在叶子节点，而且数据是按照顺序排列的，只要遍历叶子节点就可实现整棵树的遍历，且数据库中基于【范围的查询】是非常频繁的 ｜ B树区别: 【中序遍历】所有节点，效率太低
3】B+树 各页之间通过双向链表连接，叶节点是通过单向链表连接
1-3、其他数据结构（二叉查找树，平衡二叉树，红黑树，hash）的区别？其他数据结构不选用索引的原因
| 其他数据结构 | 结构特点 | 不选用索引的原因 |
| 二叉查找树 | 左子节点<当前键值<右子节点 | 树的高度不均匀，不能自平衡，存在极端情况 |
| 平衡二叉树 | AVL树, 树的构造是平衡的 ,左右子树高度差的绝对值不超过1 | 每个节点只存储一个键值和数据，需要多次磁盘IO，查找数据效率极低 |
| 红黑树 | 1、每个节点，不是黑色，就是红色 2、根节点是黑色的 3、每个叶子节点都是黑色的 4、如果一个节点是红色的，那么它的叶子节点是黑色的 5、从一个节点到该节点的子孙节点的所有路径上都包含相同数量的黑色节点 | 树的高度随着数据量增加而增加，IO代价高。 |
| hash索引 | 键值对 key ：value （键 ：值） | 虽然可以快速定位，但是没有顺序，IO复杂度高 |
1-4、聚集索引 VS 非聚集索引 的区别？MyisAM和innodb引擎相关问题
非聚集索引和聚集索引的区别在于， 通过聚集索引可以查到需要查找的数据， 而通过非聚集索引可以查到记录对应的主键值 ， 再使用主键的值通过聚集索引查找到需要的数据（回表过程）。
MyISAM（ 非聚集）
B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。
MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。
InnoDB（ 聚集索引）
1、第一个重大区别是InnoDB的数据文件本身就是索引文件， 这棵树的叶节点data域保存了完整的数据记录。
但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。
2、InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有）
1）如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键
2）如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。（隐含字段）
简单说：
如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择其作为聚集索引；如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引；
innodb引擎的4大特性
插入缓冲（insert buffer),二次写(double write),自适应哈希索引(ahi),预读(read ahead)
1-5、MyisAM和innodb引擎的区别是什么？
可以查看 两个索引的区别点：MyISAM与InnoDB 的区别（9个不同点）_Chackca的博客-CSDN博客_innodb和myisam的区别
1. InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；
2. InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；
3. InnoDB是聚集索引，使用B+Tree作为索引结构，数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构），必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。
InnoDB的B+树主键索引的叶子节点就是数据文件，辅助索引的叶子节点是主键的值；而MyISAM的B+树主键索引和辅助索引的叶子节点都是数据文件的地址指针。
4. InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快（注意不能加有任何WHERE条件）；
5. Innodb不支持全文索引，而MyISAM支持全文索引，在涉及全文索引领域的查询效率上MyISAM速度更快高；PS：5.7以后的InnoDB支持全文索引了
6. MyISAM表格可以被压缩后进行查询操作
7. InnoDB支持表、行(默认)级锁，而MyISAM支持表级锁
8、InnoDB表必须有唯一索引（如主键）（用户没有指定的话会自己找/生产一个隐藏列Row_id来充当默认主键），而Myisam可以没有
9、Innodb存储文件有frm、ibd，而Myisam是frm、MYD、MYI
Innodb：frm是表定义文件，ibd是数据文件
Myisam：frm是表定义文件，myd是数据文件，myi是索引文件
如何选择：
1. 是否要支持事务，如果要请选择innodb，如果不需要可以考虑MyISAM；
2. 如果表中绝大多数都只是读查询，可以考虑MyISAM，如果既有读也有写，请使用InnoDB。
3. 系统奔溃后，MyISAM恢复起来更困难，能否接受；
4. MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM)，说明其优势是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不会差。
1-6、innodb为什么要用自增id作为主键？
方便插入操作：如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页
减少空间碎片：如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置， 频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE（optimize table）来重建表并优化填充页面。
自增ID可以保证每次插入时B+索引是从右边扩展的，可以避免B+树和频繁合并和分裂（对比使用UUID）。如果使用字符串主键和随机主键，会使得数据随机插入，效率比较差。
1-7、MySQL 索引使用的注意事项
函数，运算，否定操作符，连接条件，多个单列索引，最左前缀原则，范围查询，不会包含有NULL值的列，like 语句不要在列上使用函数和进行运算
1）不要在列上使用函数，运算，这将导致索引失效而进行全表扫描。
2）尽量避免使用 != 或 not in，not is null, 或 <> 等否定操作符 也尽量避免使用 like, order by, distinct , count (*)
3）多个单列索引并不是最佳选择，可以使用复合索引 ，复合索引的最左前缀原则
4）范围查询对多列查询的影响（注意范围查询带来的副作用，并且尽量少用范围查询）
查询中的某个列有范围查询，则其右边所有列都无法使用索引优化查找。
举例： select * from news where publish_time >= '2017-01-02' and publish_time <= '2017-01-08' and enable = 1；
因为范围查询对多列查询的影响，将导致 news_publish_idx(publish_time, enable) 索引中 publish_time 右边所有列都无法使用索引优化查找。换句话说，news_publish_idx(publish_time, enable) 索引等价于 news_publish_idx(publish_time) 。
1-8、in是否走索引？
in 通常是走索引的，当in后面的数据 在数据表中超过30% 的匹配时，会走全表扫描，即不走索引，因此in走不走索引和后面的数据有关系。
二、事务相关问题
2-1、事务四大特性（ACID）？
事务四大特性（ACID）原子性、一致性、隔离性、持久性
原子性：一个事务（transaction）中的所有操作，要么全部成功，要么全部失败回滚，会被恢复（Rollback）不会结束在中间某个环节。
一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。数据库的完整性（A向B转账，不可能A扣了钱，B却没收到）
隔离性：每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
持久性：一旦提交，对数据库中的数据的改变就永久性的，即便系统故障也不会丢失
2-2、事务的并发问题有哪些？事务的隔离级别
2-2-1、事务的并发问题
脏读是指在一个事务处理过程中读取了另一个事务未提交的数据。
不可重复读：对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值
幻读：事务非独立执行时发生的一种现象，即在一个事务读的过程中，另外一个事务可能插入了新数据记录，影响了该事务读的结果
【不可重复读】和【幻读】的区别： 不可重复读：是针对修改操作，对应锁行； 幻读：是针对 新增/删除， 对应锁表。
2-2-2、事务的隔离级别
事务隔离分为不同级别，包括 读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和 串行化（Serializable）。
引文：几率大的数据库（MySQL）面试题（含答案）__睶_的博客-CSDN博客_数据库mysql面试题
读未提交：就是一个事务能够看到其他事务尚未提交的修改，允许脏读出现.
读已提交：事务能够看到的数据都是其他事务已经提交的修改，也就是保证不会看到任何中间性状态，当然脏读也不会出现。
可重复读：保证同一个事务多次读取数据是一致的，这是 MySQL InnoDB 引擎的默认隔离级别，
串行化：并发事务之间是串行化的，通常意味着读取需要获取共享读锁，更新需要获取排他写锁，如果 SQL 使用 WHERE 语句，还会获取区间锁（MySQL 以 GAP 锁形式实现，可重复读级别中默认也会使用），这是最高的隔离级别。
MySQL的默认隔离级别就是Repeatable read，可重复读。Oracle 支持的 2 种事务隔离级别：READ_COMMITED 读已提交 , SERIALIZABLE 可串行化。
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大，鱼和熊掌不可兼得啊。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
2-2-3、如何解决幻读问题？
解决幻读（幻读仅专指“新插入的行）。新插入记录的这个动作，要更新的是记录之间的“间隙”， 因此InnoDB引入Gap Lock【间隙锁】，这样就确保无法再插入新记录
间隙锁是锁定索引记录之间的间隙，或者锁定第一个和最后一个记录之间的间隙。组织其他事务将值插入到这个间隙中来，间隙可能跨越单个索引值，多个索引值，也有可能为空。
可重复读级别下才会有间隙锁！！！
间隙锁定之间不存在冲突关系，这点也很重要。如果一个事务对某个间隙中间加了锁，那么其他事务也可以在这个间隙中加锁，这些操作不冲突。他的存在，仅仅是为了防止其他事务在这个间隙中插入记录。
2-2-4、Myql中的事务回滚机制,持久性，隔离级别的实现
而在 MySQL 中，恢复机制是通过 回滚日志（undo log）实现的，所有事务进行的修改都会先记录到这个回滚日志中，然后在对数据库中的对应行进行写入。 当事务已经被提交之后，就无法再次回滚了回滚日志作用：
1)能够在发生错误或者用户执行 ROLLBACK 时提供回滚相关的信息
2) 在整个系统发生崩溃、数据库进程直接被杀死后，当用户再次启动数据库进程时，还能够立刻通过查询回滚日志将之前未完成的事务进行回滚，这也就需要回滚日志必须先于数据持久化到磁盘上，是我们需要先写日志后写数据库的主要原因。
MySQL 使用重做日志（redo log）实现事务的持久性在数据库中，这两种日志经常都是一起工作的.隔离级别的实现。
数据库对于隔离级别的实现就是使用并发控制机制对在同一时间执行的事务进行控制，限制不同的事务对于同一资源的访问和更新.锁: 共享锁（Shared）和互斥锁（Exclusive），前者也叫读锁，后者叫写锁
时间戳:
使用时间戳实现事务的隔离性时，往往都会使用乐观锁，先对数据进行修改，在写回时再去判断当前值，也就是时间戳是否改变过，如果没有改变过，就写入，否则，生成一个新的时间戳并再次更新数据。
三、Mysql中日志及相应用法
MySQL数据最终是存放在【磁盘】中的，但磁盘I/O效率太低。因此InnoDB（又是这个NB引擎）为MySQL提供了缓冲池（BufferPool）。
3-1、mysql 中日志在【服务层】的用法，
3-1-1、主从复制过程
主从复制过程分了五个步骤：
-
主库的更新SQL(update、insert、delete)被写到binlog
-
从库发起连接，连接到主库。
-
此时主库创建一个 binlog dump thread ，把 bin log 的内容发送到从库。
-
从库启动之后，创建一个 I/O 线程，读取主库传过来的 bin log 内容并写入到 relay log
-
从库还会创建一个SQL线程，从 relay log 里面读取内容，从 ExecMasterLog_Pos 位置开始执行读取到的更新事件，将更新内容写入到 slave 的db
3-1-2、mysql异步，半同步和全同步区别是什么？
异步（MySQL默认的复制模式）。写入binlog，并不知道slave是否接收。缺点：不能保证所有事务都被所有slave接收。
半同步：至少有一个slave开启其功能，其余仍是异步模式。
全同步：直到事务在所有slave都已提交。缺点：完成一个事务可能造成延迟
binlog【数据库记录的改动日志】：主从复制，在多台设备间保持数据一致
3-1-3、数据库主从不一致怎么导致的？怎么解决？
参考博文：造成MySQL主从数据不一致的原因_一直在努力学习的菜鸟的博客-CSDN博客_mysql主从同步数据不一致原因
MySQL binlog 日志格式(Mixed,Statement,Row) - 百度文库
首先需要了解binlog的三种格式：binlog 日志格式(Mixed,Statement,Row)
mixed格式其实就是 row 和 statement 格式混合使用，当MySQL判断可能数据不一致时，就用 row 格式，否则使用就用 statement 格式。
1、主从不一致原因：
（1）主库binlog格式为Statement，同步到从库执行后可能造成主从不一致。
（2）主库执行更改前有执行set sql_log_bin=0，会使主库不记录binlog，从库也无法变更这部分数据。
（3）从节点未设置只读，误操作写入数据
（4）主库或从库意外宕机，宕机可能会造成binlog或者relaylog文件出现损坏，导致主从不一致
（5）主从实例版本不一致，特别是高版本是主，低版本为从的情况下，主数据库上面支持的功能，从数据库上面可能不支持该功能
（6）MySQL自身bug导致
2、如何避免主从不一致
（1）主库binlog采用ROW格式
（2）主从实例数据库版本保持一致
（3）主库做好账号权限把控，不可以执行set sql_log_bin=0
（4）从库开启只读，不允许人为写入
（5）定期进行主从一致性检验
3-1-4、数据库主从延迟的原因与解决方案？
主从延迟是怎么定义：
-
主库执行完一个事务，写入binlog，我们把这个时刻记为 T1 ；
-
主库同步数据给从库，从库接收完这个binlog的时刻，记录为 T2 ；
-
从库执行完这个事务，这个时刻记录为 T3 。
所谓主从延迟，其实就是指同一个事务，在从库执行完的时间和在主库执行完的时间差值，即 T3-T1 。
-
如果从库所在的机器比主库的 机器性能差，会导致主从延迟，这种情况比较好解决，只需选择 主从库一样规格的机器就好。
-
如果 从库的压力大，也会导致主从延迟。比如主库直接影响业务的，大家可能使用会 比较克制，因此一般 查询都打到从库了，结果导致从库查询消耗大量CPU，影响同步速度，最后导致主从延迟。这种情况的话，可以搞了 一主多从的架构，即多接几个从库分摊读的压力。另外，还可以把binlog接入到Hadoop这类系统，让它们提供查询的能力。
-
大事务也会导致主从延迟。如果一个事务执行就要10分钟，那么主库执行完后，给到从库执行，最后这个事务可能就会导致从库延迟10分钟啦。日常开发中，我们为什么特别强调，不要一次性delete太多SQL，需要分批进行，其实也是为了避免大事务。另外，大表的DDL语句，也会导致大事务，大家日常开发关注一下哈。
-
网络延迟也会导致主从延迟，这种情况你只能优化你的网络啦，比如带宽20M升级到100M类似意思等。
-
如果从数据库过多也会导致主从延迟，因此要避免复制的从节点数量过多。从库数据一般以3-5个为宜。
-
低版本的MySQL只支持单线程复制，如果主库并发高，来不及传送到从库，就会导致延迟。可以换用更高版本的Mysql，可以支持多线程复制。
3-1-5、数据的库高可用方案
-
双机主备高可用
架构描述：两台机器A和B，A为主库，负责读写，B为备库，只备份数据。如果A库发生故障，B库成为主库负责读写。修复故障后，A成为备库，主库B同步数据到备库A
优点：一个机器故障了可以自动切换，操作比较简单。
缺点：只有一个库在工作，读写压力大，未能实现读写分离， 并发也有一定限制
-
一主一从
架构描述: 两台机器A和B，A为主库，负责读写，B为从库，负责读数据。如果A库发生故障，B库成为主库负责读写。修复故障后，A成为从库，主库B同步数据到从库A。
优点：从库支持读，分担了主库的压力，提升了并发度。一个机器故障了可以自动切换，操作比较简单。
缺点：一台从库，并发支持还是不够，并且一共两台机器， 还是存在同时故障的机率，不够高可用。
-
一主多从
架构描述: 一台主库多台从库，A为主库，负责读写，B、C、D为从库，负责读数据。如果A库发生故障，B库成为主库负责读写，C、D负责读。修复故障后，A也成为从库，主库B同步数据到从库A。
优点：多个从库支持读，分担了主库的压力，明显提升了读的并发度。
缺点：只有台主机写，因此写的并发度不高
-
MariaDB同步多主机
架构描述:有代理层实现负载均衡，多个数据库可以同时进行读写操作；各个数据库之间可以通过 Galera Replication 方法进行数据同步，每个库理论上数据是完全一致的。
优点：读写的并发度都明显提升，可以任意节点读写，可以自动剔除故障节点，具有较高的可靠性。
缺点：数据量不支持特别大。要避免大事务卡死，如果集群节点一个变慢，其他节点也会跟着变慢。
-
数据库中间件
架构描述：mycat分片存储，每个分片配置一主多从的集群。
优点：解决高并发高数据量的高可用方案
缺点：维护成本比较大。
引入之前总结的Redis: 大厂面试---Redis面试题（含答案，相关知识点，面试考察次数统计）_安吉_lh1029的博客-CSDN博客
3-2、mysql中日志在【引擎层】的用法
前提：MySQL数据最终是存放在【磁盘】中的，但磁盘I/O效率太低。因此InnoDB（又是这个NB引擎）为MySQL提供了缓冲池（BufferPool）。
redolog：
缓冲池（Buffer-Pool）:更新数据和磁盘之间的缓冲区，但断电即失，因此出现redolog。
Redo log 记录了 BufferPool中的数据修改。
当事务提交时会对redolog进行刷盘，同步在磁盘中。
当MySQL出现宕机时，可以从磁盘中读取redolog进行数据的恢复，从而保证了事务的【持久性】
Redolog采用的【预写】的方式记录日志，即先记录日志，再更新BufferPool，这样就强行的保证了，数据只要保存在了redolog中就一定会存储到磁盘中了
刷脏：BufferPool中更新的数据会定期刷新到磁盘中
刷脏和redolog区别（redolog比刷脏快）
1、redolog是追加操作日志，是顺序IO；而刷脏是随机IO，因为每次更新的数据不一定是挨着的，也就是随机的
2、刷脏是以数据页（Page）为单位的（即每次最少从磁盘中读取一页数据到内存，或者最少刷一页数据到磁盘），MySQL默认页大小是16KB，对一个页上的修改，都要整个页都刷到磁盘中；而redolog只包含【真正】的需要写入磁盘的操作日志。
undolog【用于MVCC中记录回滚】
把修改前的记录存储在undolog中
可以提供多版本并发控制读（MVCC），非锁定读
四、数据库相关锁问题
4-1、MySQL 有哪些锁？
可参考文章：MySQL常见的七种锁详细介绍_和代码去流浪的博客-CSDN博客_mysql的锁
-
行锁（Record Locks），行锁一定是作用在索引上
-
间隙锁（Gap Locks），间隙锁本质上是用于阻止其他事务在该间隙内插入新记录，而自身事务是允许在该间隙内插入数据的。也就是说间隙锁的应用场景包括并发读取、并发更新、并发删除和并发插入。
-
临键锁（Next-key Locks）
-
共享锁/排他锁（Shared and Exclusive Locks），共享锁/排他锁都只是行锁，与间隙锁无关，排他锁是一个事务并发更新或删除某一行记录所需要持有的锁，比如select ... for update。尽管共享锁/排他锁是行锁，与间隙锁无关，但一个事务在请求共享锁/排他锁时，获取到的结果却可能是行锁，也可能是间隙锁，也可能是临键锁，这取决于数据库的隔离级别以及查询的数据是否存在
-
意向共享锁/意向排他锁（Intention Shared and Exclusive Locks），意向共享锁/意向排他锁属于表锁，且取得意向共享锁/意向排他锁是取得共享锁/排他锁的前置条件
-
插入意向锁（Insert Intention Locks），该锁只用于并发插入操作，如果说间隙锁锁住的是一个区间，那么插入意向锁锁住的就是一个点。因而从这个角度来说，插入意向锁确实是一种特殊的间隙锁。回顾一下共享锁和排他锁：共享锁用于读取操作，而排他锁是用于更新或删除操作。也就是说插入意向锁、共享锁和排他锁涵盖了常用的增删改查四个动作。
-
自增锁（Auto-inc Locks），自增锁是一种特殊的表级锁，主要用于事务中插入自增字段，也就是我们最常用的自增主键id
实际上，MySQL官网中还提到了一种预测锁，这种锁主要用于存储了空间数据的空间索引，本文暂不讨论。
如果使用基于行的或混合模式的复制，则所有自动增量锁定模式都是安全的，因为基于行的复制对SQL语句的执行顺序不敏感（混合模式会在遇到不安全的语句是使用基于行的复制模式）
服务器重新启动还会取消CREATE TABLE和ALTER TABLE语句中的AUTO_INCREMENT = N表选项的效果（可在建表时可用“AUTO_INCREMENT=n”选项来指定一个自增的初始值，也可用alter table table_name AUTO_INCREMENT=n命令来重设自增的起始值）。
五、数据库高性能优化问题
5-1、SQL语句优化
前提：mysql中explain关键字模拟MySQL优化器执行SQL语句，用于分析【SQL语句】或【表结构】的性能瓶颈
A.尽可能的精确查询条件及查询字段，缩小查询范围（包括使用分页查询）
B.查询条件中尽可能少用:like,(not) in, (not) is null, order by, distinct , count (*) ,!= , <> ;
C.不要对查询的字段进行函数运算，
D.判断数据存在，不要使用TOP1,而应该是：EXITS
E.对于复杂SQL查询，可直接使用SQL存储过程或建立视图（视图不可太复杂）；
F.尽可能的少用游标，触发器；
5-2、表设计优化
A.纵向分割表设计，按照某种原则，设计成相对应几个表
B.横向分割表设计，【归档】仅保留近期数据
C.表数据物理存放分区设计【分库分表】
D.建立适当的索引（聚集索引与非聚集索引）
-------- 在本文一、索引相关问题，涉及到索引的相关细节点
5-3、事务设置优化
在本文二、涉及事务的相关问题，及相关细节点
5-4、服务器硬件优化
A.服务器内存，硬盘等核心硬件性能当然越强越好
B.购买多台服务器并建立集群，以实现利用多个计算机进行并行计算从而获得很高的计算速度
C.在多台服务器建立DB镜像同步，并实现【读写分离】
参考文章：
几率大的数据库（MySQL）面试题（含答案）__睶_的博客-CSDN博客_数据库mysql面试题
MyISAM与InnoDB 的区别（9个不同点）_Chackca的博客-CSDN博客_myisam和innodb的区别
MySQL常见的七种锁详细介绍_和代码去流浪的博客-CSDN博客_mysql的锁
扫一扫
1286
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
