python中与数据库相关的面试题

数据库作为面试中的重要部分，当然也需要整理

1.为什么要优化

系统的吞吐量瓶颈往往出现在数据库的访问速度上，随着应用程序的运行，数据库的中的数据会越来越多，处理时间会相应变慢，数据是存放在磁盘上的，读写速度无法和内存相比

2.如何优化

设计数据库时：数据库表、字段的设计，存储引擎，利用好MySQL自身提供的功能，如索引等
横向扩展：MySQL集群、负载均衡、读写分离 SQL语句的优化（收效甚微）

3.字段设计

字段类型的选择，设计规范，范式，

常见设计案例
原则：尽量使用整型表示字符串
存储IP INET_ATON(str)，address to number
INET_NTOA(number)，number to address

MySQL内部的枚举类型（单选）和集合（多选）类型
但是因为维护成本较高因此不常使用，使用关联表的方式来替代enum

原则：定长和非定长数据类型的选择 decimal不会损失精度，存储空间会随数据的增大而增大。double占用固定空间，较大数的存储会损失精度。
非定长的还有varchar、text

金额 对数据的精度要求较高，小数的运算和存储存在精度问题（不能将所有小数转换成二进制）
定点数decimal price decimal(8,2)有2位小数的定点数，定点数支持很大的数（甚至是超过int,bigint存储范围的数）

小单位大数额避免出现小数 元->分

字符串存储 定长char，非定长varchar、text（上限65535，其中varchar还会消耗1-3字节记录长度，而text使用额外空间记录长度）

原则：尽可能选择小的数据类型和指定短的长度 原则：尽可能使用 not null 非null字段的处理要比null字段的处理高效些！且不需要判断是否为null。

null在MySQL中，不好处理，存储需要额外空间，运算也需要特殊的运算符。
如select null = null和select null <> null（<>为不等号）有着同样的结果，只能通过is null和is not null来判断字段是否为null。

如何存储？MySQL中每条记录都需要额外的存储空间，表示每个字段是否为null。
因此通常使用特殊的数据进行占位，比如int not null default 0、string not null default ‘’

原则：字段注释要完整，见名知意
原则：单表字段不宜过多 二三十个就极限了
原则：可以预留字段
在使用以上原则之前首先要满足业务需求
关联表的设计
外键foreign key只能实现一对一或一对多的映射
一对多 使用外键
多对多 单独新建一张表将多对多拆分成两个一对多
一对一 如商品的基本信息（item）和商品的详细信息（item_intro），通常使用相同的主键或者增加一个外键字段（item_id）

4.范式 Normal Format

数据表的设计规范，一套越来越严格的规范体系（如果需要满足N范式，首先要满足N-1范式）。

第一范式1NF：字段原子性 字段原子性，字段不可再分割。

关系型数据库，默认满足第一范式 注意比较容易出错的一点，在一对多的设计中使用逗号分隔多个外键，这种方法虽然存储方便，但不利于维护和索引（比如查找带标签java的文章）

第二范式：消除对主键的部分依赖

即在表中加上一个与业务逻辑无关的字段作为主键
主键：可以唯一标识记录的字段或者字段集合。

course_namecourse_
classweekday（周几）
course_teacherMySQL教育大楼
1525周一张三Java教育大楼
1521周三李四MySQL教育大楼
1521周五张三

依赖：A字段可以确定B字段，则B字段依赖A字段。 比如知道了下一节课是数学课，就能确定任课老师是谁。
于是周几和下一节课和就能构成复合主键，能够确定去哪个教室上课，任课老师是谁等。 但我们常常增加一个id作为主键，而消除对主键的部分依赖。

对主键的部分依赖：某个字段依赖复合主键中的一部分。
解决方案：新增一个独立字段作为主键。

第三范式：消除对主键的传递依赖

传递依赖：B字段依赖于A，C字段又依赖于B。
比如上例中，任课老师是谁取决于是什么课，是什么课又取决于主键id。
因此需要将此表拆分为两张表日程表和课程表（独立数据独立建表）：

idweekdaycourse_classcourse_id 1001 周一教育大楼
15213546 course_idcourse_namecourse_teacher 3546 Java 张三

这样就减少了数据的冗余（即使周一至周日每天都有Java课，也只是course_id:3546出现了7次）

5.存储引擎选择

早期问题：如何选择MyISAM和Innodb？

现在不存在这个问题了，Innodb不断完善，从各个方面赶超MyISAM，也是MySQL默认使用的。
存储引擎Storage engine：MySQL中的数据、索引以及其他对象是如何存储的，是一套文件系统的实现。

功能差异 show engines

EngineSupportCommentInnoDBDEFAULTSupports transactions, row-level locking, and foreign keysMyISAMYESMyISAM storage engine

存储差异
MyISAMInnodb文件格式数据和索引是分别存储的，数据.MYD，
索引.MYI数据和索引是集中存储的，.ibd文件能否移动能，一张表就对应.frm、MYD、MYI3个文件否，因为关联的还有data下的其它文件记录存储顺序按记录插入顺序保存按主键大小有序插入空间碎片（删除记录并flush table 表名之后，表文件大小不变）产生。
定时整理：使用命令optimize table 表名实现不产生事务不支持支持外键不支持支持锁支持（锁是避免资源争用的一个机制，MySQL锁对用户几乎是透明的）表级锁定行级锁定、表级锁定，锁定力度小并发能力高

锁扩展 表级锁（table-level lock）：lock tables ,… read/write，unlock tables ,…。

其中read是共享锁，一旦锁定任何客户端都不可读；
write是独占/写锁，只有加锁的客户端可读可写，其他客户端既不可读也不可写。锁定的是一张表或几张表。
行级锁（row-level lock）：锁定的是一行或几行记录。
共享锁：select from where <条件> LOCK IN SHARE MODE;，对查询的记录增加共享锁；
select from where <条件> FOR UPDATE;，对查询的记录增加排他锁。
这里值得注意的是：innodb的行锁，其实是一个子范围锁，依据条件锁定部分范围，而不是就映射到具体的行上，因此还有一个学名：间隙锁。
比如select * from stu where id < 20 LOCK IN SHARE MODE会锁定id在20左右以下的范围，你可能无法插入id为18或22的一条新纪录。
选择依据 如果没有特别的需求，使用默认的Innodb即可。

MyISAM：以读写插入为主的应用程序，比如博客系统、新闻门户网站。

Innodb：更新（删除）操作频率也高，或者要保证数据的完整性；并发量高，支持事务和外键保证数据完整性。比如OA自动化办公系统。

6.索引

关键字与数据的映射关系称为索引（包含关键字和对应的记录在磁盘中的地址）。
关键字是从数据当中提取的用于标识、检索数据的特定内容。

索引检索为什么快？

关键字相对于数据本身，数据量小 关键字是有序的，二分查找可快速确定位置 图书馆为每本书都加了索引号（类别-楼层-书架）、字典为词语解释按字母顺序编写目录等都用到了索引。

MySQL中索引类型 普通索引（key），唯一索引（unique key），主键索引（primary key），全文索引（fulltext key） 三种索引的索引方式是一样的，只不过对索引的关键字有不同的限制：

普通索引：对关键字没有限制
唯一索引：要求记录提供的关键字不能重复
主键索引：要求关键字唯一且不为null
索引管理语法 查看索引 show create table 表名：

7.执行计划explain

我们可以通过explain selelct来分析SQL语句执行前的执行计划：
执行计划是：当执行SQL语句时，首先会分析、优化，形成执行计划，在按照执行计划执行。

8.索引使用场景（重点）
where

order by 当我们使用order by将查询结果按照某个字段排序时，如果该字段没有建立索引，那么执行计划会将查询出的所有数据使用外部排序（将数据从硬盘分批读取到内存使用内部排序，最后合并排序结果），这个操作是很影响性能的，因为需要将查询涉及到的所有数据从磁盘中读到内存（如果单条数据过大或者数据量过多都会降低效率），更无论读到内存之后的排序了。

但是如果我们对该字段建立索引alter table 表名 add index(字段名)，那么由于索引本身是有序的，因此直接按照索引的顺序和映射关系逐条取出数据即可。而且如果分页的，那么只用取出索引表某个范围内的索引对应的数据，而不用像上述那取出所有数据进行排序再返回某个范围内的数据。（从磁盘取数据是最影响性能的）

join

对join语句匹配关系（on）涉及的字段建立索引能够提高效率

like查询，不能以通配符开头 比如搜索标题包含mysql的文章：

select * from article where title like ‘%mysql%’; 这种SQL的执行计划用不了索引（like语句匹配表达式以通配符开头），因此只能做全表扫描，效率极低，在实际工程中几乎不被采用。而一般会使用第三方提供的支持中文的全文索引来做。

但是 关键字查询 热搜提醒功能还是可以做的，比如键入mysql之后提醒mysql 教程、mysql 下载、mysql 安装步骤等。用到的语句是：

select * from article where title like ‘mysql%’; 这种like是可以利用索引的（当然前提是title字段建立过索引）。

9.索引的存储结构

BTree btree（多路平衡查找树）是一种广泛应用于磁盘上实现索引功能的一种数据结构，也是大多数数据库索引表的实现。

BTree的一个node可以存储多个关键字，node的大小取决于计算机的文件系统，因此我们可以通过减小索引字段的长度使结点存储更多的关键字。
如果node中的关键字已满，那么可以通过每个关键字之间的子节点指针来拓展索引表，但是不能破坏结构的有序性，比如按照first_name第一有序、last_name第二有序的规则
这与二叉搜索树的思想是一样的，只不过二叉搜索树的查找效率是log(2,N)（以2为底N的对数），而BTree的查找效率是log(x,N)（其中x为node的关键字数量，可以达到1000以上）。

10.select * 要少用

即尽量选择自己需要的字段select，但这个影响不是很大，因为网络传输多了几十上百字节也没多少延时，并且现在流行的ORM框架都是用的select *，只是我们在设计表的时候注意将大数据量的字段分离，比如商品详情可以单独抽离出一张商品详情表，这样在查看商品简略页面时的加载速度就不会有影响了。

11.order by rand()不要用

它的逻辑就是随机排序（为每条数据生成一个随机数，然后根据随机数大小进行排序）。如select * from student order by rand() limit 5的执行效率就很低，因为它为表中的每条数据都生成随机数并进行排序，而我们只要前5条。

解决思路：在应用程序中，将随机的主键生成好，去数据库中利用主键检索。

12.单表和多表查询

多表查询：join、子查询都是涉及到多表的查询。如果你使用explain分析执行计划你会发现多表查询也是一个表一个表的处理，最后合并结果。因此可以说单表查询将计算压力放在了应用程序上，而多表查询将计算压力放在了数据库上。

现在有ORM框架帮我们解决了单表查询带来的对象映射问题（查询单表时，如果发现有外键自动再去查询关联表，是一个表一个表查的）。

13.count(*)
在MyISAM存储引擎中，会自动记录表的行数，因此使用count(*)能够快速返回。而Innodb内部没有这样一个计数器，需要我们手动统计记录数量，解决思路就是单独使用一张表：

idtablecount1student100

14.limit 1
如果可以确定仅仅检索一条，建议加上limit 1，其实ORM框架帮我们做到了这一点（查询单条的操作都会自动加上limit 1）。

15.慢查询日志
用于记录执行时间超过某个临界值的SQL日志，用于快速定位慢查询，为我们的优化做参考。 开启慢查询日志 配置项：slow_query_log

可以使用show variables like ‘slov_query_log’查看是否开启，如果状态值为OFF，可以使用set GLOBAL slow_query_log = on来开启，它会在datadir下产生一个xxx-slow.log的文件。

16.什么是 MongoDB ？

MongoDB 是一个介于关系数据库和非关系数据库之间的开源产品，是最接近于关系型数据库的 NoSQL 数据库。

它在轻量级JSON 交换基础之上进行了扩展，即称为 BSON 的方式来描述其无结构化的数据类型。

尽管如此它同样可以存储较为复杂的数据类型。它和Redis有异曲同工之妙。

虽然两者均为 NoSQL ，但是 MongoDB 相对于 Redis 而言，MongoDB 更像是传统的数据库。

早些年我们是先有了 Relation Database (关系型数据库)，然后出现了很多很复杂的query ，里面用到了很多嵌套，很多 join 操作。所以在设计数据库的时候，我们也考虑到了如何应用他们的关系，使得写 query 可以使 database效率达到最高。
后来人们发现，不是每个系统，都需要如此复杂的关系型数据库。
有些简单的网站，比如博客，比如社交网站，完全可以斩断数据库之间的一切关系。这样做带来的好处是，设计数据库变得更加简单，写 query 也变得更加简单。然后，query 消耗的时间可能也会变少。因为 query 简单了，少了许多消耗资源的 join操作，速度自然会上去。
正如所说的， query 简单了，很有以前 MySQL 可以找到的东西，现在关系没了，通过 Mongo找不到了。我们只能将几组数据都抓到本地，然后在本地做 join，所以在这点上可能会消耗很多资源。这里我们可以发现。如何选择数据库，完全取决于你所需要处理的数据的模型，即 Data Model。
如果它们之间，关系错综复杂，千丝万缕，这个时候 MySQL 一定是首选。如果他们的关系并不是那么密切，那么， NoSQL 将会是利器。

MongoDB 和 Redis 一样均为 key-value 存储系统，它具有以下特点：

面向集合存储，易存储对象类型的数据。
模式自由。
支持动态查询。
支持完全索引，包含内部对象。
支持查询。
支持复制和故障恢复。
使用高效的二进制数据存储，包括大型对象(如视频等)。
自动处理碎片，以支持云计算层次的扩展性 支持 Python ， PHP ， Ruby ， Java ， C ， C# ， Javascript ，Perl 及 C++ 语言的驱动程序，社区中也提供了对Erlang 及 .NET 等平台的驱动程序。
文件存储格式为 BSON (一种 JSON 的扩展)。 可通过网络访问。

17.MongoDB 与 MySQL 性能比较

像 MySQL 一样， MongoDB 提供了丰富的远远超出了简单的键值存储中提供的功能和功能。

MongoDB 具有查询语言，功能强大的辅助索引(包括文本搜索和地理空间)，数据分析功能强大的聚合框架等。
相比使用关系数据库而言，使用MongoDB ，您还可以使用如下表所示的这些功能，跨越更多样化的数据类型和数据规模。

MySQL 中的许多概念在 MongoDB 中具有相近的类比。

18.MongoDB应用范围和限制

MongoDB 的主要目标是在 key-value (键/值)存储方式(提供了高性能和高度伸缩性)以及传统的 RDBMS 系统(丰富的功能)架起一座桥梁，集两者的优势于一身。

MongoDB 适用范围如下：

网站数据： Mongo 非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
缓存：由于性能很高， Mongo 也适合作为信息基础设施的缓存层。在系统重启之后，由 Mongo 搭建的持久化缓存层可以避免下层的数据源过载
低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。
高伸缩性的场景： Mongo 非常适合由数十或数百台服务器组成的数据库。
Mongo 的路线图中已经包含对 MapReduce 引擎的内置支持。
用于对象及JSON 数据的存储： Mongo 的 BSON 数据格式非常适合文档化格式的存储及查询。

MongoDB 当然也会有以下场景的限制：

高度事物性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
传统的商业智能应用：针对特定问题的 BI 数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。 需要 SQL的问题。

19.Reids的特点

Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。

因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。

Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能。

比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。

另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。

Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

20.使用redis有哪些好处？

1.速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
2.支持丰富数据类型，支持string，list，set，sorted set，hash
3.支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
4.丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除

21.为什么redis需要把所有数据放到内存中?

Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。
所以redis具有快速和数据持久化的特征。
如果不将数据放在内存中，磁盘I/O速度为严重影响redis的性能。
在内存越来越便宜的今天，redis将会越来越受欢迎。

如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。

22.Redis是单进程单线程的

redis利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销

redis持久化的几种方式

• 1、快照（snapshots）

缺省情况情况下，Redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb。
你可以配置Redis的持久化策略，例如数据集中每N秒钟有超过M次更新，就将数据写入磁盘；
或者你可以手工调用命令SAVE或BGSAVE。

工作原理

Redis forks.

子进程开始将数据写到临时RDB文件中。

当子进程完成写RDB文件，用新文件替换老文件。

这种方式可以使Redis使用copy-on-write技术。

• 2、AOF

快照模式并不十分健壮，当系统停止，或者无意中Redis被kill掉，最后写入Redis的数据就会丢失。

这对某些应用也许不是大问题，但对于要求高可靠性的应用来说，Redis就不是一个合适的选择。Append-only文件模式是另一种选择。你可以在配置文件中打开AOF模式

• 3、虚拟内存方式

当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大.

当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value.

vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的.可能会造成比较长时间的延迟,但是对数据完整性有很好的保证.

自己测试的时候发现用虚拟内存性能也不错。
如果数据量很大，可以考虑分布式或者其他数据库。

再来一篇MySQL常见面试题
欢迎采阅！