一台服务器下有多个库，一个库下有1到多张表，表有多行多列的数据。
postgresql也是一个开源数据库，而且sql标准执行方面，比mysql要严格。
# 对于email，并非全部的存储一个字段，而是分开存储了，变得更加高效。
时间函数与流程控制函数
md5(); md5加密，不可逆，单向加密，不可逆。
- 碰撞性低 （重复的概率低）
user(); 返回用户即所在主机 , 判断自己的身份
version(); 服务器版本 , 服务器比较古老，某些兼容性问题，需要判断。
MySQL函数使用注意事项
PHP中和MySQL中都有相同的函数，那么优先使用哪种?
- MySQL的函数肯定是要影响查询速度.
应该在建表的时候，通过合理的表结构减少函数的使用。 比如：emial, 按 @ 前后拆分。 - 如果确实需要使用函数。
优先放在业务逻辑层，即PHP层处理。
- 在查询时使用了函数，最大的一个坏处。
如果针对某些查询，而此列，用上了函数来判断。
总结：在where条件中，对某列的使用了函数，由此列的索引不发挥作用。
在查询中，经常把查询结果 当成临时表来看。
View是什么? View 可以看一张虚拟表。是表通过某种运算得到的一个投影(映射)。
View 没有实实在在的数据，只是通过表，经过一系列的运算，运算出来的一个结果。
表的变化，会影响到视图。
查询每个栏目下，商品的平均价格,并取平均价前3高的栏目
group by cat_id,查询出每个栏目下的平均价，设为结果集A。无论是查询前3高，还是前3低，都要用到结果集A。结果集A频繁使用，因此可以把结果保存一张表，下次来查这张表。但是，如果goods表又添加了商品，A结果集就与保存的临时表不一样了，不会单项更新数据，这时，可以用视图解决。
建视图的，要指定视图的列名与列类型么?
不需要，它是个影子，继承了上面的字段。 只是一种关系。
既然视图只是表的某种查询的投影，所以主要的步骤在于查询表上，查询的结果命名为视图就可以了。
比如:复杂的统计时，先用视图审查一个中间结果，在查询视图。
比如:某张用户表为例。 2个网站搞合作，可以查询对方网站的用户.
需要向对方开发用户表的权限，但是呢，又不想开放用户表中的密码字段。创建一个视图，除去密码字段。
开放这个视图的权限给对方。
- 数据多，分表时可以用到。
比如：小说站 novel 表， 1000多万篇。(一张表放200万数据，大概)
查询小说时，不知在哪张表。
表与视图，数据变化时的相互影响问题
表的数据变化，要影响到视图的变化。
视图如果变化了，表如何变?
视图某种情况下，也是可以修改的
要求：视图的数据和表的数据 一一对应。 就像函数的映射才行。
表--> 退出视图的对应的数据
视图-->推出表对应的数据
视图的定义，是一直存在的，视图并没有占用空间。
一一对应是指：根据select关系，从表中取出的行，只能计算出视图中确定的一行。反之，视图中任意抽一行，能够反推出表中的确定一行。
把建视图时的条件 和 查视图的条件 叠加起来， 直接去查表。
对于一些简单视图，在发挥作用的过程中，并没有建立临时表，而只是 把条件存起来，下次来查询，把条件一合并，直接去查表。
条件叠加相比于建临时表，那个快。
建表：查询->形成临时表->查询临时表
叠加：合并条件->查询表
需要建立临时表么，还是合并语句。
algorigthm作用就是是否需要合并条件查询语句
v2视图，并没有建立临时表
有时候，在复杂查询下，必须建立临时表。
比如，每个栏目的平均价格。
下次再查，每个栏目最高的商品价格
思考：如何合并这两个语句。
合并后，语句 出错了.
此时，语句不能合并，只能先建立临时表。
这张表，明确指定了生成临时表。
如果拿不准用什么，或者不愿意考虑。alogrithm=undefind .让系统做决定.
而人的世界中，有文字，有图片，有声音。
二进制编码 到 字符的映射，就是字符集
1个字节8个位，就足够。实际上ASSIC ，使用7个位表示就足够。
碰到>128的，就再往后找一字节，2个字节理解成中文。
继续找，找到>128,就带一个字节。<127 一个字节表示。
解决了多字节之后，又引来一个问题--世界各国的字符集，兼容问题。
unicode 只负责分配编号，而不负责在网络上传输，需要经过一定的规则进行简化。
压缩方式：UTF-8。
就像原文件 --> 压缩文件的关系
utf8占用几个字节呢?
不可能定长，压缩规则才有效果。 1-6个字节.
- 解码时，与实际编码不一致，
可修复。 - 传输过程中，编码不一致，导致字节丢失
不可修复。
客户端的字符集，设为A GBK
数据库的字符集设为B UTF8(建表的时候设置的编码)
客户端收集到是什么编码 和 服务器想存成什么编码.
连接器的特性：链接客户端与服务器
客户端的字符先发给连接器，连接器选择一种编码将其转换，临时存储。
再次转换成，服务器需要的编码
要想不乱码，需要指定客户端的编码，让连接器不理解错误。这样就不会存入错误数据。往回去的时候，还要告诉连接器，如果从服务器返回数据，应该转成什么格式。
需要明确告知服务器，客户端编码:
告诉连接器使用utf8
告诉服务器返回结果使用GBK
如果服务器设置严格，不允许插入。不严格，插入会造成数据丢失。
收到客户端编码 和 往服务器送， 两个过程.
一个中文在UTF8下是三个字节
记事本在打开的时候，分辨不出来要使用什么编码解析。
分析编码的特点，推测出来使用什么编码。
如果字节比较少，容易推测错误。
在utf8的BOM，是3个字节一个中文。
utf8文件的时候，前面多了三个字节：EF BB BF。
这3个字节不用来显示，是用来辨识utf8。是BOM信息。
在session cookie 使用前，不能有任何输出，空行空格都不行。
在utf8有BOM头的信息下，多个三个字节。会在session 或 cookie 会出现错误。
表达这个编码方式. UTF-8 utf-8 utf8 UTF8。都是指选用utf-8这种方式。名称不一样，别名。推荐UTF 大写。
* 想截取无乱码，那就说明，从 42开始截几个字符，作为一个字符。 * 从第一个字节开始，需要知道截取几个字符，比如截取1个字节，截取取出42 * 再从DC截取，需要知道，从DC往后是几个字节组成一个字符。 * 类推，这样，截取出来的字节才能保证，正是是一个个的字符。 * 关键如何判断utf8的字符的字节数。 * $str 是带截取的字符串 // 使用字符串来判断，效果不高.存储引擎与事务简单介绍
美国科学家，收集了人类的音乐，符号。(二泉映月)
不变的是数据，变化的是"存储的格式"
这个信息，无论用什么engine来存储，都一样。
但是，不同engine，都有存储信息功能，则必须不一样的地方。
总结：engine 引擎，就是mysql存储数据的不同方式。
数据库对同样的数据，有着不同的存储方式和管理方式，在mysql中，称为存储引擎。
# 建立2张一样结构的表，但是引擎不一样
# 在存储数据上是一样的。这2步，必须都完成了，转账才完成。
想这种，2步或n步，从逻辑上来讲，是一个“原子操作”
即，要么成功，要么都不成功。
使用事务. 在这种环境下诞生的一个概念，操作。
事务特性：原子性，一致性，隔离性，持久性。
原子性就是：2步或N步操作，逻辑上不可分割。
通俗说，要么成功，要么都不成功。
# 是指操作前后，值的变化，逻辑上成立。
事务结束前，每一步的操作带来的影响，别的会话看不见。
事务一旦完成，无法撤销
支付成功，生成一条支付流水。
同时，把订单改为已支付。(事务，一致性)
增删改查，左右连接，子查询。
建库/建表的数据库设计。
引擎优化，索引优化，表的范式设计，主从服务器
权限管理，数据备份，运行监控，性能检测。
