mysql 数据量超过百万后怎么处理

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

5、下面的查询也将导致全表扫描：(不能前置百分号)

select id from t where name like ‘�1�7c%’

若要提高效率，可以考虑全文检索。

6、in 和 not in 也要慎用，否则会导致全表扫描，如：

select id from t where num in(1,2,3)

对于连续的数值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

MySQL 随着版本不停迭代，崩溃的现象越来越少，也越来越隐蔽。

一旦遇到生产环境上的 MySQL 崩溃，就需要保留现场信息，供分析用。虽然 MySQL 的 error log 中会打印部分信息，但对于比较隐蔽的崩溃，往往显得力不从心。

通过开启 *** 作系统级别、放开用户限制、启用 MySQL 参数三个步骤，我们启用了 MySQL 的 coredump 功能，使得 MySQL 崩溃时留下了足够的线索。

对于复杂崩溃的分析，还是需要将 coredump 交给专业的研发工程师手里，或者提交给 MySQL 开发团队。

不过不管是什么场景，能提供一份 coredump，所有技术人员都会感谢你的。

跑一个推荐算法的DEMO需要导入2百万的数据

不动脑的想象用batch insert, 批量提交的方式

尝试发现其实速度并不乐观，2000条/分钟的写入速度，

200 0000 / 2000 = 100分钟，速度不能接受，尝试其他办法。

大批量数据的正确方式就文件导入方式进行，个人觉得10万数据以上用batch insert就比较吃力了。

load data方法只支持mysql 5.5版本及以上

执行步骤：

secure_file_prive=null 限制mysqld 不允许导入导出

secure_file_priv=/tmp/ 限制mysqld的导入导出只能发生在/tmp/目录下

secure_file_priv=' ' 不对mysqld的导入导出做限制

修改secure_file_prive，直接找到my.ini中secure_file_prive修改为空重启mysql即可

随意执行，如果位置不对会给出相应的提示位置，然后再将需导入的文件copy至相应位置再执行即可 (load data infile语法需自行了解。)

---