为什么要建索引，什么字段可以建索引，什么不能建索引
1、表的主键、外键必须有索引；
2、数据量超过300的表应该有索引；
3、经常与其他表进行连接的表，在连接字段上应该建立索引；
4、经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；
5、索引应该建在选择性高的字段上；
6、索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；
7、复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替
更新频繁的字段不适合创建索引，不会出现在 where 子句中的字段不应该创建索引。
edis持久化：
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
flask请求上下文与应用上下文
current_app、g 是应用上下文。
requests、session 是请求上下文。
手动创建上下文的两种方法：
- with app.app_context()
- app = current_app._get_current_object()
两者区别：
请求上下文：保存了客户端和服务器交互的数据。
应用上下文：flask 应用程序运行过程中，保存的一些配置信息，比如程序名、数据库连接、应用信息等。
两者作用：
请求上下文(request context)：
Flask从客户端收到请求时，要让视图函数能访问一些对象，这样才能处理请求。请求对象是一个很好的例子，它封装了客户端发送的HTTP 请求。要想让视图函数能够访问请求对象，一个显而易见的方式是将其作为参数传入视图函数，不过这会导致程序中的每个视图函数都增加一个参数，除了访问请求对象,如果视图函数在处理请求时还要访问其他对象，情况会变得更糟。为了避免大量可有可无的参数把视图函数弄得一团糟，Flask使用上下文临时把某些对象变为全局可访问。
应用上下文(application context)：
它的字面意思是 应用上下文，但它不是一直存在的，它只是requestcontext 中的一个对 app的代理(人)，所谓localproxy。它的作用主要是帮助 request 获取当前的应用，它是伴 request 而生，随 request 而灭的。
redis管道（pipeline）功能
（1）以前正常使用过程
客户端向服务器发送查询，并从套接字读取，通常以阻塞的方式，用于服务器响应。
服务器处理命令并将响应发送回客户端。
也就是每个命令都会有一来以往的过程
（2）管道的意义
如果能将连续执行的redis命令在操作完成后统一返回，就可以减少连接数，从来减少延迟时间，那么管道也就产生了。
管道的基本含义是，客户端可以向服务器发送多个请求，而不必等待回复，并最终在一个步骤中读取回复。
水平触发和边缘触发
Level_triggered(水平触发)：当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据一次性全部读写完(如读写缓冲区太小)，那么下次调用 epoll_wait()时，它还会通知你在上次没读写完的文件描述符上继续读写，当然如果你一直不去读写，它会一直通知你！！！ 如果系统中有大量你不需要读写的就绪文件描述符，而它们每次都会返回，这样会大大降低处理程序检索自己关心的就绪文件描述符的率！！！
Edge_triggered(边缘触发)：当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据全部读写完(如读写缓冲区太小)，那么下次调用epoll_wait()时，它不会通知你，也就是它只会通知你一次，直到该文件描述符上出现第二次可读写事件才会通知你！！！这种模式比水平触发效率高，系统不会充斥大量你不关心的就绪文件描述符！！！
select(),poll()模型都是水平触发模式，信号驱动IO是边缘触发模式，epoll()模型即支持水平触发，也支持边缘触发，默认是水平触发
MVC和MTV：
MVC：
M：model:数据模型
V：view:视图
C: control 控制器
整个流程： 举个例子：用户注册：用户提交信息，control控制器会进行信息的接收，并将信息传递给model进行数据库的存储，在返回一个model模型给control控制器，此时控制器会通知view去产生一个HTML，最后返回给用户
MTV：
M：model:数据模型
T：templates 模板
V：view:视图
整个流程：还是以用户注册为例，用户提交信息后，view会进行一个接收，并交给model进行数据库存储，而MTV与MVC的不同在于，它是由templates来渲染一个HTML页面，最后有视图返回给用户。
怎么解决的redis页面的缓存：
我主要是在首页和用户中心页做了页面缓存，然后flask框架中是有一个flask-cache的模块，是已经封装好了的，我们只需要调用这个模块，配置我们的redis信息，然后将我们的应用注册进行，直接在视图上添加装饰器就可以使用。设置过期时间timeout，删除缓存可以通过设置一个key_prefix来作为标记，然后，在内容更新的函数里面调用cache.delete(‘index’)来删除缓存来保证用户访问到的内容是最新的，当然也可以修改配置文件设置过期时间。
谈谈redis的理解:
Redis运行在内存中，读取效率是相当高的，但是可以持久化到磁盘
支持丰富数据类型
支持事务，操作都是原子性，所谓原子性就是对数据的更改要么全部执行，要不全部不执行。
可用于缓存，消息，按key设置过期时间，过期后自动删除
分布式，读写分离模式
flask-login的实现原理，过程：
flask-login是一个用户认证的第三方库，主要就是用于用户的登录认证
实现的话，我们需要进行一个安装，然后导入LoginMmanger,实例对象，然后绑定登录视图的路由，同样将应用注册进去，在登录时，将用户注册到login_user中，注册之后只要我们在其他需要用户认证的视图添加登录认证的装饰器，便会受到它的控制，如果验证不通过则返回到登录页面，我们可以得到一些参数，比如说is_authenticated，current_user这些参数，有一个user_loader的回调函数，返回值得到用户的所有信息，做登出操作时，通过logout_user()删除登录标识，跳转回登录界面。
红黑树，B树，B+树，为什么mysql的索引使用B+树
红黑树主要是保证树的平衡，二叉树如果插入的数据是有序的，就会退化为一个链表，它的查询效率是很低的，反而失去了二叉树的效果
b树：多路搜索树，路数越多，树的高度越低，查询效率是根据树的高度来决定的，树越低，查询速度越快
b+树: 数据都在叶子节点，叶子节点还加了指针形成链表，select 查询多条的时候，由于所有数据都在叶子结点，不用跨层，同时由于有链表结构，只需要找到首尾，通过链表就能把所有数据取出来了。如果只选一个数据，那确实是hash更快。但是数据库中经常会选择多条，这时候由于B+树索引有序，并且又有链表相连，它的查询效率比hash就快很多了。而且数据库中的索引一般是在磁盘上，数据量大的情况可能无法一次装入内存，B+树的设计可以允许数据分批加载，同时树的高度较低，提高查找效率。
Mysql 数据库如何分区、分表
分表可以通过三种方式：Mysql 集群、自定义规则和 merge 存储引擎。
分区有四类：
RANGE 分区：基于属于一个给定连续区间的列值，把多行分配给分区。
LIST 分区：类似于按 RANGE 分区，区别在于 LIST 分区是基于列值匹配一个离散值集合中的某个值来进行选择。
HASH 分区：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算。这个函数可以包含 MySQL 中有效的、产生非负整数值的任何表达式。
KEY 分区：类似于按 HASH 分区，区别在于 KEY 分区只支持计算一列或多列，且 MySQL 服务器提供其自身的哈希函数。必须有一列或多列包含整数值。