MySQL的架构上的进化历程
•为什么MySQL能在关系型数据库领域混的风生水起?
能以较低的成本解决问题
•MySQL生态的进化历程
1.单机
2.读写分离
3.•数据分片
•代码应该与环境相适应
1.由于单机的性能有限、MySQL通过读写分离的方式把压力分发到不同的机器上
2.极端情况下即使有读写分离、但是主库还是不能满足写操作的性能要求
3.为了把写的压力也分发出去、MySQL做了数据分片
•什么叫代码适应环境
1.procedure 此类把业务逻辑封装到SQL层实现的手段有什么问题
2.由于中间件无法知道procedure是只读、读写、还是只写中的哪一种,所以它只能将请求发往所有分片,这样业务压力就分发不出去了
MySQL最佳实践
1.业务逻辑应该尽可能的在应用服务器上实现
2.力求业务用户只要有select update delete insert 权限就能完成
•SQL语言与其它编程语言的不同
1.不同于其它的编程语言,SQL语言只要你描述你要什么就行,而其它语言你要告诉计算机它要怎么去做。
2.写在前面的不一定最先得到执行
•为什么oracle 、mysql、sql-server … 它们的SQL语句都长的差不多
1.ANSI(美国国家标准化组织) & ANSI-SQL
2.因为大家都参照同一套标准、并且在标准之上加上了一些个人的创作、这就形成了不同的SQL方言,所以它们都大致上相同但是又各有各的特色
•ANSI-SQL标准下SQL的一生
•from
1.from 子句虽然没有写在select查询的最前面,但是它是整个select查询中最先开始执行的;from用于指定要查询的表名,以及对这些表进行的操作。
2. from 子句返回的一个集合,没有其它操作的情况下它返回表中所有的行
•where
1.where 的输入是from阶段的输出、where会根据指定的条件对行进行过虑
2.注意SQL的三值逻辑 True,False,NULL ;在where阶段只返回条件判断为True的行,聚合函数又会根据写法的不同而区别对待
3.解答select中给出的名字为何不能在where中使用
•SQL的三值逻辑
•为什么select中给出的别名不能在where中使用
因为where子句在select子句之前执行,所以select中定义的别名在where中不能用
•group by
1.group by的输入是where阶段的输出、group by 会根据指定的条件对行进行分组、注意group by阶段返回的是“组”的集合而不是“行”的集合。 select子句中如果出现了没在group by 子句中的列名,会引发错误;除非它返回一个标量(聚合函数返回标量)
•groupy by 的常见误用
•从组中随机抽取一行作为村量返回
•having 是对组进行过虑
1.having的输入是group by 的输出 having会根据给出的条件对组进行过滤
2.注意SQL的三值逻辑
•order by
1.对数据进行排序,由于它在select之后执行所以它可以使用select中定义的别名
范式化
•关系模型的目标是什么?
1.要用最小或完全无冗余地支持完整数据的持久化表示,而且数据完整性要定义为模型的一部分
•如何确定自己的表结构已经到了第几范式
1.第一范式:行必须要唯一而且原性是原子的
2.第二范式:在满足第一范式的基础之上再加上所有非键属性必须完成依赖于键
3.第三范式:在满足第二范式的基础之上再加上所有非键属性必须非传递依赖于键
•例子
只范式化到了第一范式,因为存在为非键属性对键属性的部分依赖,通过orderid能找到的应该有orderdate,customerid,companyname 所以要对Orders关系进行分解
只范式化到了第二范式,因为存在为非键属性对键属性的传递,通过customerid能找到companyname。
只范式化到了第二范式,因为存在为非键属性对键属性的传递,通过customerid能找到companyname
SQL设计模式
1.与OOP中的设计模式差不多,都讲的是针对某一特定问题的最佳编码实现