(2022)MySQL知识点总结

最新推荐文章于 2024-08-07 21:56:09 发布

@Jizaichun

最新推荐文章于 2024-08-07 21:56:09 发布

阅读量264

点赞数 1

文章标签：数据库 mysql

本文链接：https://blog.csdn.net/jizaichun/article/details/126279458

版权

数据库的三大范式？
- 第一范式：每个列都不可以再拆分。
- 第二范式：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。(每一行数据只做一件事，只与一列相关)
- 第三范式：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键(数据表中每一列数据都和主键直接相关而不能间接相关)
- 在设计数据库结构的时候，要尽量遵守三范式，如果不遵守，必须有足够的理由。比如性能。事实上我们经常会为了性能而妥协数据库的设计
char 和 varchar 的区别？
- char(n) ：固定长度类型，比如char(10)，当你输入”abc”三个字符的时候，它们占的空间还是 10 个字节，其他 7 个是空字节，效率高
- varchar(n) ：可变长度，存储的值是每个值占用的字节再加上一个用来记录其长度的字节的长度，节省空间
存储引擎MyISAM和InnoDB的区别？
- MyISAM：
  - 不支持事务和外键，每次查询都是原子的
  - 只支持表锁
  - 支持全文索引，不支持哈希索引
  - 会存储表的总行数
  - 采用非聚簇索引，索引的数据域存储指向数据文件的指针
  - 表存储空间较小
  - 崩溃后数据无法恢复
- InnoDB：
  - 支持事务，支持事务的四种隔离级别
  - 支持行锁和表锁及外键约束
  - 不支持全文索引，支持哈希索引和B+树索引
  - 不会存储表的总行数
  - 主键采用聚簇索引(索引的数据域存储数据本身)，辅索引的数据域存储主键的值，因此从辅索引查找数据需要先通过辅索引找到主键值，再访问辅索引
  - 表存储空间较大，约为2倍
  - 崩溃后数据可以恢复
MyISAM索引与InnoDB索引的区别？
- InnoDB索引是聚簇索引，MyISAM索引是非聚簇索引
- InnoDB的主键索引的叶子节点存储着行数据，因此主键索引非常高效。MyISAM索引的叶子节点存储的是行数据地址，需要再寻址一次才能得到数据
- InnoDB非主键索引的叶子节点存储的是主键和其他带索引的列数据，因此查询时做到覆盖索引会非常高效
索引
- 什么是索引？
  - 索引是一种数据结构。数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用B树及其变种B+树
  - 更通俗的说，索引就相当于目录。为了方便查找书中的内容，通过对内容建立索引形成目录。索引是一个文件，它是要占据物理空间的
- 索引的优缺点？
  - 可以大大加快数据的检索速度，这也是创建索引的最主要的原因
  - 可以在查询的过程中，使用优化隐藏器，提高系统的性能
  - 时间方面：创建索引和维护索引要耗费时间，具体地，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，会降低增/改/删的执行效率
  - 空间方面：索引需要占物理空间
- 索引的基本原理？
  - 索引用来快速地寻找那些具有特定值的记录。如果没有索引，一般来说执行查询时遍历整张表
  - 索引的原理很简单，就是把无序的数据变成有序的查询
    - 把创建了索引的列的内容进行排序
    - 对排序结果生成倒排表
    - 在倒排表内容上拼上数据地址链
    - 在查询的时候，先拿到倒排表内容，再取出数据地址链，从而拿到具体数据
- 索引的四种类型？
  - 主键索引：数据列不允许重复，不允许为NULL，一个表只能有一个主键
  - 唯一索引：数据列不允许重复，允许为NULL，一个表允许多个列创建唯一索引
    - 通过 `ALTER TABLE table_name ADD UNIQUE (column)` 创建唯一索引
    - 通过 `ALTER TABLE table_name ADD UNIQUE (column1,column2)` 创建唯一组合索引
  - 普通索引：基本的索引类型，没有唯一性的限制，允许为NULL值
    - 通过`ALTER TABLE table_name ADD INDEX index_name (column)`创建普通索引
    - 通过`ALTER TABLE table_name ADD INDEX index_name(column1, column2, column3)`创建组合索引
  - 全文索引：是目前搜索引擎使用的一种关键技术，只用MyISAM支持
    - 通过`ALTER TABLE table_name ADD FULLTEXT (column)`创建全文索引
- 索引的两种数据结构？
  - Hash索引：底层的数据结构就是哈希表，通过Hash算法，将数据库字段数据转换成定长的Hash值，与这条数据的行指针一并存入Hash表的对应位置。单条记录查询的时候，可以选择哈希索引，查询性能最快，hash索引不支持排序，不支持范围查找
  - B+树索引：查询一批记录及大部分场景，建议选择B+树索引
    - MyISAM：B+树叶节点的data域存放的是数据记录的地址。在索引检索的时候，首先按照B+树搜索索引，如果指定的Key存在，则取出其 data 域的值，然后以 data 域的值作为地址读取相应的数据记录。这被称为非聚簇索引。索引文件和数据文件是分离的
    - InnoDB：其数据文件本身就是索引文件，树的叶节点data域保存了完整的数据记录。索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。这被称为聚簇索引。在根据主索引搜索时，直接找到key所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂
- 索引的设计原则？
  - 适合索引的列是出现在where子句中的列，或者连接子句中指定的列
  - 基数较小的类，索引效果较差，没有必要在此列建立索引
  - 使用短索引，如果对长字符串列进行索引，应该指定一个前缀长度，这样能够节省大量索引空间
  - 不要过度索引。索引需要额外的磁盘空间，并降低写操作的性能。在修改表内容的时候，索引会进行更新甚至重构，索引列越多，这个时间就会越长。所以只保持需要的索引有利于查询即可。
- 创建索引的原则？
  - 最左前缀匹配原则，组合索引非常重要的原则
  - 较频繁作为查询条件的字段才去创建索引
  - 更新频繁字段不适合创建索引
  - 若是不能有效区分数据的列不适合做索引列(如性别，男女未知，最多也就三种，区分度实在太低)
  - 尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。
  - 定义有外键的数据列一定要建立索引
  - 查询中很少涉及的列，重复值比较多的列不要建立索引
  - 定义为text、image和bit的数据类型的列不要建立索引
- 创建和删除索引的方式？
  - 创建索引：
    - 执行CREATE TABLE时创建索引：UNIQUE KEY (id_card)
    - 使用ALTER TABLE命令去增加索引：ALTER TABLE table_name ADD INDEX index_name (column_list)
    - 使用CREATE INDEX命令创建：CREATE INDEX index_name ON table_name (column_list)
  - 删除索引：
    - 根据索引名删除普通索引、唯一索引、全文索引：`alter table 表名 drop KEY 索引名`
    - 删除主键索引：`alter table 表名 drop primary key`。这里值得注意的是，如果主键自增长，那么不能直接执行此操作，需要取消自增长再行删除，但通常不会删除主键，因为设计主键一定与业务逻辑无关
- 什么是前缀索引？
  - 语法：index(field(10))，使用字段值的前10个字符建立索引，默认是使用字段的全部内容建立索引。
  - 前提：前缀的标识度高。比如密码就适合建立前缀索引，因为密码几乎各不相同。
- 什么是回表？
  - 回表，简单说就是mysql内部需要经过两次查询，如果索引的字段在查询所需要的字段中或者根据一次索引查询就能获得记录就不需要回表(聚簇索引)，如果查询的字段中有大量的非索引字段，索引就需要到表中找到相应的字段的信息，这就叫回表。
- 什么是索引覆盖？
  - 索引覆盖就是一个SQL在执行时，可以利用索引来快速查找，并且此SQL所要查询的字段在当前索引对应的字段中都包含了，那么就表示此SQL走完索引后不用回表了，所需要的字段都在当前索引的叶子节点上存在，可以直接作为结果返回了
- 什么是索引下推？
  - 索引下推就是把索引当中的所有数据全部用到以减少回表的次数，提高查询效率
- 什么是最左匹配(前缀)原则？
  - 当一个SQL想要利用索引是，就一定要提供该索引所对应的字段中最左边的字段，也就是排在最前面的字段，比如针对a，b，c三个字段建立了一个联合索引，那么在写一个sql时就一定要提供a字段的条件，这样才能用到联合索引，这是由于在建立a,b,c三个字段的联合索引时，底层的B+树是按照a，b，c三个字段从左往右去比较大小进行排序的，所以如果想要利用B+树进行快速查找也得符合这个规则
  - 最左前缀匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整
- B树和B+树的区别？
  - B树的特点：
    - 节点排序，一个节点了可以存多个元素，多个元素也排序了
  - B+树的特点：
    - 拥有B树的特点，叶子节点之间有双指针，非叶子节点上的元素在叶子节点上都沉余了，也就是冗余，叶子结点中存储了所有的元素，并且排好了序
- MySQL为什么使用B+树？
  - B+树的数据都是排好序的，叶子节点之间又有双指针，所以可以提高查询速度
  - B+树一个节点中可以存储多个元素，提高了空间利用率，压缩了树的高度，可以减少I/O次数。在Mysql中一个Innodb页就是一个B+树节点，一个Innodb页默认16kb,所以一般情况下一颗两层的B+树可以存2000万行左右的数据
  - B+树叶子节点存储了所有数据并且进行了排序，并且叶子节点之间有指针，可以很好的支持全表扫描，范围查找等SQL语句。
  - B树只适合随机检索，而B+树同时支持随机检索和顺序检索
  - B+树的查询效率更加稳定，所有关键字的查找路径长度相同，导致每一个关键字的查询效率相当。
- B+树在满足聚簇索引和覆盖索引时为什么不要回表？
  - 在B+树的索引中，叶子节点可能存储了当前的key值，也可能存储了当前的key值以及整行的数据，这就是聚簇索引和非聚簇索引。在InnoDB中，只有主键索引是聚簇索引，如果没有主键，则挑选一个唯一键建立聚簇索引。如果没有唯一键，则隐式的生成一个键来建立聚簇索引
  - 当查询使用聚簇索引时，在对应的叶子节点，可以获取到整行数据，因此不用再次进行回表查询
- 聚簇索引和非聚簇索引的区别
  - 聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据
  - 非聚簇索引：将索引和数据分开存储，索引的叶子节点指向了数据的对应行(存储了数据地址)
- 什么是联合索引？
  - 字段同时建立一个索引，叫做联合索引。在联合索引中，如果想要命中索引，需要按照建立索引时的字段顺序挨个使用，否则无法命中索引。
- 什么时候索引会失效？
  - 查询条件中有or,即使有部分条件带索引也会失效
  - like查询是以%开头
  - 如果列类型是字符串，那在查询条件中需要将数据用引号引用起来，否则不走索引
  - 索引列上参与计算会导致索引失效
  - 违背最左匹配原则
- 查询缓存的使用？
  - 执行查询语句的时候，会先查询缓存。不过，MySQL 8.0 版本后移除，因为这个功能不太实用
  - 缓存虽然能够提升数据库的查询性能，但是缓存同时也带来了额外的开销，每次查询后都要做一次缓存操作，失效后还要销毁。因此，开启缓存查询要谨慎，尤其对于写密集的应用来说更是如此。如果开启，要注意合理控制缓存空间大小，⼀般来说其大小设置为几十MB比较合适。此外，还可以通过sql_cache和sql_no_cache来控制某个查询语句是否需要缓存
事务
- 什么是事务？
  - 事务是一个不可分割的数据库操作序列，也是数据库并发控制的基本单位，其执行的结果必须使数据库从一种一致性状态变到另一种一致性状态。事务是逻辑上的一组操作，要么都执行，要么都不执行。
- 事务的四大特性(ACID)?
  - 原子性（Atomicity）：事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用
  - 一致性（Consistency）：执行事务前后，数据保持一致，多个事务对同一个数据读取的结果是相同的；数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。例如现有完整性约束a + b = 10，如果一个事务改变了a，那么必须得改变b，使得事务结束后依然满足a + b = 10，否则事务失败
  - 隔离性（Isolation）：并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的
  - 持久性（Durability）：⼀个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响
- ACID靠什么来保证？
  - 原子性由undo log日志保证，它记录了需要回滚的日志信息，事务回滚时撤销已经执行成功的sql
  - 一致性由其他三大特性保证、程序代码要保证业务上的一致性
  - 隔离性由MVCC来保证
  - 持久性由内存+redo log来保证，mysql修改数据同时在内存和redo log记录这次操作，宕机的时候可以从redo log恢复
- 什么是脏读、幻读、不可重复读？
  - 脏读（Dirty read）：当⼀个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外⼀个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外⼀个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的
  - 不可重复读（Unrepeatableread）：指在一个事务内多次读同⼀数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读
  - 幻读（Phantom read）：幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读
  - 不可重复读和幻读区别？
    - 不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改，幻读的重点在于新增或者删除，比如多次读取一条记录发现记录增多或减少了
- 事务的四种隔离级别？
  - READ-UNCOMMITTED(读取未提交)：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
  - READ-COMMITTED(读取已提交)：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
  - REPEATABLE-READ(可重复读)：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。(MySQL默认)
  - SERIALIZABLE(可串行化)：最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读
- Innodb是如何实现事务的？
  - Innodb通过Buffer Pool，LogBuffer，Redo Log，Undo Log来实现事务，以一个update语句为例
    - Innodb在收到一个update语句后，会先根据条件找到数据所在的页，并将该页缓存在Buffer Pool中
    - 执行update语句，修改Buffer Pool中的数据，也就是内存中的数据
    - 针对update语句生成一个RedoLog对象，并存入LogBuffer中
    - 针对update语句生成undolog日志，用于事务回滚
    - 如果事务提交，那么则把RedoLogi对象进行持久化，后续还有其他机制将Buffer Poole中所修改的数据页持久化到磁盘中
    - 如果事务回滚，则利用undolog日志进行回滚
- 关于MVCC？
  - 什么是MVCC？
    - MVCC是多版本并发控制，指的就是在使用读已提交、可重复读这两种隔离级别的事务在执行普通的 SEELCT 操作时访问记录的版本链的过程，这样子可以使不同事务的读-写、写-读操作并发执行，从而提升系统性能。MVCC使得数据库读不会对数据加锁，普通的SELECT请求不会加锁，提高了数据库的并发处理能力。MVCC 在mysql 中的实现依赖的是 undo log 与 read view
    - 在 MySQL 中，读已提交和可重复读隔离级别的的一个非常大的区别就是它们生成 ReadView 的时机不同。在 READ COMMITTED 中每次查询都会生成一个实时的 ReadView，做到保证每次提交后的数据是处于当前的可见状态。而 REPEATABLE READ 中，在当前事务第一次查询时生成当前的 ReadView，并且当前的 ReadView 会一直沿用到当前事务提交，以此来保证可重复读
  - InnoDB的MVCC实现逻辑？
    - 通过在每行记录后面保存两个隐藏的列来实现的。一个是行的事务ID（DB_TRX_ID），一个是行的回滚指针（DB_ROLL_PT）。每开始一个新的事务，都会自动递增产生一个新的事务id。事务开始时刻的会把事务id放到当前事务影响的行事务id中，当查询时需要用当前事务id和每行记录的事务id进行比较。
锁
- 隔离级别与锁的关系？
  - 在Read Uncommitted级别下，读取数据不需要加共享锁，这样就不会跟被修改的数据上的排他锁冲突
  - 在Read Committed级别下，读操作需要加共享锁，但是在语句执行完以后释放共享锁；
  - 在Repeatable Read级别下，读操作需要加共享锁，但是在事务提交之前并不释放共享锁，也就是必须等待事务执行完毕以后才释放共享锁。
  - SERIALIZABLE 是限制性最强的隔离级别，因为该级别锁定整个范围的键，并一直持有锁，直到事务完成
- MySQL中的锁有哪些？
  - 行级锁：每次锁一行。其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁和排他锁。(开销最大，并发度最高)
  - 表级锁：每次锁整张表。资源消耗较少，被大部分MySQL引擎支持。MYISAM与INNODB都支持表锁。表级锁定分为表共享锁与排他锁(开销最小，并发度最低)
  - 页级锁：页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录(介于表锁和行锁之间)
  - 乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。在修改数据的时候把事务锁起来，通过version的方式来进行锁定。实现方式：一般会使用版本号机制或CAS算法实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加1。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据
  - 悲观锁：悲假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。在查询完数据的时候就把事务锁起来，直到提交事务。实现方式：使用数据库中的锁机制使用悲观锁之前需要关闭自动提交，set autocommit=0。(共享锁和排它锁都是悲观锁的实现方式)
    - 共享锁：又称读锁，是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改，直到已释放所有共享锁。如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获得共享锁的事务只能读数据，不能修改数据。共享锁可以同时加上多个
    - 排它锁：又称写锁。若事务 1 对数据对象A加上X锁，事务 1 可以读A也可以修改A，其他事务不能再对A加任何锁，直到事物1 释放A上的锁。这保证了其他事务在事物 1 释放A上的锁之前不能再读取和修改A。排它锁会阻塞所有的排它锁和共享锁。排他锁只可以加一个，他和其他的排他锁，共享锁都相斥
- InnoDB锁的算法？
  - Record lock：单个行记录上的锁
  - Gap lock：间隙锁，锁定一个范围，不包括记录本身
  - Next-key lock：record+gap 锁定一个范围，包含记录本身
- 什么是死锁？怎么解决？
  - 死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象
  - 如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会
  - 在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率
  - 对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率
  - 如果业务处理不好可以用分布式事务锁或者使用乐观锁
SQL语句是如何执行的？
- select * from tb_student A where A.age='18' and A.name=' 张三 '语句是如何执行的？
- 先检查该语句是否有权限，如果没有权限，直接返回错误信息，如果有权限，在 MySQL8.0 版本以前，会先查询缓存，以这条 sql 语句为 key 在内存中查询是否有结果，如果有直接缓存，如果没有，执行下一步
- 通过分析器进行词法分析，提取 sql 语句的关键元素，比如提取上面这个语句是查询 select，提取需要查询的表名为 tb_student,需要查询所有的列，查询条件是这个表的 id='1'。然后判断这个 sql 语句是否有语法错误，比如关键词是否正确等等，如果检查没问题就执行下一步
- 接下来就是优化器进行确定执行方案，上面的 sql 语句，可以有两种执行方案，优化器根据自己的优化算法进行选择执行效率最好的一个方案
  - a.先查询学生表中姓名为“张三”的学生，然后判断是否年龄是 18
  - b.先找出学生中年龄 18 岁的学生，然后再查询姓名为“张三”的学生
- 进行权限校验，如果没有权限就会返回错误信息，如果有权限就会调用数据库引擎接口，返回引擎的执行结果
MySQL分为哪两层？
- Server 层：主要包括连接器、查询缓存、分析器、优化器、执行器等，所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图，函数等，还有一个通用的日志模块 binglog 日志模块
- 存储引擎：主要负责数据的存储和读取，采用可以替换的插件式架构，支持 InnoDB、MyISAM、Memory 等多个存储引擎，其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB，它从 MySQL 5版本开始就被当做默认存储引擎了
MySQL主从同步原理？
- 主服务器会将数据的改变记录写到一个binary log日志文件中，当主服务器上的数据发生改变时，就会把变化写到这个二进制文件中
- 从服务器会在一定时间间隔内对binary log文件进行探测，观测其是否发生改变，如果改变就会开启一个I/O线程请求log事件，主服务器收到从服务器的请求后会开启一个log dump线程，用来给从服务器传binary log，从服务器会将读取的日志保存到本地的一个relay log(中继日志)文件中
- 从服务器会启动一个SQL线程从中继日志中读取日志，并解析成sql语句逐一执行,使其数据和主节点保持一致
大表优化？
- 限定数据的范围：务必禁止不带任何限制数据范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内
- 读/写分离：经典的数据库拆分方案，主库负责写，从库负责读
- 缓存：使用MySQL的缓存，另外对重量级、更新少的数据可以考虑使用应用级别的缓存
- 分库分表的方式进行优化，主要有垂直分表和水平分表
  - 垂直分表：
    - 根据数据库里面数据表的相关性进行拆分。例如，用户表中既有用户的登录信息又有用户的基本信息，可以将用户表拆分成两个单独的表，甚至放到单独的库做分库。简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表
  - 水平分表：
    - 保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中，达到了分布式的目的。水平拆分可以支撑非常大的数据量
慢查询怎么优化？
- 检查是否走了索引，如果没有命中索引，则优化SQL利用索引
- 检查所利用的索引，是否是最优索引
- 检查所查字段是否都是必须的，是否查询了过多字段，查出了多余数据
- 检查表中数据是否过多，是否应该进行分库分表了
- 检查数据库实例所在机器的性能配置，是否太低，是否可以适当增加资源
关于连接池？
- 数据库连接本质就是⼀个 socket 的连接。数据库服务端还要维护⼀些缓存和用户权限信息之类的所以占用了一些内存。我们可以把数据库连接池是看做是维护的数据库连接的缓存，以便将来需要对数据库的请求时可以重用这些连接。为每个用户打开和维护数据库连接，尤其是对动态数据库驱动的网站应用程序的请求，既昂贵又浪费资源。在连接池中，创建连接后，将其放置在池中，并再次使用它，因此不必建立新的连接。如果使用了所有连接，则会建立一个新连接并将其添加到池中。连接池还减少了用户必须等待建立与数据库的连接的时间
- 常用的数据库连接池：dbcp，c3p0，druid，hikari
JDBC连接数据库的步骤
- 加载驱动
- 获取连接对象
- 通过连接对象创建Statement语句对象
- 执行SQL语句
- 处理返回的结果
- 关闭连接，释放资源