探討MySQL中索引和提交頻率對InnoDB表寫入速度的影響。本站提示廣大學習愛好者：（探討MySQL中索引和提交頻率對InnoDB表寫入速度的影響）文章只能為提供參考，不一定能成為您想要的結果。以下是探討MySQL中索引和提交頻率對InnoDB表寫入速度的影響正文
本次，我們來看看索引、提交頻率對InnoDB表寫入速度的影響，懂得有哪些須要留意的。
先直接說幾個結論吧：
1、關於索引對寫入速度的影響：
a、假如有自增列做主鍵，絕對完整沒索引的情形，寫入速度約晉升 3.11%；
b、假如有自增列做主鍵，而且二級索引，絕對完整沒索引的情形，寫入速度約下降 27.37%；
是以，InnoDB表最好老是有一個自增列做主鍵。
2、關於提交頻率對寫入速度的影響（以表中只要自增列做主鍵的場景，一次寫入數據30萬行數據為例）：
a、期待全體數據寫入完成後，最初再履行commit提交的效力最高；
b、每10萬行提交一次，絕對一次性提交，約慢了1.17%；
c、每1萬行提交一次，絕對一次性提交，約慢了3.01%；
d、每1千行提交一次，絕對一次性提交，約慢了23.38%；
e、每100行提交一次，絕對一次性提交，約慢了24.44%；
f、每10行提交一次，絕對一次性提交，約慢了92.78%；
g、每行提交一次，絕對一次性提交，約慢了546.78%，也就是慢了5倍；
是以，最好是期待一切事務停止後再批量提交，而不是每履行完一個SQL就提交一次。
已經有一次比較測試mysqldump啟用extended-insert和未啟用導出的SQL劇本，後者比前者慢了不止5倍。
主要：這個建議其實不是相對成立的，要看詳細的場景。假如是一個高並發的在線營業，就須要盡快提交事務，防止鎖規模被擴展。但假如是在非高並發的營業場景，特別是做數據批量導入的場景下，就建議采取批量提交的方法。
上面是具體的測試案例進程，有興致的同窗可以看看：
DROP TABLE IF EXISTS `mytab`; CREATE TABLE `mytab` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `c1` int(11) NOT NULL DEFAULT ‘0', `c2` int(11) NOT NULL DEFAULT ‘0', `c3` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `c4` varchar(200) NOT NULL DEFAULT ”, PRIMARY KEY (`id`) ) ENGINE=InnoDB; DELIMITER $$$ DROP PROCEDURE IF EXISTS `insert_mytab`; CREATE PROCEDURE `insert_mytab`(in rownum int, in commitrate int) BEGIN DECLARE i INT DEFAULT 0; SET AUTOCOMMIT = 0; WHILE i < rownum DO INSERT INTO mytab(c1, c2, c3,c4) VALUES( FLOOR(RAND()*rownum),FLOOR(RAND()*rownum),NOW(), REPEAT(CHAR(ROUND(RAND()*255)),200)); SET i = i+1; /* 到達每 COMMITRATE 頻率時提交一次 */ IF (commitrate > 0) AND (i % commitrate = 0) THEN COMMIT; SELECT CONCAT(‘commitrate: ‘, commitrate, ‘ in ‘, I); END IF; END WHILE;
/* 終究再提交一次,確保勝利 */
COMMIT; SELECT ‘ALL COMMIT;'; END; $$$ #測試挪用 call insert_mytab(300000, 1); — 每次一提交 call insert_mytab(300000, 10); — 每10次一提交 call insert_mytab(300000, 100); — 每100次一提交 call insert_mytab(300000, 1000); — 每1千次一提交 call insert_mytab(300000, 10000); — 每1萬次提交 call insert_mytab(300000, 100000); — 每10萬次一提交 call insert_mytab(300000, 0); — 一次性提交
測試耗時成果比較：
