iOS实训笔记—学习数据库、服务端优化

IOS开发实训第十二周周报

学习知识点归纳

1、数据库的优化策略

（1）数据类型的优化

更小的通常更好，因为它占用更小的磁盘、内存和cpu缓存，且处理时需要的cpu周期更小，但需要确保没有低估需要存储的值的范围；

简单的数据类型操作需要更少的cpu处理周期，如：整型比字符串代价更低、MySQL内建类型（date，time，datetime）而非字符串来存储时间、用整型存储IP地址；

尽量避免使用NULL，通常最好指定列为NOT NULL，除非真的需要存储NULL值，因为可为 NULL 的列使得索引、索引统计和值比较都更复杂，需要进行特殊处理；

（2）索引优化

建立索引的优点：1、索引可以大大减少数据库表的扫描量；2、索引可以帮助服务器避免排序和临时表；3、索引可以将随机I/O变成顺序I/O；

索引类型：

B-tree索引，所有数据按索引值顺序存储，并且每一个叶子叶到根的距离相等，适用于范围查找；

哈希索引：对于每一行数据，存储引擎都会对所有索引列计算一个哈希码，哈希索引将所有哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针，应用于某些频繁引用的索引值，他会在内存中基于B-Tree索引的基础上创建一个哈希索引；

（3）查询语句优化

优化数据访问：避免查询不需要的记录：使用limit； 避免多表查询查询所有列：不要随意使用select * ；当重复查询相同数据时：采用缓存；

从好到坏的where条件应用：最佳：存储引擎层在索引中使用where过滤不匹配的记录；次佳：使用索引覆盖扫描，直接从索引中过滤不需要的记录并返回，在服务器层完成；最次：先从数据表中返回数据，然后过滤，需要回表查询

重构查询：将一个大的查询拆分为几个小的查询，对大查询“分而治之”，减少锁持有的时间

2、服务端的优化策略

对于高并发的解决方案，通常为负载均衡：在服务器集群中，由有一台服务器充当调度者的角色，用户的所有请求都会首先由它接收，调度者再根据每台服务器的负载情况将请求分配给某一台后端服务器去处理；

然而我们的项目只租用了一台服务器，因此无法考虑负载均衡，但我认为有必要深入了解这一概念；

实现方式：

（1）反向代理负载均衡：反向代理服务器是一个位于实际服务器之前的服务器，所有向我们网站发来的请求都首先要经过反向代理服务器，服务器根据用户的请求要么直接将结果返回给用户，要么将请求交给后端服务器处理，再返回给用户。

优点
隐藏后端服务器；故障转移；合理分配任务

缺点
调度者压力过大

（2）HTTP重定向负载均衡：当用户向服务器发起请求时，请求首先被集群调度者截获；调度者根据某种分配策略，选择一台服务器，并将选中的服务器的IP地址封装在HTTP响应消息头部的Location字段中，并将响应消息的状态码设为302，最后将这个响应消息返回给浏览器；当浏览器收到响应消息后，解析Location字段，并向该URL发起请求，然后指定的服务器处理该用户的请求，最后将结果返回给用户。

在使用HTTP重定向来实现服务器集群负载均衡的过程中，需要一台服务器作为请求调度者。用户的一项操作需要发起两次HTTP请求，一次向调度服务器发送请求，获取后端服务器的IP，第二次向后端服务器发送请求，获取处理结果。

优点：实现逻辑简单

缺点：在HTTP重定向方法中，调度服务器只在客户端第一次向网站发起请求的时候起作用，由于不同用户的访问时间、访问页面深度有所不同，从而每个用户对各自的后端服务器所造成的压力也不同。而调度服务器在调度时，无法知道当前用户将会对服务器造成多大的压力，因此这种方式无法实现真正意义上的负载均衡，只不过是把请求次数平均分配给每台服务器罢了。

总结

经过本周的学习，我对于优化策略有了更加深刻的理解，并将它们应用于项目中，以提升app的性能；