PS：(MYSQL官方文档：https://dev.mysql.com/doc/refman/5.7/en/）一、什么是主键、外键：
关系型数据库中的一条记录中有若干个属性，若其中某一个属性组(注意是组)能唯一标识一条记录，该属性组就可以成为一个主键比如 ：
学生表(学号，姓名，性别，班级)
其中每个学生的学号是唯一的，学号就是一个主键
用户表(用户名、密码、登录级别)
其中用户名是唯一的, 用户名就是一个主键
上机记录表(卡号,学号,姓名、序列号)
上机记录表中单一一个属性无法唯一标识一条记录，学号和姓名的组合才可以唯一标识一条记录，所以 学号和姓名的属性组是一个主键
上机记录表中的序列号不是成绩表的主键，但它和学生表中的学号相对应，并且学生表中的学号是学生表的主键，则称成绩表中的学号是学生表的外键
定义主键和外键主要是为了维护关系数据库的完整性，总结一下：
主键是能确定一条记录的唯一标识，比如，一条记录包括身份证号，姓名，年龄。身份证号是唯一能确定你这个人的，其他都可能有重复，所以，身份证号是主键。
外键用于与另一张表的关联。是能确定另一张表记录的字段，用于保持数据的一致性。比如，A表中的一个字段，是B表的主键，那他就可以是A表的外键。
二、 主键、外键 和索引的区别
主键、外键和索引的区别？
定义： 唯一标识一条记录，不能有重复的，不允许为空 表的外键是另一表的主键, 外键可以有重复的, 可以是空值
该字段没有重复值，但可以有一个空值作用： 用来保证数据完整性 用来和其他表建立联系用的 是提高查询排序的速度个数： 主键只能有一个
一个表可以有多个外键 一个表可以有多个惟一索引
聚集索引和非聚集索引的区别？聚集索引一定是唯一索引。但唯一索引不一定是聚集索引。
聚集索引，在索引页里直接存放数据，而非聚集索引在索引页里存放的是索引，这些索引指向专门的数据页的数据。
三、数据库中主键和外键的设计原则
主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境，就很难对这些键进行修改，所以在开发阶段就设计好主键和外键就是非常必要和值得的。
主键：
关系数据库依赖于主键---它是数据库物理模式的基石。主键在物理层面上只有两个用途：
1. 惟一地标识一行。
2. 作为一个可以被外键有效引用的对象。
基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则：
1. 主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。
2. 主键应该是单列的，以便提高连接和筛选操作的效率。
注：使用复合键的人通常有两个理由为自己开脱，而这两个理由都是错误的。其一是主键应当具有实际意义，然而，让主键具有意义只不过是给人为地破坏数据库提供了方便。其二是利用这种方法可以在描述多对多关系的连接表中使用两个外部键来作为主键，我也反对这种做法，理由是：复合主键常常导致不良的外键，即当连接表成为另一个从表的主表，而依据上面的第二种方法成为这个表主键的一部分，然而这个表又有可能再成为其它从表的主表，其主键又有可能成了其它从表主键的一部分，如此传递下去，越靠后的从表，其主键将会包含越多的列了。
3. 永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。如果主键需要更新，则说明主键应对用户无意义的原则被违反了。
注：这项原则对于那些经常需要在数据转换或多数据库合并时进行数据整理的数据并不适用。
4. 主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等。
5. 主键应当有计算机自动生成。如果由人来对主键的创建进行干预，就会使它带有除了惟一标识一行以外的意义。一旦越过这个界限，就可能产生认为修改主键的动机，这样，这种系统用来链接记录行、管理记录行的关键手段就会落入不了解数据库设计的人的手中。
四、数据库主键选取策略
我们在建立数据库的时候，需要为每张表指定一个主键，所谓主键就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引。因为主键可以唯一标识某一行记录，所以可以确保执行数据更新、删除的时候不会出现张冠李戴的错误。当然，其它字段可以辅助我们在执行这些操作时消除共享冲突，不过就不在这里讨论了。主键除了上述作用外，常常与外键构成参照完整性约束，防止出现数据不一致。所以数据库在设计时，主键起到了很重要的作用。
常见的数据库主键选取方式有：
• 自动增长字段
• 手动增长字段
• UniqueIdentifier
• “COMB（Combine）”类型
1自动增长型字段很多数据库设计者喜欢使用自动增长型字段，因为它使用简单。自动增长型字段允许我们在向数据库添加数据时，不考虑主键的取值，记录插入后，数据库系统会自动为其分配一个值，确保绝对不会出现重复。如果使用SQL
Server数据库的话，我们还可以在记录插入后使用@@Identity全局变量获取系统分配的主键键值。
尽管自动增长型字段会省掉我们很多繁琐的工作，但使用它也存在潜在的问题，那就是在数据缓冲模式下，很难预先填写主键与外键的值。
假设有两张表：
Order(OrderID, OrderDate)
OrderDetial(OrderID, LineNum, ProductID, Price)
Order表中的OrderID是自动增长型的字段。现在需要我们录入一张订单，包括在Order表中插入一条记录以及在OrderDetail表中插入若干条记录。因为Order表中的OrderID是自动增长型的字段，那么我们在记录正式插入到数据库之前无法事先得知它的取值，只有在更新后才能知道数据库为它分配的是什么值。这会造成以下矛盾发生：
首先，为了能在OrderDetail的OrderID字段中添入正确的值，必须先更新Order表以获取到系统为其分配的OrderID值，然后再用这个OrderID填充OrderDetail表。最后更新OderDetail表。但是，为了确保数据的一致性，Order与OrderDetail在更新时必须在事务保护下同时进行，即确保两表同时更行成功。显然它们是相互矛盾的。
除此之外，当我们需要在多个数据库间进行数据的复制时（SQL
Server的数据分发、订阅机制允许我们进行库间的数据复制操作），自动增长型字段可能造成数据合并时的主键冲突。设想一个数据库中的Order表向另一个库中的Order表复制数据库时，OrderID到底该不该自动增长呢？
ADO.NET允许我们在DataSet中将某一个字段设置为自动增长型字段，但千万记住，这个自动增长字段仅仅是个占位符而已，当数据库进行更新时，数据库生成的值会自动取代ADO.NET分配的值。所以为了防止用户产生误解，建议大家将ADO.NET中的自动增长初始值以及增量都设置成-1。此外，在ADO.NET中，我们可以为两张表建立DataRelation，这样存在级联关系的两张表更新时，一张表更新后另外一张表对应键的值也会自动发生变化，这会大大减少了我们对存在级联关系的两表间更新时自动增长型字段带来的麻烦。
2手动增长型字段既然自动增长型字段会带来如此的麻烦，我们不妨考虑使用手动增长型的字段，也就是说主键的值需要自己维护，通常情况下需要建立一张单独的表存储当前主键键值。还用上面的例子来说，这次我们新建一张表叫IntKey，包含两个字段，KeyName以及KeyValue。就像一个HashTable，给一个KeyName，就可以知道目前的KeyValue是什么，然后手工实现键值数据递增。在SQL
Server中可以编写这样一个存储过程，让取键值的过程自动进行。代码如下：
CREATE PROCEDURE[GetKey]
@KeyNamechar(10),
@KeyValue intOUTPUT AS UPDATE IntKey SET @KeyValue =KeyValue = KeyValue + 1
WHERE KeyName = @KeyName GO
这样，通过调用存储过程，我们可以获得最新键值，确保不会出现重复。若将OrderID字段设置为手动增长型字段，我们的程序可以由以下几步来实现：首先调用存储过程，获得一个OrderID，然后使用这个OrderID填充Order表与OrderDetail表，最后在事务保护下对两表进行更新。
使用手动增长型字段作为主键在进行数据库间数据复制时，可以确保数据合并过程中不会出现键值冲突，只要我们为不同的数据库分配不同的主键取值段就行了。但是，使用手动增长型字段会增加网络的RoundTrip，我们必须通过增加一次数据库访问来获取当前主键键值，这会增加网络和数据库的负载，当处于一个低速或断开的网络环境中时，这种做法会有很大的弊端。同时，手工维护主键还要考虑并发冲突等种种因素，这更会增加系统的复杂程度。
3使用UniqueIdentifierSQL Server为我们提供了UniqueIdentifier数据类型，并提供了一个生成函数NEWID(
)，使用NEWID(
)可以生成一个唯一的UniqueIdentifier。UniqueIdentifier在数据库中占用16个字节，出现重复的概率非常小，以至于可以认为是0。我们经常从注册表中看到类似
{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}
的东西实际上就是一个UniqueIdentifier，Windows用它来做COM组件以及接口的标识，防止出现重复。在.NET里管UniqueIdentifier称之为GUID（Global
Unique Identifier）。在C#中可以使用如下命令生成一个GUID：
Guid u =System.Guid.NewGuid();
对于上面提到的Order与OrderDetail的程序，如果选用UniqueIdentifier作为主键的话，我们完全可以避免上面提到的增加网络RoundTrip的问题。通过程序直接生成GUID填充主键，不用考虑是否会出现重复。
UniqueIdentifier字段也存在严重的缺陷：首先，它的长度是16字节，是整数的4倍长，会占用大量存储空间。更为严重的是，UniqueIdentifier的生成毫无规律可言，要想在上面建立索引（绝大多数数据库在主键上都有索引）是一个非常耗时的操作。有人做过实验，插入同样的数据量，使用UniqueIdentifier型数据做主键要比使用Integer型数据慢，所以，出于效率考虑，尽可能避免使用UniqueIdentifier型数据库作为主键键值。
4使用“COMB（Combine）”类型既然上面三种主键类型选取策略都存在各自的缺点，那么到底有没有好的办法加以解决呢？答案是肯定的。通过使用COMB类型（数据库中没有COMB类型，它是Jimmy
Nilsson在他的“The Cost of GUIDs asPrimary Keys”一文中设计出来的），可以在三者之间找到一个很好的平衡点。
COMB数据类型的基本设计思路是这样的：既然UniqueIdentifier数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么我们能不能通过组合的方式，保留UniqueIdentifier的前10个字节，用后6个字节表示GUID生成的时间（DateTime），这样我们将时间信息与UniqueIdentifier组合起来，在保留UniqueIdentifier的唯一性的同时增加了有序性，以此来提高索引效率。也许有人会担心UniqueIdentifier减少到10字节会造成数据出现重复，其实不用担心，后6字节的时间精度可以达到1/300秒，两个COMB类型数据完全相同的可能性是在这1/300秒内生成的两个GUID前10个字节完全相同，这几乎是不可能的！在SQL
Server中用SQL命令将这一思路实现出来便是：
DECLARE @aGuidUNIQUEIDENTIFIER
SET @aGuid =CAST(CAST(NEWID() AS BINARY(10))
+ CAST(GETDATE()AS BINARY(6)) AS UNIQUEIDENTIFIER)
经过测试，使用COMB做主键比使用INT做主键，在检索、插入、更新、删除等操作上仍然显慢，但比Unidentifier类型要快上一些。
二.MySQL常用命令
1、如何登陆MYSQL数据库
mysql -u username -p2、如何开启/关闭mysql服务
service mysql start/stop3、查看mysql的状态
service mysql status4、如何显示数所有数据库
show databases5、如何获取表内所有字段对象的名称和类型
describe table_name;
三.每日十题
1.简述Django对HTTP请求的执行流程。
答：
Django 和其他 Web 框架的 HTTP处理的流程大致相同，Django 处理一个 Request 的过程是首先通过中间件，然后再通过默认的 URL 方式进行的。
我们可以在 Middleware 这个地方把所有 Request 拦截住，用我们自己的方式完成处理以后直接返回 Response。
2.简述Django下的（内建的）缓存机制。
答：
缓存的目的是为了避免重复计算，特别是对一些比较耗时间、资源的计算。
静态的网站的内容都是些简单的静态网页直接存储在服务器上，可以非常容易地达到非常惊人的访问量。但是动态网站因为是动态的，也就是说每次用户访问一个页面，服务器要执行数据库查询，
启动模板，执行业务逻辑到最终生成一个你所看到的网页，这一切都是动态即时生成的。从处理器资源的角度来看，这是比较昂贵的。
对于大多数网络应用来说，过载并不是大问题。因为大多数网络应用并不是washingtonpost.com或Slashdot；它们通常是很小很简单，或者是中等规模的站点，只有很少的流量。
但是对于中等至大规模流量的站点来说，尽可能地解决过载问题是非常必要的。
3.Django中Model的SlugField类型字段有什么用途？
答：
"Slug" 是一个报纸术语. slug 是某个东西的小小标记(短签), 只包含字母,数字,下划线和连字符.它们通常用于URLs.
若你使用 Django 开发版本,你可以指定 maxlength. 若 maxlength 未指定, Django 会使用默认长度: 50. 在以前的 Django 版本,没有任何办法改变 50 这个长度.
这暗示了 db_index=True.
它接受一个额外的参数: prepopulate_from, which is a list of fields from which to auto-populate the slug, via JavaScript, in the object's admin form:
models.SlugField(prepopulate_from=("pre_name", "name"))
prepopulate_from 不接受 DateTimeFields.
admin 用一个``<input type="text">``表示 SlugField 字段数据(一个单行编辑框)
4.Python Web开发常用的框架有哪些？
答：
1.Django
2.Flask
3.Tornado
5.Python中的变量作用域（变量查找顺序）。
答：
在python中，变量查找遵循LGB原则，即优先在局部作用域(local scope)中对变量进行查找，失败则在全局作用域(global scope)中进行查找,
最后尝试再内建作用域(build-in scope)内查找，如果还是未找到的话，则抛出异常。后来由于闭包和嵌套函数的出现，作用域又增加了外部作用域，
这样变量的查找作用域优先级变为：局部、外部、全局和内建。
6.解释Python脚本程序的“__name__”变量及其作用。
答：
__name__和其他一些以__开头和结尾的变量是特殊变量，代表特殊的意思。一个文件在直接执行时，__name__ 的值就是__main__。 在调试程序时比较常用。
7.简单解释Python的字符串驻留机制。
答：
字符串驻留机制的优缺点如下：
优点：能够提高一些字符串处理任务在时间和空间上的性能，
缺点：在创建或驻留字符串时的会花费更多的时间。
连接字符串 :
由于字符串的改动不是inplace的操作，需要新建对象，因此不推荐使用+来拼接字符串，推荐使用join函数，因为join函数在拼接字符串之前会计算所有字符串的长度，然后逐一拷贝，
仅新建一次对象。
字符串驻留限制:
仅包含下划线（_）、字母和数字的字符串会启用字符串驻留机制驻留机制。因为解释器仅对看起来像python标识符的字符串使用intern()方法，而python标识符正是由下划线、字母和数字组成。
字符串驻留时机：
字符串只会在编译时进行驻留，而不是在运行时。
整数驻留 ：
python只会针对整数范围为[-5, 256]的整数启用字符串驻留
8.简述什么是浏览器事件。
答：
浏览器事件指载入文档直到该文档被关闭期间的浏览器事件，如浏览器载入文档事件onload、关闭该文档事件onunload、浏览器失去焦点事件onblur、获得焦点事件onfocus 等。
9.解释下HTTP常见响应状态码。
答：
1xx（临时响应）：表示临时响应并需要请求者继续执行操作的状态代码。
http状态码 100 （继续） 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
http状态码 101 （切换协议） 请求者已要求服务器切换协议，服务器已确认并准备切换。
2xx （成功）：表示成功处理了请求的状态代码。
http状态码 200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
http状态码 201 （已创建） 请求成功并且服务器创建了新的资源。
http状态码 202 （已接受） 服务器已接受请求，但尚未处理。
http状态码 203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
http状态码 204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
http状态码 205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
http状态码 206 （部分内容） 服务器成功处理了部分 GET 请求。
3xx （重定向）：表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。
http状态码 300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
http状态码 301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
http状态码 302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
http状态码 303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
http状态码 304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
http状态码 305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
http状态码 307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
4xx（请求错误）：这些状态代码表示请求可能出错，妨碍了服务器的处理。
http状态码 400 （错误请求） 服务器不理解请求的语法。
http状态码 401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
http状态码 403 （禁止） 服务器拒绝请求。
http状态码 404 （未找到） 服务器找不到请求的网页。
http状态码 405 （方法禁用） 禁用请求中指定的方法。
http状态码 406 （不接受） 无法使用请求的内容特性响应请求的网页。
http状态码 407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
http状态码 408 （请求超时） 服务器等候请求时发生超时。
http状态码 409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
http状态码 410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
http状态码 411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
http状态码 412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
http状态码 413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
http状态码 414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
http状态码 415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
http状态码 416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
http状态码 417 （未满足期望值） 服务器未满足”期望”请求标头字段的要求。
5xx（服务器错误）：这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。
http状态码 500 （服务器内部错误） 服务器遇到错误，无法完成请求。
http状态码 501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
http状态码 502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
http状态码 503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
http状态码 504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
http状态码 505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。
10。Python是如何进行内存管理的？
答：
内存池（memory pool）的概念：