标签：ext 保险 行数据 mysq sql 响应 业务 order 读取
某些进程/服务消耗更多CPU资源（服务响应更多请求或存在某些应用瓶颈）；
发生比较严重的swap（可用物理内存不足）；
发生比较严重的中断（因为SSD或网络的原因发生中断）；
磁盘I/O比较慢（会导致CPU一直等待磁盘I/O请求）；
绝对不要因表数据量小，sql语句随便写都行，随便join都不会出现性能瓶颈，决不能有这
种思想。
尽量避免join表 join表笛卡尔积
如果要join表一定要把where条件写全，安全起见最好加个limit。
一次请求读写的数据量太大，导致磁盘I/O读写值较大，例如一个SQL里要读取或更新几万>行数据甚至更多，这种最好是想办法减少一次读写的数据量；
SQL查询中没有适当的索引可以用来完成条件过滤、排序（ORDER BY）、分组（GROUP BY）
、数据聚合（MIN/MAX/COUNT/AVG等），添加索引或者进行SQL改写吧；
瞬间突发有大量请求，这种一般只要能扛过峰值就好，保险起见还是要适当提高服务器的>配置，万一峰值抗不过去就可能发生雪崩效应；
因为某些定时任务引起的负载升高，比如做数据统计分析和备份，这种对CPU、内存、磁盘
I/O消耗都很大，最好放在独立的slave服务器上执行；
服务器自身的节能策略发现负载较低时会让CPU降频，当发现负载升高时再自动升频，但通
常不是那么及时，结果导致CPU性能不足，抗不过突发的请求；
使用raid卡的时候，通常配备BBU（cache模块的备用电池），早期一般采用锂电池技术，>需要定期充放电（DELL服务器90天一次，IBM是30天），我们可以通过监控在下一次充放电
的时间前在业务低谷时提前对其进行放电，不过新一代服务器大多采用电容式电池，也就>不存在这个问题了。
文件系统采用ext4甚至ext3，而不是xfs，在高I/O压力时，很可能导致%util已经跑到100%了，但iops却无法再提升，换成xfs一般可获得大幅提升；
内核的io scheduler策略采用cfq而非deadline或noop，可以在线直接调整，也可获得大幅
提升。
标签：ext 保险 行数据 mysq sql 响应 业务 order 读取
原文地址：http://www.cnblogs.com/mikeluwen/p/7777454.html
