mysql(表:InnoDB,无索引),批量插入50万条记录后,越来越慢。

插入10000条,已用时0秒
插入20000条,已用时2秒
插入30000条,已用时3秒
插入40000条,已用时3秒
插入50000条,已用时4秒
插入60000条,已用时5秒
插入70000条,已用时6秒
插入80000条,已用时7秒
插入90000条,已用时8秒
插入100000条,已用时9秒
插入110000条,已用时11秒
插入120000条,已用时12秒
插入130000条,已用时13秒
插入140000条,已用时14秒
插入150000条,已用时15秒
插入160000条,已用时16秒
插入170000条,已用时17秒
插入180000条,已用时18秒
插入190000条,已用时19秒
插入200000条,已用时21秒
插入210000条,已用时22秒
插入220000条,已用时23秒
插入230000条,已用时25秒
插入240000条,已用时26秒
插入250000条,已用时27秒
插入260000条,已用时28秒
插入270000条,已用时30秒
插入280000条,已用时31秒
插入290000条,已用时32秒
插入300000条,已用时33秒
插入310000条,已用时34秒
插入320000条,已用时36秒
插入330000条,已用时37秒
插入340000条,已用时38秒
插入350000条,已用时39秒
插入360000条,已用时41秒
插入370000条,已用时42秒
插入380000条,已用时43秒
插入390000条,已用时44秒
插入400000条,已用时45秒
插入410000条,已用时46秒
插入420000条,已用时48秒
插入430000条,已用时49秒
插入440000条,已用时50秒
插入450000条,已用时52秒
插入460000条,已用时57秒
插入470000条,已用时66秒
插入480000条,已用时76秒
插入490000条,已用时90秒
插入500000条,已用时105秒
插入510000条,已用时123秒
插入520000条,已用时142秒
插入530000条,已用时164秒
插入540000条,已用时187秒
插入550000条,已用时212秒
插入560000条,已用时239秒
插入570000条,已用时266秒
插入580000条,已用时294秒
插入590000条,已用时323秒
插入600000条,已用时358秒
插入610000条,已用时389秒
插入620000条,已用时421秒
插入630000条,已用时458秒
插入640000条,已用时496秒

停止程序,再次运行,一万条需几十秒。
清空该表,重新运行,很快。在将近插入50万条记录时,一万条需几十秒。

public static void main(String[] args) {
    PreparedStatement pstmt = null;
    Connection conn = null;
    try {
        Class.forName("com.mysql.jdbc.Driver");
        String url = "jdbc:mysql://localhost:3306/pis";
        String username = "root";
        String password = "root";
        conn = DriverManager.getConnection(url, username, password);

        conn.setAutoCommit(false);

        String sql = "SELECT T.ID FROM PIS_PERSON_EX T WHERE T.NAME LIKE 'TEST%'";
        PreparedStatement statement = conn.prepareStatement(sql);
        ResultSet result = statement.executeQuery();

        String sql2 = "INSERT INTO PIS_RECORD (ID, RCTIMES, RCTIMEP, YEARS, MONTHS, DAYS, YMD, PERSONID, DEVICEID, NOTESTR) "
                + " VALUES (?,?,?,?,?,?,?,?,?,?)";
        pstmt = conn.prepareStatement(sql2);

        SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmss");
        Random random = new Random();
        int pos = 0;
        Date t1 = new Date();
        while (result.next()) {
            for (int i = 1; i <= 31; i++) {
                String day = i + "";
                if (i < 10) {
                    day = "0" + i;
                }

                for(int j = 0; j < 5; j++){
                    Date checkStartTime = new Date(
                            sdf.parse("201601" + day + "090000").getTime() - (random.nextInt(21600000) - 10800000));
                    Date checkEndTime = new Date(
                            sdf.parse("201601" + day + "180000").getTime() - (random.nextInt(21600000) - 10800000));
                    String checkStartTimeStr = sdf.format(checkStartTime);
                    String checkEndTimeStr = sdf.format(checkEndTime);

                    pstmt.setString(1, UUID.randomUUID().toString().replaceAll("-", ""));
                    pstmt.setString(2, checkStartTimeStr);
                    pstmt.setTimestamp(3, new Timestamp(checkStartTime.getTime()));
                    pstmt.setString(4, checkStartTimeStr.substring(0, 4));
                    pstmt.setString(5, checkStartTimeStr.substring(4, 6));
                    pstmt.setString(6, checkStartTimeStr.substring(6, 8));
                    pstmt.setString(7, checkStartTimeStr.substring(0, 8));
                    pstmt.setString(8, result.getString(1));
                    pstmt.setString(9, "402888634f5d7f28014f62f346af1268");
                    pstmt.setString(10, "NONE");
                    pos++;
                    pstmt.addBatch();

                    pstmt.setString(1, UUID.randomUUID().toString().replaceAll("-", ""));
                    pstmt.setString(2, checkEndTimeStr);
                    pstmt.setTimestamp(3, new Timestamp(checkEndTime.getTime()));
                    pstmt.setString(4, checkEndTimeStr.substring(0, 4));
                    pstmt.setString(5, checkEndTimeStr.substring(4, 6));
                    pstmt.setString(6, checkEndTimeStr.substring(6, 8));
                    pstmt.setString(7, checkEndTimeStr.substring(0, 8));
                    pstmt.setString(8, result.getString(1));
                    pstmt.setString(9, "402888634f5d7f28014f62f346af1268");
                    pstmt.setString(10, "NONE");
                    pos++;
                    pstmt.addBatch();

                    if (pos % 10000 == 0) {
                        long sj = (new Date().getTime() - t1.getTime()) / 1000;
                        pstmt.executeBatch();
                        conn.commit();
                        System.out.println("插入" + pos + "条,已用时"+sj+"秒");
                    }
                }
            }
        }

        pstmt.executeBatch();
        conn.commit();
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        if (pstmt != null) {
            try {
                pstmt.close();
            } catch (SQLException e) {
                e.printStackTrace();
            }
        }
        if (conn != null) {
            try {
                conn.close();
            } catch (SQLException e) {
                e.printStackTrace();
            }
        }
    }
}
0

5个回答

解决,把主键的uuid改成字符串的1,2,3.。。。就正常了。
插入10000条,已用时0秒
插入20000条,已用时1秒
插入30000条,已用时2秒
插入40000条,已用时3秒
插入50000条,已用时4秒
插入60000条,已用时5秒
插入70000条,已用时6秒
插入80000条,已用时7秒
插入90000条,已用时7秒
插入100000条,已用时8秒
插入110000条,已用时9秒
插入120000条,已用时10秒
插入130000条,已用时11秒
插入140000条,已用时12秒
插入150000条,已用时13秒
插入160000条,已用时14秒
插入170000条,已用时14秒
插入180000条,已用时15秒
插入190000条,已用时16秒
插入200000条,已用时17秒
插入210000条,已用时18秒
插入220000条,已用时19秒
插入230000条,已用时20秒
插入240000条,已用时21秒
插入250000条,已用时21秒
插入260000条,已用时22秒
插入270000条,已用时23秒
插入280000条,已用时24秒
插入290000条,已用时25秒
插入300000条,已用时26秒
插入310000条,已用时27秒
插入320000条,已用时28秒
插入330000条,已用时28秒
插入340000条,已用时29秒
插入350000条,已用时30秒
插入360000条,已用时31秒
插入370000条,已用时32秒
插入380000条,已用时33秒
插入390000条,已用时34秒
插入400000条,已用时34秒
插入410000条,已用时35秒
插入420000条,已用时36秒
插入430000条,已用时37秒
插入440000条,已用时38秒
插入450000条,已用时40秒
插入460000条,已用时41秒
插入470000条,已用时42秒
插入480000条,已用时43秒
插入490000条,已用时44秒
插入500000条,已用时45秒
插入510000条,已用时46秒
插入520000条,已用时47秒
插入530000条,已用时48秒
插入540000条,已用时49秒
插入550000条,已用时50秒
插入560000条,已用时51秒
插入570000条,已用时52秒
插入580000条,已用时53秒
插入590000条,已用时54秒
插入600000条,已用时55秒
插入610000条,已用时56秒
插入620000条,已用时57秒
插入630000条,已用时58秒
插入640000条,已用时59秒
插入650000条,已用时60秒
插入660000条,已用时61秒
插入670000条,已用时62秒
插入680000条,已用时63秒
插入690000条,已用时64秒
插入700000条,已用时65秒
插入710000条,已用时66秒
插入720000条,已用时67秒
插入730000条,已用时68秒
插入740000条,已用时69秒
插入750000条,已用时70秒
插入760000条,已用时71秒
插入770000条,已用时73秒
插入780000条,已用时74秒
插入790000条,已用时75秒
插入800000条,已用时76秒
插入810000条,已用时77秒
插入820000条,已用时78秒
插入830000条,已用时80秒
插入840000条,已用时81秒
插入850000条,已用时82秒
插入860000条,已用时83秒
插入870000条,已用时84秒
插入880000条,已用时85秒
插入890000条,已用时86秒
插入900000条,已用时87秒
插入910000条,已用时88秒
插入920000条,已用时90秒
插入930000条,已用时91秒
插入940000条,已用时92秒
插入950000条,已用时93秒
插入960000条,已用时94秒
插入970000条,已用时95秒
插入980000条,已用时97秒
插入990000条,已用时98秒
插入1000000条,已用时99秒
插入1010000条,已用时100秒
插入1020000条,已用时101秒
插入1030000条,已用时102秒
插入1040000条,已用时104秒
插入1050000条,已用时105秒
插入1060000条,已用时106秒
插入1070000条,已用时107秒
插入1080000条,已用时108秒
插入1090000条,已用时110秒
插入1100000条,已用时111秒
插入1110000条,已用时113秒
插入1120000条,已用时114秒
插入1130000条,已用时116秒
插入1140000条,已用时117秒
插入1150000条,已用时118秒
插入1160000条,已用时119秒
插入1170000条,已用时121秒
插入1180000条,已用时122秒
插入1190000条,已用时123秒
插入1200000条,已用时124秒
插入1210000条,已用时125秒
插入1220000条,已用时126秒
插入1230000条,已用时128秒
插入1240000条,已用时129秒
插入1250000条,已用时130秒
插入1260000条,已用时131秒
插入1270000条,已用时133秒
插入1280000条,已用时134秒
插入1290000条,已用时135秒
插入1300000条,已用时136秒
插入1310000条,已用时138秒
插入1320000条,已用时139秒
插入1330000条,已用时140秒
插入1340000条,已用时141秒
插入1350000条,已用时143秒
插入1360000条,已用时144秒
插入1370000条,已用时145秒
插入1380000条,已用时146秒
插入1390000条,已用时148秒
插入1400000条,已用时149秒
插入1410000条,已用时150秒
插入1420000条,已用时151秒
插入1430000条,已用时153秒
插入1440000条,已用时154秒
插入1450000条,已用时155秒
插入1460000条,已用时157秒
插入1470000条,已用时158秒
插入1480000条,已用时159秒
插入1490000条,已用时160秒
插入1500000条,已用时161秒
插入1510000条,已用时163秒
插入1520000条,已用时164秒
插入1530000条,已用时165秒
插入1540000条,已用时166秒
插入1550000条,已用时168秒
插入1560000条,已用时169秒
插入1570000条,已用时170秒
插入1580000条,已用时171秒
插入1590000条,已用时172秒
插入1600000条,已用时173秒
插入1610000条,已用时175秒
插入1620000条,已用时176秒
插入1630000条,已用时178秒
插入1640000条,已用时179秒
插入1650000条,已用时180秒
插入1660000条,已用时182秒
插入1670000条,已用时183秒
插入1680000条,已用时184秒
插入1690000条,已用时185秒
插入1700000条,已用时186秒
插入1710000条,已用时188秒
插入1720000条,已用时189秒
插入1730000条,已用时190秒
插入1740000条,已用时192秒
插入1750000条,已用时193秒
插入1760000条,已用时194秒
插入1770000条,已用时195秒
插入1780000条,已用时197秒
插入1790000条,已用时198秒
插入1800000条,已用时199秒
插入1810000条,已用时201秒
插入1820000条,已用时202秒
插入1830000条,已用时203秒
插入1840000条,已用时205秒
插入1850000条,已用时206秒
插入1860000条,已用时207秒
插入1870000条,已用时209秒
插入1880000条,已用时210秒
插入1890000条,已用时211秒
插入1900000条,已用时212秒
插入1910000条,已用时213秒
插入1920000条,已用时215秒
插入1930000条,已用时216秒
插入1940000条,已用时217秒
插入1950000条,已用时218秒
插入1960000条,已用时220秒
插入1970000条,已用时221秒
插入1980000条,已用时222秒
插入1990000条,已用时223秒
插入2000000条,已用时225秒
插入2010000条,已用时226秒
插入2020000条,已用时227秒
插入2030000条,已用时228秒
插入2040000条,已用时229秒
插入2050000条,已用时230秒
插入2060000条,已用时231秒
插入2070000条,已用时233秒
插入2080000条,已用时234秒
插入2090000条,已用时236秒
插入2100000条,已用时237秒
插入2110000条,已用时238秒
插入2120000条,已用时239秒
插入2130000条,已用时241秒
插入2140000条,已用时242秒
插入2150000条,已用时243秒
插入2160000条,已用时244秒
插入2170000条,已用时246秒
插入2180000条,已用时247秒
插入2190000条,已用时249秒
插入2200000条,已用时250秒
插入2210000条,已用时251秒
插入2220000条,已用时253秒
插入2230000条,已用时254秒
插入2240000条,已用时255秒
插入2250000条,已用时256秒
插入2260000条,已用时258秒
插入2270000条,已用时259秒
插入2280000条,已用时261秒
插入2290000条,已用时263秒
插入2300000条,已用时265秒
插入2310000条,已用时266秒
插入2320000条,已用时267秒
插入2330000条,已用时268秒
插入2340000条,已用时269秒
插入2350000条,已用时270秒
插入2360000条,已用时271秒
插入2370000条,已用时272秒
插入2380000条,已用时273秒
插入2390000条,已用时275秒
插入2400000条,已用时276秒
插入2410000条,已用时277秒
插入2420000条,已用时279秒
插入2430000条,已用时280秒
插入2440000条,已用时281秒
插入2450000条,已用时282秒
插入2460000条,已用时283秒
插入2470000条,已用时284秒
插入2480000条,已用时285秒
插入2490000条,已用时286秒
插入2500000条,已用时288秒
插入2510000条,已用时289秒
插入2520000条,已用时290秒
插入2530000条,已用时292秒
插入2540000条,已用时293秒
插入2550000条,已用时294秒
插入2560000条,已用时295秒
插入2570000条,已用时296秒
插入2580000条,已用时298秒
插入2590000条,已用时299秒
插入2600000条,已用时300秒
插入2610000条,已用时301秒
插入2620000条,已用时302秒
插入2630000条,已用时304秒
插入2640000条,已用时305秒
插入2650000条,已用时306秒
插入2660000条,已用时308秒
插入2670000条,已用时309秒
插入2680000条,已用时310秒
插入2690000条,已用时311秒
插入2700000条,已用时313秒
插入2710000条,已用时314秒
插入2720000条,已用时315秒
插入2730000条,已用时316秒
插入2740000条,已用时317秒
插入2750000条,已用时319秒
插入2760000条,已用时320秒
插入2770000条,已用时321秒
插入2780000条,已用时322秒
插入2790000条,已用时324秒
插入2800000条,已用时325秒
插入2810000条,已用时326秒
插入2820000条,已用时327秒
插入2830000条,已用时329秒
插入2840000条,已用时330秒
插入2850000条,已用时331秒
插入2860000条,已用时332秒
插入2870000条,已用时334秒
插入2880000条,已用时335秒
插入2890000条,已用时336秒
插入2900000条,已用时337秒
插入2910000条,已用时339秒
插入2920000条,已用时340秒
插入2930000条,已用时341秒
插入2940000条,已用时342秒
插入2950000条,已用时343秒
插入2960000条,已用时344秒
插入2970000条,已用时345秒
插入2980000条,已用时347秒
插入2990000条,已用时348秒
插入3000000条,已用时349秒
插入3010000条,已用时351秒
插入3020000条,已用时352秒
插入3030000条,已用时353秒
插入3040000条,已用时355秒
插入3050000条,已用时356秒
插入3060000条,已用时358秒
插入3070000条,已用时359秒
插入3080000条,已用时360秒
插入3090000条,已用时361秒
插入3100000条,已用时362秒

0

检查主键、外键、唯一索引、触发器等。

2
qq1247
笨人_ 无外键,无索引,无触发器
3 年多之前 回复

不过最好先看下目前消耗的是cpu内存还是io,然后才好判断。

2

原因分析一下吧,开始使用uuid作为主键,由于生成的uuid是无序的。写入数据库的时候引起page分裂,数量越大分裂的可能性就越大,分裂时需要搬动的数据库就越多。所以会越来越慢。后来把uuid变成1、2、3这样的字符窜,数据是有序地写入,不会引起page的分裂,不存在数据的搬动,所以可以保持速度很快。这和innodb的存储引擎特性有关。建议直接使用自增主键。

1

用explain等查看一下性能瓶颈 是不是数据进去跟已有数据有联系 导致越来越慢

0
qq1247
笨人_ 插入不能用explain查看吧。
3 年多之前 回复
qq1247
笨人_ 插入不能用explain查看吧。
3 年多之前 回复
Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
其他相关推荐
java下的mysql数据库插入越插越慢的问题解决(百万数据量级别)
最近的项目需要导入大量的数据,插入的过程中还需要边查询边插入。插入的数据量在100w左右。n一开始觉得100w的数据量不大,于是就插啊插,吃了个饭,回来一看,在插入了50多w条数据后,每秒就只能插10条了。。觉得很奇怪,为啥越插越慢呢?n于是就开始分析插入的时间损耗,想到了如下的解决方案:(mysql使用的INNODB引擎)n1.分析是否是由主码,外码,索引造成的插入效率降低n主码:由于主
mysql近500w条数据建立索引后查询速度还是提升很多
494w条数据rn根据hash查询速度 好几秒rnrnrn建立索引后rnrn快乐好多好多,就是索引存储空间占用比数据空间还大
mysql 批量插入数据(INNODB)优化
innodb的主要优化rninit_connect='SET autocommit=0'    //关闭自动提交,这个对于innodb来说,很重要  rn innodb-file-per-table=1            //使用独立表空间  rn innodb-open-file=500               //打开最大文件数据是500,默认是300  rn innodb_log_f
mysql的limit优化(大数据量 Mysql limit分页慢的解决办法)
mysql的limit优化(大数据量 Mysql limit分页慢的解决办法)rn单表数据量超千万,使用limit 大的话很慢,(aid 做主键索引)SELECT   aid,jid,title,content FROM article_a WHERE aid&amp;gt;='10000000' limit 20执行时间,2~3秒。SELECT aid,jid,title,content FROM ar...
MySQL测试任务:使用存储过程,往表中插入百万级数据,根据索引优化速度
 nn创建表nDROP TABLE IF EXISTS index_test;nCREATE TABLE index_test(nid BIGINT(20) PRIMARY KEY NOT NULL AUTO_INCREMENT,nUSER VARCHAR(16) DEFAULT NULL,npsd varchar(64) default nulln/*psd mediumint DEFAULT ...
mysql innodb优化导致的慢查询
现象:同样一段sql,由于时间条件不同,导致执行的时间相差1个数量级nn nn1、执行sql 1:nnnselect nDISTINCT nx.x_id, x.x_record_id, x.aid, y.z_id, x.gmt_created, x.user_id, x.xx_id, x.xx_no, x.operatornfrom x, y  , znwhere nx.x_id = y.x_id...
MySql Innodb引擎 数据表 上万条数据连续插入优化
innodb_flush_log_at_trx_commit rn设置为0 的时候,Log Thread 会在每次事务结束的时候将数据写入事务日志,mysql每秒执行一次,mysql崩溃,则会丢失数据。rnrn设置为1 的时候,Log Thread 会在每次事务结束的时候将数据写入事务日志,并flush写入磁盘。rnrn设置为2 的时候,Log Thread 会在每次事务结束的时候将数据写入事务日
关于批量插入数据之我见(100万级别的数据,mysql)
http://blog.csdn.net/frinder/article/details/38830723
插入大量数据速度慢的解决方法:批量插入
场景:rn项目需要导入案件2200条。其中导入的excel每个行案件的信息上包含大约15个联系方式。那么总的联系方式一共用30000条左右rn这里优化之前的速度是16-20分钟之间。太慢了。找了好久优化的方法。最后确定了使用mysql批量插入的方法去进行插入操作rnrnrn慢的原因及解决思路:rn这里慢的原因是针对本项目:rn插入方式为程序遍历循环逐条插入。在mysql上检测插入一条的速度在0.0
50万条数据保存到数据库
load data infile 'D:/yaoding/gitDataSource/ceeasPython/sqlFiles/insertCollegeCutoff.txt' ignore into table college_cutoff fields terminated by ',' enclosed by '"' lines terminated by '\r\n' (`COLLEGEI
MySQL——InnoDB锁问题(四)
一、InnoDB行锁实现方式。rn     InnoDB行锁是通过给索引上的索引项来加锁实现的,如果没有索引,InnoDB将通过隐藏的聚簇索引来对记录加锁。InnoDB行锁分三种情形。rn(1)Record lock :对索引项加锁。rn(2)Grap lock:对索引项之间的”间隙”、第一条记录前的“间隙”,或者最后一条记录后的“间隙”加锁。rn(3)Next-key lock:前两种的组合,对
MySQL像数据库批量插入100w条数据
package com.test.mysql;rnrnimport java.io.IOException;rnimport java.sql.DriverManager;rnimport java.sql.PreparedStatement;rnimport java.sql.SQLException;rnimport com.mysql.jdbc.Connection;rnpublic cla
mysql中for update没有命中索引会锁表吗?
前天和同事饭后散步的时候他说使用for update如果没有命中索引就会锁表,刚好最近要写类似的代码,听了之后心有戚戚,于是乎来尝试一下。n表结构:nn数据:nn第一个事务:SELECT * FROM student WHEREno= '325985' FOR UPDATE;nn第二个事务:SELECT * FROM student WHEREno= '456325' FOR UPDATE;nn可...
MySQL InnoDB 默认行级锁,行级锁都是基于索引,SQL 语句用不到索引是不会使用行级锁的,而会使用表级锁把整张表锁住
使用select…forrn update给数据加锁的时候,咱们需要注意锁的级别,MySQL InnoDB 默认行级锁。rn行级锁都是基于索引的,如果一条 SQL 语句用不到索引是不会使用行级锁的,而会使用表级锁把整张表锁住,这点需要咱们格外的注意
Mysql InnoDB引擎 -索引组织表
在InnoDB 存储引擎中,表都是根据主键顺序组织存放的,这种存储方式的额表称为索引组织表。在InnoDB存储引擎表中,每张表都有个主键(Primary key),如果在创建表时 没有显示地定义主键,则InnoDB存储引擎会按如下方式选择或创建主键:首先判断表是否有非空的唯一索引(Unique not null),如果有,则该列即为主键。如果不符合上述条件,InnoDB存储引擎自动创建一个6字节大...
navicat批量插入mysql表数据
打开Navicat的查询,写入以下代码,定义一个方法:nnndelimiter //nCREATE PROCEDURE pro_insertMany(in num INT)nBEGINn DECLARE i int DEFAULT 1;n WHILE i&amp;lt;=num DOn INSERT INTO students VALUES(NULL,CONCAT('html',i),CONCAT('分...
mysql 有索引没走索引 更新锁全表
Session 1:nmysql> select connection_id();n+-----------------+n| connection_id() |n+-----------------+n| 2 |n+-----------------+n1 row in set (0.00 sec)nnmysql> start transaction;nQuery
mysql Innodb单表31m千万级数据count计数方案及调优
ENVn线上环境为RDS,版本5.7.15 n nselect version() noutput: n5.7.15-log 测试环境为docker搭建的mysql,版本5.7.19 n nselect version() noutput: n5.7.19 单表3000万+的class表以及20万+的学校表,需要使用count查询实时数量用于分页,延迟不能太高,否则影响业务n因需要使用事务功能,使用
Mysql学习总结(35)——Mysql两千万数据优化及迁移
最近有一张2000W条记录的数据表需要优化和迁移。2000W数据对于MySQL来说很尴尬,因为合理的创建索引速度还是挺快的,再怎么优化速度也得不到多大提升。不过这些数据有大量的冗余字段和错误信息,极不方便做统计和分析。所以我需要创建一张新表,把旧表中的数据一条一条取出来优化后放回新表;rnrn一. 清除冗余数据,优化字段结构rn2000W数据中,能作为查询条件的字段我们是预知的。所以将这部分数据单
关于limit在后面为什么会慢的问题
n      大家都用过mysql分页,实现一般是select * from talbe_name limit pageSize*(pageNo-1),pageSizern这条语句前面几页很快,为什么会随着pageNo增大而导致变慢呢?rn rn原理是因为limit分页它会把pageSize*(pageNo-1)以前的记录也标记出来。这句话说得可能不是很容易理解。举个简单的例子,邮局的信件可能按地...
InnoDB这种行锁实现特点意味者:只有通过索引条件检索数据,InnoDB才会使用行级锁,否则,InnoDB将使用表锁!
InnoDB行锁是通过索引上的索引项来实现的,这一点MySQL与Oracle不同,后者是通过在数据中对相应数据行加锁来实现的。nnInnoDB这种行锁实现特点意味者:只有通过索引条件检索数据,InnoDB才会使用行级锁,否则,InnoDB将使用表锁!n n在实际应用中,要特别注意InnoDB行锁的这一特性,不然的话,可能导致大量的锁冲突,从而影响并发性能。
mysql千万级数据量根据索引优化查询速度
(一)索引的作用nn索引通俗来讲就相当于书的目录,当我们根据条件查询的时候,没有索引,便需要全表扫描,数据量少还可以,一旦数据量超过百万甚至千万,一条查询sql执行往往需要几十秒甚至更多,5秒以上就已经让人难以忍受了。nn提升查询速度的方向一是提升硬件(内存、cpu、硬盘),二是在软件上优化(加索引、优化sql;优化sql不在本文阐述范围之内)。nn能在软件上解决的,就不在硬件上解决,毕竟硬件提升...
MySQL重建或修复表或索引
2.11.3重建或修复表或索引nnnnn本节介绍如何重建或修复表或索引,这可能需要以下几点:nnnn对MySQL如何处理数据类型或字符集的更改。例如,排序规则中的错误可能已被更正,需要重建表以更新使用排序规则的字符列的索引。nn所需的表修理或升级的报道 CHECKn TABLE, mysqlcheck的,或 mysql_upgrade。nnn重建表的方法包括:
mysql优化存储过程中批量插入的速度
第一次操作,每一条数据执行一次插入操作。 n一万条数据花费34s,太慢。nCREATE PROCEDURE insertPro(in sum INT)nBEGINnDECLARE count INT DEFAULT 0;nDECLARE i INT DEFAULT 0;nset count=0;nset i = rand() * 10000;nwhile count<sum do n inse
【Mysql】给你100万条数据的一张表,你将如何查询优化?
author:咔咔nnwechat:fangkangfknn1.两种查询引擎查询速度(myIsam 引擎 )nnInnoDB 中不保存表的具体行数,也就是说,执行select count(*) from table时,InnoDB要扫描一遍整个表来计算有多少行。nnMyISAM只要简单的读出保存好的行数即可。nn注意的是,当count(*)语句包含 where条件时,两种表的操作有些不同,Inno...
MySQL表为什么必须有主键 -- 聚集索引的简单介绍
比较规范的数据库表设计(包括我们公司)都会有一条不成文的规定,那就是给每张表一个自增主键。那么自增主键除了有数据的唯一性外,还有什么所用呢?为什么要有自增主键?
MySQL批量插入百万条数据
这是个面试题,我的第一想法是foreach 一条条插入。凉凉!!!nn1.建库建表million_data  test 字段 id name timenn2.由于单条循环插入肯定没有拼接一条sql语句快的,所以直接拼接一条,运行 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 1099...
几张图介绍MyISAM和InnoDB的数据分布以及主键索引和二级索引的数据分布区别
表结构:           create table layout_test (                    col1 int NOT NULL,                    col2 int NOT NULL ,                    PRIMARY KEY (col1),                    KEY (col2)            )...
MySQL在Innodb和MyISAM中的二级索引
本文主要讲解InnoDB和MyISAM两种存储引擎的二级索引区别。n1.二级索引与聚簇索引n  聚簇索引的认识请参考百科点击打开链接n二级索引,又被成为辅助索引,在不同存储引擎中的内容不同。n两者的区别在于:聚簇索引的叶子节点存放的是主键值和数据行,支持覆盖索引;二级索引的叶子节点存放的是主键值或指向数据行的指针。n2.两种引擎中的区别nInnoDB中的二级索引存放的是主键值,如果需要
MYSQL INNODB数据存储结构
一 序:nn    在整理InnoDB存储引擎的索引的时候,发现B+树是离不开页面page的。所以先整理InnoDB的数据存储结构。nn关键词:Pages, Extents, Segments, and Tablespacesnn如何存储表nnMySQL 使用 InnoDB 存储表时,会将表的定义和数据索引等信息分开存储,其中前者存储在 .frm 文件中,后者存储在 .ibd 文件中,这一节就会对...
mysql中关于批量插入数据(1万、10万、100万、1000万、1亿级别的数据)二
硬件:windows7+8G内存+i3-4170处理器+4核CPUnn关于前天写的批量插入数据,还有一种方式,就是通过预先写入文本文件,然后通过mysql的load in file命令导入到数据库,今天把这种方式也说一下,首先是main方法调用:nn解释一下为什么要两个参数:nn第一个参数是写入几次nn第二个参数是一次写入多少条,直观来说就是StringBuffer中存储多少条记录(目的为了测试S...
php向MySQL数据库批量添加几十万条数据,很少一部分数据丢失
1.出现高并发现象。nn2.php脚本有个默认的执行超时时间  默认为30秒,所以对批量数据处理的时候会停止,nn解决方法:可以再第一行代码中添加set_time_limit(0);(永不超时)...
EF大批量插入数据的性能调优思路
最近碰到一个需求:需要从XML格式的文本中解析数据,并写入数据库表中。遇到这种情况自然是EF+WinForm开干,写完程序之后跑了一下,发现速度有点慢,因为数据急着要,所以就这么拿去用了。最后实际运行的速度大概是2W条数据10分钟左右。nn后面仔细想了想,性能不应该这么低才对。首先想到会不会是多线程的问题,于是看了下资源监视器,所有核心都是在跑的。nnnn(程序运行时的CPU占用)nn然后在代码里...
mysql 插入百万数据过慢的解决办法
一开始我用存储过程批量插入100万条数据的时候,用了几个小时都还没有插完,这让我十分郁闷。于是我想应该会有解决办法吧nn我存储过程sql代码如下:nnndelimiter #ncreate PROCEDURE test()nBEGINnDECLARE i int DEFAULT 1;nwhile i&amp;lt;=1000000 DOn insert into book VALUES(null,'jav...
mysql 删除数据慢
最近做项目,一张单表临时数据达到3亿,非常影响数据库性能,就考虑删除表中多余的数据,就遇到这个删除数据非常缓慢的问题了! n直接上代码吧:DELETE FROM t_orders_detail WHERE pro_record_id in(SELECT a.prId FROM (SELECT pr.id AS prId FROM t_pro_record pr WHERE pr.state=3 L
MyISAM和InnoDB批量插入1万数据速度比较
创建测试表nnnCREATE TABLE testBinlog(id int PRIMARY KEY auto_increment ,name CHAR(16));//MySQL默认存储引擎为InnoDBnnCREATE TABLE testMyISAM(id int PRIMARY KEY AUTO_INCREMENT, name CHAR(16))ENGINE = MyISAM;nnn表结构信...
mysql中innodb、mysaim存储引擎的区别及explain的使用
mysql中主要的存储引擎是innodb、mysiam。下面介绍一下它们的区别:rninnodb、mysiamrninnodb:注重事物、行级锁、R/W比较少,频繁更新大字段rnmysiam : 注重性能、表级锁、R/W > 100 :1且update相对较少。rnrnrn总结 :innodb整体性能远高于myisam。同时,innodb的索引不仅需要缓存索引本身,也缓存数据,所以innodb需要
200w条数据创建索引所遇问题二
错误原因,请求数据量超过设定值解决方案Exception in thread &quot;main&quot; java.lang.reflect.InvocationTargetExceptionn at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)n at sun.reflect.NativeMethodAccessorImpl.invok...
MySQL中innodb的索引和锁
  innodb是支持行锁的。并且,索引可以让查询锁定更少的行。nn  如果你的查询从不访问那些不需要的行,那么就会锁定更少的行,从两个方面可以来看这对性能有好处nn  虽然innodb的行锁效率很高,内存使用也很少,但是锁定行的时候仍然会带来额外的开销n   锁定超过需要的行会增加锁征用并减少并发性。n  innodb只有在访问行的时候才会对其加锁,而索引能够减少innodb访问的行数,从而减少...
上万条数据插入和去重
建立一个和主表一样的副表。然后每次用sqlbulkcopy将数据写入副表。然后在数据库中,利用sql来查询来取出有效数据,插入到主表即可
文章热词 机器学习教程 Objective-C培训 交互设计视频教程 颜色模型 设计制作学习
相关热词 mysql关联查询两次本表 native底部 react extjs glyph 图标 50了开始学习java 大数据无基础