mysql 数据库,表每天会插入30W条数据,该表数据千万级,查询效率很慢,建立索引是否利大于弊?

mysql 数据库,表每天会插入30W条数据,该表数据千万级,查询效率很慢,建立索引是否利大于弊?,第1张

呵呵,我认为可以建立索引,但必须要合理分配IO

为什么:

1:索引是建立在表的一列或多个列上的辅助对象,目的是加快访问表中的数据(加快查询);

2:通常,通过索引查询数据比全表扫描要快. 当ORACLE找出执行查询和Update语句的最佳路径时, ORACLE优化器将使用索引. 除了那些LONG或LONG RAW数据类型, 你可以索引几乎所有的列. 在大型表中使用索引特别有效.

3:虽然使用索引能得到查询效率的提高,但是我们也必须注意到它的代价. 索引需要空间来 存储,也需要定期维护, 每当有记录在表中增减或索引列被修改时, 索引本身也会被修改. 这意味着每条记录的INSERT , DELETE , UPDATE将为此多付出4 , 5 次的磁盘I/O . 因为索引需要额外的存储空间和处理,那些不必要的索引反而会使查询反应时间变慢.

4:解决方案:

4.1利用分表 *** 作。千万级的数据必须要用垂直分表 *** 作,这样每天插入的数据在不同的表中,索引也就在不同的表的索引中,减少插入带来的效率问题

4.2 索引表空间和数据表空间分开存放。不要把索引和表数据建立在一个磁盘中,利用两个磁盘,分别进行IO *** 作,也就是索引表空间和数据表空间彻底分开。提高系统IO吞吐量。会有一定的效果,但不如第一个的效果好

mysql>delimiter $

mysql>SET AUTOCOMMIT = 0$$

mysql>create procedure test()

begin

declare i decimal (10) default 0

dd:loop

INSERT INTO `million` (`categ_id`, `categ_fid`, `SortPath`, `address`, `p_identifier`, `pro_specification`, `name`, `add_date`, `picture_url`, `thumb_url`, `is_display_front`, `create_html_time`, `hit`, `buy_sum`, `athor`, `templete _style`, `is_hot`, `is_new`, `is_best`) VALUES

(268, 2, '0,262,268,', 0, '2342', '423423', '123123', '2012-01-09 09:55:43', 'upload/product/20111205153432_53211.jpg', 'upload/product/thumb_20111205153432_53211.jpg', 1, 0, 0, 0, 'admin', '0', 0, 0, 0)

commit

set i = i+1

if i= 1000000 then leave dd

end if

end loop dd

end$

mysql>delimiter

mysql>call test

结果

mysql>call testQuery OK, 0 rows affected (58 min 30.83 sec)

非常耗时。

于是我又找了一个方法

先用PHP代码生成数据,再导入:

导入时把生成索引给关掉,应该能快一点.

不要一边导入一边建立索引.

8G数据,应该也不那么慢了.

把sql语句文件读取出一部分看看,建表语句中,应当有建立索引的部分,删掉它!

只做建表和插入数据两件事.

还有,看看数据库有没有外键?

尽量在插入数据过程中去掉外键关联.

等数据插入完成之后再加索引和外键,应该能提高很多读写性能.

截取一部分数据,例如100Mb.

插入一下试试,可以预先对整体时间有一个预期.

还有,真的要弄台好点的电脑,或者去借一台,等把数据导入完成之后,把msyql的库文件直接复制出来放自己机器上跑就好.

emm..

再追加点信息,要先搞明白,sql原文件里,到底都执行了哪几类 *** 作?

可能需要你用c之类写点小工具,或者别的什么语言,分块读取并处理文件.

8G..

嗯,还好.

现在内存都够大,否则你都没法直接用软件打开了.

只有8G也可以直接用软件打开看.

停掉索引真的可以大幅度加快插入数据的速度.

建议试一试!


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/7510244.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-06
下一篇 2023-04-06

发表评论

登录后才能评论

评论列表(0条)

保存