MySQL数据库插入速度和读出速度
（1）改进数据库插入性能中心的思想：尽量将数据写入数据文件，尽可能减少数据库的检查点操作，这一次修改了以下四个配置项：1）设置innodb_flush_log_at_trx_commit配置0；设置过去的经验0、插入速度将大大提高。
0：将日志缓冲区写入日志文件并刷新
1：每个日志文件都被写入日志缓冲区。
2：每次提交时都将日志缓冲区写入文件中。
2）的innodb_autoextend_increment配置调整，由于默认的8m 128M
这种配置的作用主要是当表空间满时，MySQL系统自动扩展是必需的。每个表空间扩展将使每个SQL处于等待状态。增加自动扩展大小可以减少表空间自动扩展的数量。
3）的innodb_log_buffer_size配置调整，由于默认的1m 16M
这种配置功能设置innodb数据库引擎写日志缓存；缓存段增加减少数据库中的数据文件的数量。
4）的innodb_log_file_size配置调整，由于默认的8m 128M
这种配置功能设置innodb数据库引擎的大小UNDO日志；从而降低了数据库检查点操作。
经过以上调整，系统的插入速度在过去的10分钟增加到数万成千上万的1W。注：以上参数应根据不同的机器调整。特别是，innodb_flush_log_at_trx_commit，innodb_log_buffer_size和innodb_log_file_size需要仔细调整，因为他们涉及mysql容灾。
（2）提高数据库读取速度，数据库级读取速度增加主要是由于以下几点：简化SQL、索引和分区；检查sql程序最简单，查询上的索引就增加了。我们只能使用武器：表分区。
数据库MySQL预分区准备：在MySQL中，表空间是存储数据和索引的数据文件。
由于共享表空间修改为支持多数据库表空间的S11；
两表wb_user_info_sina和wb_user_info_tx修改成单独的表空间；（新浪：1700w数据，2.6g大数据文件，腾讯1400W，2.3g大数据文件）。
分区操作：
首先删除现有主键和索引
创建ID联合主键，UID
那么UID作为分区键值。此时 / / / MySQL VaR数据查看数据文件，你可以看到，这两大表不同的表空间被分为几个不单独划分空间。（在这个时候，如果用户查询为检索条件，它不增加速度；因为关键是数据的存储、分区和分区索引是不成立的。我觉得这不是比Oracle一点半点）。
该指数是建立在流体领域。再次 / / / MySQL VaR数据文件夹查看数据文件，很是郁闷的发现每个分区的大小是big.mysql仍存储索引和数据在同一个表空间一样，如果指数可以分离数据，它可以更好的管理。
经过以上调整，系统不能反映一段时间的阅读速度；基本完成5K的数据在2 ~ 3秒更新。
mysql数据库插入速度调整补充信息：
MySQL将插入速度从开始的1000分钟增加到每秒10000次。我相信大家都在等待紧急的相关介绍，我做了整个调优过程。改进了数据库插入性能中心的思想：
1。尝试让数据库一次写入数据文件。
2。减少数据库的检查点操作
三.程序尽可能地缓冲数据，以便批量插入和提交。
4，减少系统的IO冲突。
根据以上四点，对MySQL服务作了如下调整：作为一个业余DBA：
负责修改记录，包括MySQL服务器的配置，提高MySQL的整体写作速度；特别是以下三个变量的值：innodb_autoextend_increment数据库，innodb_log_buffer_size，innodb_log_file_size；三变量的默认值为5M，8M，8M，根据服务器的内存大小和具体用法，三如下：128M，16m，128M。同时，文件原来的2改为8 log日志文件。修改主要满足第一和第二点。例如，增加innodb_autoextend_increment是避免MySQL的检查点操作由于数据文件频繁自动扩展。
将大表分成独立的空表和分区，然后在不同分区下的多个不同的磁盘阵列中。
经过以上的修改操作，我看到了下面的快乐结果：
获取测试结果：
查询OK，受影响的2500000行（4分钟4.85秒）
记录：2500000个重复：0个警告：0
查询OK，受影响的2500000行（4分钟58.89秒）
记录：2500000个重复：0个警告：0
查询OK，受影响的2500000行（5分钟25.91秒）
记录：2500000个重复：0个警告：0
查询OK，受影响的2500000行（5分钟22.32秒）
记录：2500000个重复：0个警告：0
最后表中的数据量：
------------ + +
|计数（*）|
------------ + +
10000000 | |
------------ + +
由于上述的结果，数据量的增加会对插入的性能有一定的影响。然而，整体速度仍然很有价，不到一天的时间，4亿的数据可以被正常处理。预计该数据库的瓶颈已经被巧妙地解决了，和结果是程序猿是痛苦的向我抱怨，和哥哥是不那么残忍。