mysql怎样导入百万级数据

关于mysql处理百万级以上的数据时如何提高其查询速度的方法

最近一段时间由于工作需要，开始关注针对Mysql数据库的select查询语句的相关优化方法。

由于在参与的实际项目中发现当mysql表的数据量达到百万级时，普通SQL查询效率呈直线下降，而且如果where中的查询条件较多时，其查询速度简直无法容忍。曾经测试对一个包含400多万条记录（有索引）的表执行一条条件查询，其查询时间竟然高达40几秒，相信这么高的查询延时，任何用户都会抓狂。因此如何提高sql语句查询效率，显得十分重要。以下是网上流传比较广泛的30种SQL查询语句优化方法：

1、应尽量避免在 where 子句中使用!=或<> *** 作符，否则将引擎放弃使用索引而进行全表扫描。

2、对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

3、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num=0

4、尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or num=20

可以这样查询：

select id from t where num=10

union all

select id from t where num=20

有的。插入大量数据导致越来越慢甚至崩溃越来越慢说明执行当前的 *** 作可能已经占用了你大量的内存，数据库本身执行 *** 作越来越费力，电脑是在被搞得太忙了处理的事情太多，几乎处理不过来了，这个时候显然如果能释放不需要的内存资源，或者提高数据库本身处理数据的性能自然是最有效的提升方式。

offset+limit方式的分页查询，当数据表超过100w条记录，性能会很差。

主要原因是offset limit的分页方式是从头开始查询，然后舍弃前offset个记录，所以offset偏移量越大，查询速度越慢。

比如: 读第10000到10019行元素(pk是主键/唯一键).

使用order by id可以在查询时使用主键索引。

但是这种方式在id为uuid的时候就会出现问题。可以使用where in的方式解决：

带条件的查询：

如果在分页查询中添加了where条件例如 type = 'a’这样的条件，sql变成 ：

这种情况因为type没有使用索引也会导致查询速度变慢。但是只添加type为索引查询速度还是很慢,是因为查询的数据量太多了。这个时候考虑添加组合索引，组合索引的顺序要where条件字段在前，id在后，如 (type,id)，因为组合索引查询时用到了type索引，而type跟id是组合索引的关系，如果只select id ，那么直接就可以按组合索引返回id，而不需要再进行一次查询去返回id

使用uuid作为主键不仅会带来性能上的问题，在查询时也会遇到问题。

因为在使用select id from table limit 10000,10 查询id数据时，默认是对id进行排序，返回的是排序后的id结果，如果我们想按插入顺序查询结果，这样查询出来的结果就与我们的需求不相符。

聚集索引跟非聚集索引：聚集索引类似与新华字典的拼音，根据拼音搜索到的信息都是连续的，可以很快获取到它前后的信息。非聚集索引类似于部首查询，信息存放的位置可能不在一个区域。对经常使用范围查询的字段考虑使用聚集索引。

InnoDB中索引分为聚簇索引（主键索引）和非聚簇索引（非主键索引），聚簇索引的叶子节点中保存的是整行记录，而非聚簇索引的叶子节点中保存的是该行记录的主键的值。

如果您的表上定义有主键，该主键索引是聚集索引。

如果你不定义为您的表的主键时，MySQL取第一个唯一索引（unique）而且只含非空列（NOT NULL）作为主键，InnoDB使用它作为聚集索引。

如果没有这样的列，InnoDB就自己产生一个这样的ID值，

优先选index key_len小的索引进行count(*),尽量不使用聚簇索引

在没有where条件的情况下，count(*)和count(常量)，如果有非聚簇索引，mysql会自动选择非聚簇索引，因为非聚簇索引所占的空间小，如果没有非聚簇索引会使用聚集索引。count(primary key)主键id为聚集索引，使用聚集索引。有where条件的情况下，是否使用索引会根据where条件判断。

---