影响网站性能的因素
文件上传
文件上传会占用大量的服务器带宽,所以我们一般不会往web服务器进行上传操作,
如果需要上传文件,我们可以建立专门的文件上传服务器.还可以使用云存储,比如OSS
之类的,这样会踢服务器分担很大的压力
然后就是web服务器的性能
php7的性能提升,其实相对于我们业务逻辑小一点的网站来说,意义并没有想象中那么大,
就算Facebook的各种优化,拿来给小网站用,也不会看到有多么明显的提升.即使是java,
虽然速度比php快,毫秒级别的,也不是我们能感觉出来的.再然后就是web服务器的
性能,比如apache和nginx.这个影响用户的连接数,我们可以多配置几台web服务器来解决这个问题.
然后的问题就是连接mysql
php每处理一个请求,就会开启一个进程(一个进程可以有多个线程,但是PHP是单线程的,而java是单进程多线程的),
一些写的很差的网站,很可能处理一个
用户的请求都建立很多和mysql的连接,要知道,这些连接走的也tcp协议,也会占用IO.请求不结束,连接不
关闭,这样服务器的IO很容易就会被占满,无法再处理其他用户的请求.
在java中我们可以用数据库连接池来处理这个问题,但是PHP并没有连接池,就算你用单态模式实例化的mysql
连接对象,也仅仅是做到一个请求只连接一次,做不到连接池的效果.
其实是否使用连接池,要根据具体的情况来看,连接池的固定分配,很容易造成某个服务大量访问,对应服务的
服务器瘫痪
如果PHP想要使用连接池也可以实现,通过使用c语言的扩展就行了
最后问题就落在了mysql系统上
mysql在接收到PHP发来的请求的时候,会根据发来的语句执行一系列的操作.我们知道,mysql执行查询会比写
数据快,写数据呢,我们可以通过建立独立的写服务器,来防止在写数据的时候锁表.
那么查询呢?
我们从两个方面来优化
一是sql语句:
像like这个模糊查询是一定不要用的,效率是最低了,遇到查模糊查询的地方,我们可以使用mysql的全文索引
,处理中文在用中文分词技术
关于查询语句中的关联查询,还是一条一条查询的效率问题:
先说一下mysql查询机制:
在没有索引的情况下,查询会检索整个表,一条一条往下查,即使查到数据也会继续查完整张表
基于这个原理,关联查询就会就会产生笛卡尔积(假设两张表,先从第一张第一条数据开始,去匹配第二个表的所有数据,其结果就是100x100,查了一万次,100条数据就要查一万次,真可怕)
在数据量少的时候呢,我们关联查询是没有问题的(10x10=100次嘛)
当时数据一旦多起来就很可怕了(10000x10000=一亿,一万条数据要查一亿次,可怕不)
这个时候可能不用关联查询会好一些,我们先查第一张表,查一万次取得数据,在查第二张表查一万次,取得数据,总计查两万次.
二是建立索引
为什么查索引会比不带索引的快很多呢?
这里涉及到索引的机制:
给一个字段建立索引,会生成对应的字段一个索引文件,存储形式是以键值对的一个数组.在查询的时候,先查索引,通过红黑树算法查询,命中之后再通过对应的键直接想表中取值,直接命中会非常的快
那么我们在实际项目中怎么处理呢?
比如用户表,我们可以把所有用户放在一个表了,索引怎么建立呢,当然可以建立一个索引,那么数据一旦非常大,查/Users/xdl/Documents/笔记/homestead安装.md
询也会很慢的,我们可以分表,减少查询的区
总结一下mysql的优化顺序
- 优化sql语句
- 加缓存
- 在应用层做主从复制,读写分离
- 分区
- 垂直分
- 水平分
mysql的写入优化
解决并发写
锁表是一种效率很低的方式,不推荐使用
主从复制,也就是读写分离,也仅仅解决了并发读的问题,因为写服务器还是只有一台
那么只有分表了,可以减轻写的压力.
通过计算md5加密后的uuid计算出每次往哪一张表里插入数据,一般分表都是2的N次方
真正意义上的分布式数据库,就是分片技术,把不同类型的数据放在不同的库里面.里面再进行分表操作.