通常来说，服务器上最容易成为瓶颈的是磁盘I/O子系统，因为它的读写速度通常是最慢的。即便是现在的PCIe SSD，其随机I/O读写速度也是不如内存来得快。当然了，引起磁盘I/O慢得原因也有多种，需要确认哪种引起的。
第一步，我们一般先看整体负载如何，负载高的话，肯定所有的进程跑起来都慢。
可以执行指令 w 或者 sar -q 1 来查看负载数据或者 sar -q 的观察结果
load average大意表示当前CPU中有多少任务在排队等待，等待越多说明负载越高，跑数据库的服务器上，一般load值超过5的话，已经算是比较高的了。
引起load高的原因也可能有多种：
-
某些进程/服务消耗更多CPU资源（服务响应更多请求或存在某些应用瓶颈）；
-
发生比较严重的swap（可用物理内存不足）；
-
发生比较严重的中断（因为SSD或网络的原因发生中断）；
-
磁盘I/O比较慢（会导致CPU一直等待磁盘I/O请求）；
从 Cpu(s) 这行的统计结果也能看的出来，%us 和 %wa 的值较高，表示当前比较大的瓶颈可能是在用户进程消耗的CPU以及磁盘I/O等待上。
执行 sar -d 确认磁盘I/O是否真的较大
在这个例子中，产生瓶颈的原因比较好定位，SQL优化也不难，实际线上环境中，通常有以下几种常见的原因导致负载较高：
-
一次请求读写的数据量太大，导致磁盘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，可以在线直接调整，也可获得大幅提升。
- why-is-load-data-infile-faster-than-normal-insert-statements: 主要是解析所需的开销更少。
- High-speed inserts with MySQL: 基准测试; 中文翻译
为什么说LOAD DATA导入速度比SOURCE快很多倍呢，这是因为数据库执行SQL语句的时候会先校验语法，然后优化SQL，最后再执行。但是LOAD DATA导入的纯数据，于是就跳过了SQL的校验和优化，导入的速度也就大大提升了。
Increase Buffering, Decrease Durability innodb_buffer_pool_size = 4G (default 128M) innodb_log_buffer_size = 1G (default 16M) innodb_log_file_size = 4G (default 48M) innodb_flush_log_at_trx_commit = 0 (default 1) # log-bin = mysql-bin Time: 56 seconds (00:00:56) 1000000 rows = 17697.29 rows/sec
- 来源： load-data-fast: 各个方式的对比
load跳过SQL解析，直接生成数据库的数据文件，导入前关闭索引，导入完成后更新索引；
load的速度与文件中一行数据的大小有关系，一行数据字节数过大，load速度就越快。
load如果对应的Mysql是InnoDB，会整个load 过程当作一个事务。中途异常中断，会回滚。
如何优化了load
-
关掉自动提交
-
禁掉唯一索引
-
禁掉外键
这样能节省大量物理io
3 应用
replace
ignore
4 测试情况
140w行数据，load data：45s
insert 单行：8m
insert批量3m
insert批量：
10行 4s
100行 3.4s
1000行：3.4s
5000行：3.4s
- 来源： Load原理与测试