mysql 批量更新10000+的数据，有什么效率比较高的方法

首先， 插入上万条数据，对于数据库来说并不是“很大”的工作量，一般配置的笔记本电脑都可以在1分钟内完成。 所以最简单、最灵活的办法还是写SQL语句。

如果不希望DB编译器每次执行都编译SQL的话，可以使用存储过程，直接调用，性能上会好很多。也比较简单。

（几万条数据怎么地也得要时间去处理，所以不可能特别快的。）

如果由于各种原因，导致这个插入还是很慢， 而且你的MYSQL又是5.0以上版本的话，可以使用BulkCopy来进行批量 *** 作。

BulkCopy的原理就是Client直接把一个数组（DataTable）传给DB，然后传入表名，所有的编译、 *** 作都由DB自己完成，效率很高。

引用MySql.Data.dll ， 调用MysqlBulkCopy函数即可。

这个函数在处理海量数据插入的时候效率尤为明显， 小量数据反而没什么优势，而且由于传入的DataTable格式必须和表的字段一模一样（空的列也要传进去），导致C#要写很多代码来构造这个数组，所以要你自己权衡用还是不用。

我在自己的电脑上批量插入一亿条数据，Insert写法大概需要1小时,BulkCopy大概只需要5分钟。

分页查询一般 DBA 想到的办法是在某个（如ID，create_time)字段上加组合索引。这样条件排序都能有效的利用到索引，性能迅速提升。

因为如果当 LIMIT 子句变成 “LIMIT 1000000,10” 时，你会抱怨：我只取10条记录为什么还是慢？

要知道数据库也并不知道第1000000条记录从什么地方开始，即使有索引也需要从头计算一次。出现这种性能问题，多数情形下是程序员偷懒了。在前端数据浏览翻页，或者大数据分批导出等场景下，是可以将上一页的最大值当成参数作为查询条件的。SQL 重新设计如下：

SELECT *

FROM 表

WHERE create_time >'2017-07-04 09:00:00'

ORDER BY create_time limit 10

这样查询时间基本固定，不会随着数据量的增长而发生变化。

mysql数据库对1亿条数据的分表方法设计：

目前针对海量数据的优化有两种方法：

（1）垂直分割

优势：降低高并发情况下，对于表的锁定。

不足：对于单表来说，随着数据库的记录增多，读写压力将进一步增大。

（2）水平分割

如果单表的IO压力大，可以考虑用水平分割，其原理就是通过hash算法，将一张表分为N多页，并通过一个新的表（总表），记录着每个页的的位置。

假如一个门户网站，它的数据库表已经达到了1亿条记录，那么此时如果通过select去查询，必定会效率低下（不做索引的前提下）。为了降低单表的读写IO压力，通过水平分割，将这个表分成10个页，同时生成一个总表，记录各个页的信息，那么假如我查询一条id=100的记录，它不再需要全表扫描，而是通过总表找到该记录在哪个对应的页上，然后再去相应的页做检索，这样就降低了IO压力。

---